kuanhung c

幸運的有 AWS::Serverless::Function 可以使用，不然想到要用 Custom Resource 頭就痛。原生的 AWS::Lambda::Function 如果要使用 Provisioned Concurrency 就必須使用 Version/Alias，但是 Version 的 property 全部都是不能更新的！所以接下來 lambda function 的更新，都不會讓 Alias 指向新的 Version.... 還好透過 Transform 的宣告後，啟用AutoPublishAlias: live 再加上小部分 property 的修改，CloudFormation 就可以自動地幫我們管理 Version 和 Alias 啦。 不過還踩到另外一個小雷是，預設 Application Load Balancer 的 Target Group 如果是指向 lambda 的話，healthy check 是關閉的。但是在這種情況下，你 update stack 就會遇到 " ElasticLoadBalancerV2 TargetGroup did not stabilize " ，很厲害的 AWS Support 就給了一個 workaround ，把 healthy check 打開就好了 .... lol Ref: https://stackoverflow.com/questions/41452274/how-to-create-a-new-version-of-a-lambda-function-using-cloudformation

如果在 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 調整執行順序，但是像今天這個...