役割ごとに分離することで、 インターネット公開範囲や通信制御を整理しやすくなります。

Public Subnetからインターネットへ向かう通信は、 インターネット接続用ゲートウェイへ転送します。

PrivateなApplication Subnetでは、 デフォルトルートをNAT Gatewayへ向けます。

これにより、 Applicationサーバーからインターネットへ接続できますが、 インターネット側からApplicationサーバーへ直接新規接続する構成にはしません。

本社LANの 10.10.0.0/16 宛て通信は、 VPNまたは専用線側へルーティングします。

インターネットからのHTTPS通信はロードバランサーで受け、 Private Subnet上の複数Web/Appサーバーへ振り分けます。

1台が停止した場合はヘルスチェックで異常を検知し、 正常なサーバーへ通信を振り分けることで可用性を高めます。

VPNは比較的短期間かつ低コストで導入しやすい一方、 インターネットを経由するため通信品質が外部環境の影響を受けます。

専用線はコストや導入期間が増えるものの、 大容量通信や安定した通信を求める環境に適しています。

重要システムであれば、 「専用線を主系、VPNをバックアップ」とする構成も候補になります。

環境同士をすべて1対1で接続すると、 環境数の増加に伴って接続数、ルート管理、設定変更箇所が増えます。

中央の接続ハブへ通信を集約することで、 新しいネットワークを追加するときの接続関係を整理しやすくなります。

ただし、中央ハブへの依存度や障害影響範囲も考慮する必要があります。

本社PCからの問い合わせを社内DNSが受け、 クラウド側で管理する名前についてはクラウド側DNSへ転送します。

クラウドDNSが app.example.local に対応するアドレスを返し、 その結果を本社PCへ返します。

DNSで名前解決できた後は、 VPNまたは専用線のルーティングを利用して実際の通信を行います。

確認候補の例は次のとおりです。

1. 本社からクラウドへのVPN・専用線接続状態
2. 本社側のクラウド宛てルート
3. クラウド側の本社宛てルート
4. クラウド側セキュリティ制御
5. FW・ACL・セッション情報

今回はクラウド側の 10.10.0.0/16 宛て経路が削除されています。

本社からクラウドへパケットが到達できても、 クラウドから本社へ戻すための経路がないため、 通信の往復が成立しません。

ネットワーク障害では、 往路だけでなく必ず復路も確認する ことが重要です。

クラウド上にあるサーバーをすべてインターネットへ直接公開すると、 本来外部からアクセスさせる必要のないサーバーまで攻撃を受ける入口が増えてしまいます。

そのため、外部から接続を受ける部分だけを公開し、 Webサーバーやデータベースなどは内部側へ配置します。 必要な通信だけを通すことで、万一どこかに問題が発生した場合も影響範囲を小さくできます。