Amazon VPCのステージング環境はどこにセットアップする必要がありますか？そしてテスト？
オレゴンのAmazonVPCでサービスの本番環境をセットアップします。
- 2つのアベイラビリティーゾーン
- 各アベイラビリティーゾーンに1つのパブリックサブネット（要塞、NAT、ELBを含む）と3つのプライベートサブネット（データベース、Webサーバー、構成/監視）。
- 11のセキュリティグループ
現在、約25のVMがあり、うまくいけばそれは成長するでしょう。
次に、ステージング環境をセットアップしますが、どこに配置するかわかりません。
- 単純に本番インスタンスの隣にステージングインスタンスを配置する？基本的に、同じAmazonリージョン、同じアベイラビリティーゾーン、同じサブネット、同じセキュリティグループを再利用するだけですか？ステージングインスタンスを指す新しいELBを作成する必要があるだけで、それだけです。シンプル。
- または、ステージングインスタンスを独自のサブネットに配置するである必要がありますが、それでも同じリージョン/アベイラビリティーゾーンにありますか？ただし、単一のアベイラビリティーゾーンに2つのパブリックサブネットを含めることはできないため、パブリックサブネットは同じである必要があります。サブネットを分離すると、管理が容易になる可能性があります。また、専用のルーティングルールを使用して、さまざまなnatインスタンスや、場合によってはさまざまな要塞を通過することもできます。より複雑ですが、セキュリティは厳しくなります。ただし、本番サブネットとステージングサブネット間のトラフィックを禁止する単一の全体的なネットワークACLを持つことができるため、セキュリティグループを2倍にする必要はないと思います。
- または私はセットアップ全体を別のVPCに複製する？ Amazonリージョンごとに1つのVPCしか持てないため、これは別のリージョンで行う必要があります。
ステージング環境の全体的なポイントは、本番環境と同一（または可能な限り近い）にすることです。したがって、別のアマゾン地域でステージング環境を設定するのは間違っていると感じます。これにより、オプション3が除外されますね。
オプション1は、可能な限り本番環境に近づけるという目標に最も近いものです。しかし、同じサブネット内にステージング環境と本番環境があると、潜在的なセキュリティ問題のように感じますよね？したがって、私はオプション2にいくらか傾いていますが、潜在的なセキュリティの問題が、管理するサブネットの数が2倍になることを正当化するほど深刻であるかどうか疑問に思います。
そして、テスト環境はどうですか？これも本番環境に似ている必要がありますが、それほど厳密に一致する必要はありません。すべてがいくつかのインスタンスに収まり、ELBなどすべてが必要ありません。おそらく、この環境はすべて、同じVPC内の単一の専用サブネットに収まる可能性がありますか？同じVPC内にあるため、gitリポジトリとchefサーバー、監視ツール、openvpnアクセスなどに簡単にアクセスできます。
多くの人がこれらの考慮事項を経験していると確信していますか？これについてどう思いますか？
ありがとう。
オプション3が最適な分離レベルであり、ステージング環境の変更による本番環境への影響を防ぎます。また、リージョンごとに1つのVPCを想定するのは間違っているようです。私の知る限り、リージョン内に複数のVPCを作成できます。
「Amazonリージョンごとに1つのVPCしか持てないので、別のリージョンでこれを行う必要があります。」
オプション2を使用することをお勧めします。 AWSインフラストラクチャが成長するにつれて、ディレクトリサービス（ネームサーバー、ユーザーディレクトリ、VMディレクトリ、ルックアップサービスなど）が必要になります）。2つのVPCがある場合、ディレクトリサービスの共有は簡単ではありません。 。また、DEV用に3つの別々のVPCを持つコードリポジトリ（GitHubなど）またはビルドツール（Jenkinsなど）が必要な場合、ステージングとプロダクションは物事を非常に複雑にします。
環境ごとに個別のvpcをお勧めします。すべての共有リソースを共有vpcに配置し、各環境間で共有vpcをピアリングできます。