攻撃者がすでにインフラストラクチャへの初期アクセスを獲得している場合、より多くのリソースに攻撃を拡大する (横方向の展開) 能力は、主にネットワークの構造や設定の可視性に左右されます。攻撃者から見て、ネットワーク内の他のリソースがどの程度見えるか、アクセスしやすいかによって、攻撃の広がり方が大きく変わってきます。そのため、影響範囲を減らすには、Virtual Private Cloud (VPC) を使用してネットワークを分離することが重要です。パブリックサブネットにはパブリックアクセスが必要なリソース (公開アプリケーション用の Web サーバーなど) のみを公開し、データベースなどの他のリソースはプライベートネットワークに置きます。
例えば、アプリケーションロードバランサーを使用する Web アプリケーションでは、データベースはプライベートサブネットに配置し、セキュリティグループで Web サーバーのセキュリティグループのみがデータベースに接続できるように指定すべきです。
プライベートサブネット上の Amazon EC2 インスタンスがアップデートのためにインターネットに接続する必要がある場合、NAT ゲートウェイを設定することで、EC2 インスタンスをパブリックサブネットに移動したりパブリック IP アドレスを提供したりすることなく、インターネットへのアウトバウンド通信を許可できます。
ワークロードを複数のアカウントと複数の VPC に分離することで、攻撃と潜在的な影響を単一のアカウントや VPC に抑えることができます。
VPC ピアリングも必要に応じて確立することは問題ありませんが、セキュリティ上の理由から、必要でない場合は VPC ピアリングの使用を制限することが好ましいです。
VPC をオンプレミスのデータセンターに接続する場合、VPN を使用する (理想的には AWS Direct Connect 経由) べきですが、これは VPC がオンプレミスリソースへのアクセスを必要とする場合のみです。将来の使用のためにすべての VPC を接続することは推奨されません。
アカウント内のリソースの競合を避け、アカウント単位のサービス制限の影響を受ける可能性を減らすため、環境 (開発/テスト/本番) を複数のアカウントに分割することをお勧めします。