如果在 CloudFormation 裡面直接使用 "AWS::Lambda::Version" 加上 ProvisionedConcurrencyConfig 接著 update stack 更新 ConcurrentExecutions 就會出現 update error 因為 version 不能夠 update
但是如果把 ProvisionedConcurrency 放在 "AWS::Lambda::Alias" 裡面，update stack 卻又可以了... lol...
不過一個 provisioned concurrent lambda 一個月要額外多 $5 USD 的費用還不包含 lambda execution 的費用，一個 1 vCPU + 512MB 的 fargate container 也不過大概是 $31 USD ....
Update:
再仔細看了一下，update stack 失敗的原因有兩個一個是因為 Application Load Balancer Target Group 指向的 lambda 無法 stabilized 所以 update 失敗導致 rollback。其中一個原因是因為 ALB 沒有權限 invoke lambda function。LambdaPermission resource 還沒執行時，就先執行了 ALB TargetGroup 設定，所以在 TargetGroup resource 加了 DependsOn LambdaPermission 後，就少了 一個錯誤，但剩下的 ALB 無法 stabilized 的錯誤目前還是無解.... 只能把 stack 刪掉重新 deploy，接下來的 update 好像就都沒事。只是說在刪除 stack 的時候，會出現等待 lambda ENI 刪除的 waiting... 要等 8 ~ 20 min? 據說是後來 aggregate ENI 給 VPC 內的 lambda 後導致的 side effect....
CloudFormation 印象中也是越來越聰明，當 Resource A 有 !Ref Resource B 的時候，就會自動做 DependsOn 調整執行順序，但是像今天這個 LambdaPermission 和 ALB TargetGroup 似乎就漏掉了...
ALB + lambda + provisioned concurrency 很多 bug 一次踩好踩滿 Q_Q...
但是如果把 ProvisionedConcurrency 放在 "AWS::Lambda::Alias" 裡面，update stack 卻又可以了... lol...
不過一個 provisioned concurrent lambda 一個月要額外多 $5 USD 的費用還不包含 lambda execution 的費用，一個 1 vCPU + 512MB 的 fargate container 也不過大概是 $31 USD ....
Update:
再仔細看了一下，update stack 失敗的原因有兩個一個是因為 Application Load Balancer Target Group 指向的 lambda 無法 stabilized 所以 update 失敗導致 rollback。其中一個原因是因為 ALB 沒有權限 invoke lambda function。LambdaPermission resource 還沒執行時，就先執行了 ALB TargetGroup 設定，所以在 TargetGroup resource 加了 DependsOn LambdaPermission 後，就少了 一個錯誤，但剩下的 ALB 無法 stabilized 的錯誤目前還是無解.... 只能把 stack 刪掉重新 deploy，接下來的 update 好像就都沒事。只是說在刪除 stack 的時候，會出現等待 lambda ENI 刪除的 waiting... 要等 8 ~ 20 min? 據說是後來 aggregate ENI 給 VPC 內的 lambda 後導致的 side effect....
CloudFormation 印象中也是越來越聰明，當 Resource A 有 !Ref Resource B 的時候，就會自動做 DependsOn 調整執行順序，但是像今天這個 LambdaPermission 和 ALB TargetGroup 似乎就漏掉了...
ALB + lambda + provisioned concurrency 很多 bug 一次踩好踩滿 Q_Q...
留言
張貼留言