ミラーリングされた環境（簡単に言えば、EC2インスタンスとRDSとS3バケットですが、これはかなり一般的な設定です）を展開するための良いパターンとアンチパターンを探しています。これを何百回、あるいは何千回も実行する必要があるとしましょう。私は次のようなアイデアをいくつか検討しました。
複数のアカウント - 単一の目的 - すべての地域を使用
- リージョンごとに VPC のインスタンスを 1 つデプロイし、そのリージョンにサービスのセットをデプロイします。
- 良好、分離が保証され
noisy neighbors、TFモジュールやCloudFormationテンプレートが複雑にならない - 最悪だ、管理上は悪夢だ
単一アカウント - 多目的
- VPCを複数のサブネットに分割し、サブネットグループごとにリソースを展開します。
- 良い、管理が簡単、少ないコストでより多くの成果
- 悪い点：1リージョンあたり20サブネット（16リージョン×20）に制限されているため、近隣のノイズが大きくなり、ネットワークがスパゲッティ状になってしまう可能性があります。
私は、これを実行する方法をさらに検討しており、それがなぜ悪いのか（技術的負債、保守不可能）または良いのか（簡単に再利用できるなど）を検討しています。
どうもありがとう
答え1
したがって、この非常に複雑なトピックに関して、いくつか一般的な点を述べておきます。これは、実際に何を達成しようとしているかによって大きく異なります。
次の 3 つのオプションがあります。
単一の VPC - 単一の大規模サブネット セット - この例では、2 つの「パブリック」サブネットと 2 つの「プライベート」サブネットの 4 つになります。次に、セキュリティ グループを使用して「デプロイメント」を分離します。IP アドレス空間と多数のサブネットを管理する必要があること以外、サブネットを使用して分離する利点はないと思います。最終的に、サブネット間の唯一の違いは通常、AZ/ルート テーブル/nacl/dhcp オプションです。これらのいずれかが変更された場合にのみ、新しいサブネットを使用します。サブネット自体では、「ノイジー ネイバー」の問題は発生しません。これは、従来の「VLAN」の意味でのレイヤー 2 ドメインではなく、アップストリーム インターネット ゲートウェイは、次のとおり、制限なしで水平方向に拡張可能です。Amazon VPC に関するよくある質問
複数の VPC - 単一のアカウントがある場合、リージョン内に複数の VPC を持つことができます。ソフト制限は 5 VPC ですが、ハード制限は次のとおりです。
リージョン内の VPC の数と VPC あたりのセキュリティ グループの数を掛けた数が 10000 を超えることはできません。
これはかなり高いですね。あなたの例では、セキュリティ グループが 4 つ (ELB、EC2 ASG、RDS、管理者アクセス) あると考えられるので、理論上は 2,500 個の VPC ということになりますか? そんなことをしている人は聞いたことがありませんが、選択肢の 1 つになるかもしれません。
ただし、プラットフォームの自動スケーラビリティに応じて考慮すべきもう 1 つの点は、一部の制限はアカウント全体に適用され、1 つのデプロイメントでその制限に達すると、別のデプロイメント (たとえば、特定のタイプのインスタンス数) や Lambda 同時実行制限に影響する可能性があることです。これが 3 番目のオプションにつながります...
複数のアカウント - AWS Organizations API のおかげで、API 経由で新しいアカウントを作成できるようになりました。ただし、残念ながら制限ページではアカウント数に関する制限があいまいです。ただし、大企業では 1,000 以上のアカウントがあるという話は聞いたことがあります。以下を参照してください。AWS 組織の制限そしてAWS Organizations を使用してエンドツーエンドのアカウント作成を自動化する方法
ユースケース全体では、展開、運用、サポートの一貫性を保つために、最小限のバリエーションで完全に再利用できるクリーンな CloudFormation スタックが必要になります。私にとって、これは展開の単位として VPC を使用するか、展開の単位としてアカウントを使用するかのいずれかを意味します。どちらの場合も、制限に注意する必要があります。VPC 内で大規模なサブネットを使用するか、サブネットごとに分割すると、最終的にはメンテナンスが面倒になります - これは私の主観的な見解です。