弊社のサーバレス開発事例にて利用している Nested Applications についてご紹介いたします。 CloudFormationのリソース数の制限 AWS CloudFormation には制限があることをご存知でしょうか。 制限のほとんどは、上限解放することができない制限となっております。 参考：AWS CloudFormation の制限 重要な制限として、リソース数の制限があります。 リソースは一つのテンプレートに最大で200までしか作成することができません。 「テンプレートに記載したリソース数 = リソース数」 ではない 例えば、シンプルなAWS Lambdaをテンプレートに定義した場合、 下記2つのリソースが作成されます。 AWS::Lambda::Function AWS::IAM::Role テンプレートに記載したリソース数は 最終的に出力されるリソース数とは合致し
Announcing nested applications for AWS SAM and the AWS Serverless Application Repository | Amazon Web Services
AWS Compute Blog Announcing nested applications for AWS SAM and the AWS Serverless Application Repository Serverless application architectures enable you to break large projects into smaller, more manageable services that are highly reusable and independently scalable, secured, and evolved over time. As serverless architectures grow, we have seen common patterns that get reimplemented across compa
どうやらSAMのデプロイメントでは、常にベースバージョン(prod)にデプロイされるようです。 で、先程3回目のSAMのデプロイメントがエラーになった理由ですが、こちらのドキュメントの最後の方に理由が記載されています。 Canary がステージで有効になっていると、デプロイは Canary リリースのデプロイになります。Canary 設定がステージから削除されるまで、ステージは非 Canary のデプロイに関連付けることはできません。 悲しい結末 結論として、 API Gateway Canary パターン をSAMのデプロイフローで利用するのは無理っぽいです。。。 理由は、 AWS SAMでCanarySettingは設定はできるが、カナリアバージョンへのデプロイが実質機能しない 仮に上記が可能だとしても、、、 API Gatewayの設定が変更されている必要がある ( = Lambda
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Working with nested stacks - AWS CloudFormation
