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 の制約はエイリアスレコードで解決する。
目次 12 sections
- 01 セキュリティグループと NACL
- 02 プライベートサブネットのアウトバウンド
- 03 VPC エンドポイント(PrivateLink)
- 04 VPC フローログの読み方
- 05 Transit Gateway と VPC ピアリング
- 06 Route 53
- ルーティングポリシー
- エイリアスレコードと Zone Apex
- Route 53 Resolver(ハイブリッド DNS)
- 07 Direct Connect と VPN の冗長化
- 08 CloudFront
- 3 コンポーネントの分離
- 1 ビヘイビア = 1 パスパターン
- 複数オリジンの使い分け
- 09 ロードバランサー
- 10 EKS のエンドポイント
- 11 関連
- 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 には使えない
VPC エンドポイント(PrivateLink)
- 閉域から Secrets Manager / SSM / AMP などの AWS サービスに届かせるには、インターフェイス型エンドポイントを作り「プライベート DNS」を有効にする。アプリの接続先 URL を変えずに AWS バックボーン内で完結する
- NAT 経由だとデータ処理料金が乗る。プライベートサブネットからの AWS サービス通信はエンドポイントで NAT 課金を避けるのが定石
- SSM に必要なエンドポイントは
ssm/ssmmessages/ec2messagesの 3 つ
VPC フローログの読み方
action(通信の結果)と log-status(ログ出力自体の健全性)は独立している。
| 状況 | action | log-status |
|---|---|---|
| セキュリティルールで拒否された | REJECT | OK |
| 許可された | ACCEPT | OK |
| 集約期間中に通信が一切なかった | - | 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 → オンプレ DNS | VPC 内の 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 のエンドポイント
| 種別 | 挙動 |
|---|---|
| Public | API サーバーへ常にインターネット経由。CIDR 制限が必須 |
| Public and Private | VPC 外からはパブリック、VPC 内からはプライベートホストゾーン経由でプライベート IP に解決 |
| Private | インターネット経由不可。VPC 内または接続済みネットワークから EKS 所有の ENI 経由 |
セキュリティグループはコントロールプレーン用の「クラスター SG」とデータプレーン用の「ノード SG」に分かれ、ノード間通信などはデフォルトで許可済み。不要な手動変更を提案する選択肢は落とす。
関連
- AWS のアクセス制御と監査の判断基準(RAM のサブネット共有、ACM)
- バックアップ・DR・可用性設計(DR と Route 53)
- コンテナ監視の設計
- AWS コスト最適化の判断基準
- SOA-C03 の試験構成と学習の進め方
更新履歴
- 2026-07-18: 初版(ローカル調査ノート)
- 2026-10-17: Wiki へ移植、概念ページとして再構成。冒頭に定義を追加
同じトピック — AWS
- バックアップ・DR・可用性設計の判断基準(RTO/RPO・AWS Backup・RDS/Aurora・Auto Scaling)
- CloudFormation と CDK によるデプロイ設計(変更セット・DeletionPolicy・StackSets・Construct)
- CloudWatch の監視設計(メトリクス階層・アラーム・ログ分析の使い分け)
- コンテナ監視の設計(AMP / Managed Grafana / CloudWatch Observability / Fargate の制約)
- AWS コスト最適化の判断基準(購入オプション・Savings Plans・Cost Explorer・インスタンス選定)
- EventBridge と自動修復の設計パターン
- AWS のアクセス制御と監査の判断基準(IAM / SCP / KMS / CloudTrail)
- SOA-C03(AWS Certified CloudOps Engineer - Associate)の試験構成と学習の進め方
- Systems Manager の運用自動化(マネージドノード・Run Command・Automation・Patch Manager)