AWS VPCとアプリケーションラッピングのサブネット

Question

私はAWS組織パターンをよりよく理解しようとしています。

「アプリケーションスタック」という用語を相互接続されたAWSリソース（ELB + dynamoDBの背後にあるJavaマイクロサービスなど）のセットとして定義すると、独立したスタックを分離する方法が必要です。各アプリケーションは個別のdynamodbまたはkinesisを取得するため、クロススタックリソース共有の必要はありません。しかし、マイクロサービスは互いに通信する必要があります。

Iが使用されている2つの組織のいずれかの方法を見ることができる演繹：

1. それぞれ独立スタック用VPC（1つのアプリケーションにつき1 VPC）を作成

2. は、単一の「生産を作成します"VPCと各スタックは別々のプライベートサブネット内にあります。

リソースの枯渇の可能性がありますので、VPC数のハード制限がある場合は、組織内のこれらの独立した「スタック」の100Sまでがあるかもしれません。しかしリソース不足の他、新しいVPCを作成するか、既存のVPCを各スタックに使用するかの決定基準は何ですか？いずれのアプローチにも強い肯定的または否定的な結果がありますか？

ありがとうございました。

Answer 1

サブネットとIPアドレスは、VPC内の限られた商品です。その制限に達すると、VPC内でIPアドレスの数を増やすことはできません。また、デフォルトでは、すべてのサブネットが他のサブネットと通信できるため、セキュリティ上の懸念があります。 VPC数の制限はソフトリミットであり、AWSサポートによって増加させることができます。

これらの理由から、VPCレベルで別個のプロジェクトを区切ります。 VPC内でプロジェクトを混在させないでください。それはただのトラブルを求めているだけです。

また、IAMユーザー、DynamoDBテーブル、SQSキューなどのVPC非対応リソースもプロダクションプロジェクトに含める予定がある場合は、それらのプロジェクトを独自のAWSアカウント（生産レベル）。

このように、異なるプロジェクトのテーブルを含むDynamoDBテーブルのリストは表示されません。