VPC ネットワークとコンテンツ配信の設計判断(SG / NACL / NAT / TGW / CloudFront / Route 53)

一言まとめ

SG はステートフルで Allow のみ、NACL はステートレスで Deny も書ける。IPv4 の出口は NAT Gateway、IPv6 は無料の Egress-Only IGW。VPC が 10 個未満ならピアリング、以上なら Transit Gateway。CloudFront はオリジンとビヘイビアを分離する。Zone Apex に CNAME を置けない DNS の制約はエイリアスレコードで解決する。

作成 · 更新 · #aws#vpc#cloudfront#route53#soa-c03
目次 12 sections
  1. 01 セキュリティグループと NACL
  2. 02 プライベートサブネットのアウトバウンド
  3. 03 VPC エンドポイント(PrivateLink)
  4. 04 VPC フローログの読み方
  5. 05 Transit Gateway と VPC ピアリング
  6. 06 Route 53
  7. ルーティングポリシー
  8. エイリアスレコードと Zone Apex
  9. Route 53 Resolver(ハイブリッド DNS)
  10. 07 Direct Connect と VPN の冗長化
  11. 08 CloudFront
  12. 3 コンポーネントの分離
  13. 1 ビヘイビア = 1 パスパターン
  14. 複数オリジンの使い分け
  15. 09 ロードバランサー
  16. 10 EKS のエンドポイント
  17. 11 関連
  18. 12 更新履歴

調査時点: 2026-07。料金は当時の値。

Amazon VPC(Virtual Private Cloud)は、AWS 上に作る論理的に分離された仮想ネットワーク。内部をサブネットに分け、経路と通信許可を設定する。SG(セキュリティグループ)と NACL(ネットワーク ACL)はその中の通信許可の仕組み。

セキュリティグループと NACL#

比較セキュリティグループネットワーク ACL
適用範囲インスタンス(ENI)単位サブネット単位
状態ステートフル(インバウンド許可の戻りは自動許可)ステートレス(行きと戻りを個別に許可)
ルールAllow のみAllow と Deny
使う場面ポートごとの通信許可特定 IP 帯を明示的にブロックしたいとき

プライベートサブネットのアウトバウンド#

比較NAT ゲートウェイEgress-Only インターネットゲートウェイ
プロトコルIPv4 専用IPv6 専用
料金時間単価 + データ処理量無料
役割内→外の通信を中継内→外のみ許可し、外→内を遮断
  • NAT ゲートウェイはパブリックサブネットに置き、Elastic IP を付け、プライベートサブネットのルートテーブルの 0.0.0.0/0 を NAT に向ける。プライベートサブネットに置いても外に出られない
  • マルチ AZ では AZ ごとにパブリックサブネットへ NAT を置き、同 AZ のプライベートから向ける(単一障害点の排除)
  • VPC エンドポイント(PrivateLink)は AWS 内の対応サービス宛て専用で、インターネット上のサードパーティ API には使えない
  • 閉域から Secrets Manager / SSM / AMP などの AWS サービスに届かせるには、インターフェイス型エンドポイントを作り「プライベート DNS」を有効にする。アプリの接続先 URL を変えずに AWS バックボーン内で完結する
  • NAT 経由だとデータ処理料金が乗る。プライベートサブネットからの AWS サービス通信はエンドポイントで NAT 課金を避けるのが定石
  • SSM に必要なエンドポイントは ssm / ssmmessages / ec2messages の 3 つ

VPC フローログの読み方#

action(通信の結果)と log-status(ログ出力自体の健全性)は独立している。

状況actionlog-status
セキュリティルールで拒否されたREJECTOK
許可されたACCEPTOK
集約期間中に通信が一切なかった-NODATA
高負荷などで一部を記録できなかった-SKIPDATA

「ログが見当たらない」ときに即「通信が来ていない」と断定しない。NODATA なら経路やクライアント側を疑い、SKIPDATA なら集約間隔を縮めて再テストする。WAF でブロックされたリクエストの特定は WAF のウェブ ACL ログ。

Transit Gateway と VPC ピアリング#

ピアリングが勝つ 4 条件: コスト最優先(ピアリングは無料、TGW は当時アタッチメントあたり約 36 USD/月 + 1GB あたり 0.02 USD)、1ms 未満の超低遅延(TGW は 1 ホップ増える)、帯域上限なしが要る(TGW はアタッチメントごとに上限)、VPC が 3 個以下。

目安は 10。VPC が 10 個未満ならピアリング、10 個以上ならフルメッシュの接続数が爆発するので TGW のハブ&スポークに統合する。

Route 53#

ルーティングポリシー#

ポリシー基準向く場面
フェイルオーバーヘルスチェックの結果Active / Passive の DR。カスタムの Lambda で DNS を書き換える構成は選ばない
位置情報(Geolocation)ユーザーの国・大陸・州日本からは日本語ページ、のように言語圏で振り分け
地理的近接性(Geoproximity)ユーザーとリソースの物理距離 + バイアスTraffic Flow で守備範囲を広げ縮めする
レイテンシー最小遅延のリージョン平常時から全リージョンを使う構成。Passive リージョンに流れるので DR には不向き
加重重みカナリアや段階移行

エイリアスレコードと Zone Apex#

DNS の仕様上、Zone Apex(サブドメインを付けないドメイン名。www.example.com ではなく example.com のほう)に CNAME は置けない。ALB や CloudFront は固定 IP を持たず DNS 名しか提供しないため、Apex を向けたくても A レコードも CNAME も使えないことになる。Route 53 のエイリアスレコードはこの制約を回避する独自機能で、Apex でも ALB / S3 / CloudFront の DNS 名に直接マッピングでき、外からは A レコードとして返る。エイリアスへのクエリは無料。

ALB と連動させるときは「エイリアス + ターゲットのヘルスの評価(Evaluate Target Health)= はい」。Route 53 のヘルスチェック費用を使わずに ALB 側の健全性を反映でき、DB などの依存関係はアプリに /health を用意して ALB のターゲットグループで見る。

単一 EC2 の終了を見る CloudWatch アラームだけでリージョンフェイルオーバーを決めない。ELB 配下のアプリ全体の応答性はエンドポイントへのヘルスチェックで評価する。

Route 53 Resolver(ハイブリッド DNS)#

エンドポイント向き用途
Inboundオンプレ DNS → VPCオンプレのサーバーから VPC のプライベートホストゾーン名を解決
Outbound + 転送ルールVPC → オンプレ DNSVPC 内の EC2 から corp.internal のようなオンプレドメインを解決。ルールを VPC に関連付ける

Direct Connect と VPN の冗長化#

  • 平常時は Direct Connect、障害時のみ Site-to-Site VPN に落としたいなら、BGP の AS-Path Prepending で VPN 側の経路にダミーの AS 番号を足して経路長を長く見せる。オンプレ側は短い DX を自律的に優先する
  • 1 本の DX を複数 VPC につながった Transit Gateway に接続するには Transit VIF。VPC が増えるたびに Private VIF を作らずに済む

CloudFront#

3 コンポーネントの分離#

コンポーネント役割
ディストリビューション窓口となるドメイン名
オリジン物理的な接続先(S3、ALB、API Gateway)を 1 か所で定義
キャッシュビヘイビアパスパターン(/images/*)をトリガーに TTL・WAF・HTTPS 強制を定義し、どのオリジンへ送るかをマッピング

接続先が変わってもオリジン定義を 1 か所直せば、それを参照する全ビヘイビアに反映される。同じ S3 に対してフォルダごとに TTL の違うビヘイビアを並べられる。

1 ビヘイビア = 1 パスパターン#

ビヘイビアは優先順に上から評価され、最初にマッチしたものが適用される。複数パスに同じルールを当てたいときは、同内容のビヘイビアを複数並べるか、URL を /assets/* のように統一してパターンを 1 つに集約する。

複数オリジンの使い分け#

  • 静的コンテンツは S3、動的 API は ALB にパスで振り分けるのはビヘイビアの仕事
  • S3 への直接アクセスを防ぐには Origin Access Control(OAC)を有効にし、バケットポリシーで CloudFront からのみ許可する
  • オリジングループはプライマリの 5xx 時にセカンダリへ逃がすフェイルオーバー用で、定常のパス振り分けには使わない
  • 署名付き URL はアクセス制限(会員限定など)の機能で、振り分けには無関係。X-Forwarded-For はクライアント IP のヘッダーでルーティング機能はない

ロードバランサー#

  • NLB のクロスゾーン負荷分散はデフォルト無効。「AZ 間でターゲット数に偏りがある」「片方の AZ が全滅するとクライアントがタイムアウトする」なら明示的に有効化する。ALB は最初から有効
  • 単一 AZ 構成をマルチ AZ 化するには、Auto Scaling グループと ALB の両方に別 AZ のサブネットを追加する

EKS のエンドポイント#

種別挙動
PublicAPI サーバーへ常にインターネット経由。CIDR 制限が必須
Public and PrivateVPC 外からはパブリック、VPC 内からはプライベートホストゾーン経由でプライベート IP に解決
Privateインターネット経由不可。VPC 内または接続済みネットワークから EKS 所有の ENI 経由

セキュリティグループはコントロールプレーン用の「クラスター SG」とデータプレーン用の「ノード SG」に分かれ、ノード間通信などはデフォルトで許可済み。不要な手動変更を提案する選択肢は落とす。

関連#

更新履歴#

  • 2026-07-18: 初版(ローカル調査ノート)
  • 2026-10-17: Wiki へ移植、概念ページとして再構成。冒頭に定義を追加

同じトピック — AWS