VPC

VPC とは

VPC (Virtual Private Cloud) は、AWS 上に論理的に隔離されたプライベートネットワークを構築するサービスである。IP アドレス範囲、サブネット、ルートテーブル、セキュリティグループを自由に設定し、リソースのネットワーク環境を制御する。

VPC の構成要素

構成要素は機能の寄せ集めではなく、経路を決めるものと通信の可否を決めるものに分かれる。ルートテーブルとゲートウェイ類がパケットの行き先を決め、セキュリティグループとネットワーク ACL がその経路上で通していいかを判定する。片方だけでは通信は成立しない。

予約アドレスは設計に効いてくる。10.0.0.0/24 を切ると使えるのは 251 個で、最小の /28 では 16 個のうち 11 個しか残らない。ネットワークアドレス、VPC ルーター、DNS 用、将来のための予約、ブロードキャスト相当の 5 つが持っていかれるためで、/28 を並べる設計は増設余地をほとんど持たない。

典型的な構成

2 つの AZ にパブリックとプライベートを 1 組ずつ置く形が出発点になる。同じ役割のサブネットを AZ ごとに用意するのは、ALB や RDS のマルチ AZ 構成がサブネットを AZ 単位で要求するためだ。

VPC (10.0.0.0/16)
├── パブリックサブネット (10.0.1.0/24) - AZ-a
│   ├── ALB
│   └── NAT Gateway
├── パブリックサブネット (10.0.2.0/24) - AZ-c
│   └── ALB
├── プライベートサブネット (10.0.10.0/24) - AZ-a
│   ├── Lambda
│   └── RDS (プライマリ)
└── プライベートサブネット (10.0.20.0/24) - AZ-c
    ├── Lambda
    └── RDS (スタンバイ)

パブリック vs プライベートサブネット

パブリックとプライベートは、サブネットに設定できる属性ではない。関連付けられたルートテーブルに 0.0.0.0/0 の宛先としてインターネットゲートウェイが載っているかどうかだけの違いで、その 1 行を差し替えればパブリックはプライベートになる。プライベート側では同じ 0.0.0.0/0 の向き先が NAT ゲートウェイ (IPv6 なら egress-only インターネットゲートウェイ) になり、VPC 内部宛ての local 行はどちらの表にも入っている。

「プライベートに置いたから外部から触られない」と読み替えるのは危険だ。インターネットからの直接の着信路が無いだけで、VPN や Direct Connect、VPC ピアリング、パブリックサブネットの ALB を経由した通信は届く。逆にパブリックサブネットへ置いただけで公開されるわけでもなく、パブリック IPv4 アドレスが割り当てられていて、かつセキュリティグループが通していなければ外からは到達しない。到達できるかどうかを決めるのは経路とファイアウォールの両方である。

そのパブリック IPv4 アドレスには 2024 年 2 月 1 日から課金がある。使用中かどうかに関わらず 1 アドレスあたり 1 時間 $0.005 (2026 年 8 月時点) で、ALB の背後に並べた EC2 にまでパブリック IP を付けている構成は台数分そのまま費用になる。VPC / サブネット / ルートテーブル / インターネットゲートウェイを作ること自体には料金がかからず、費用が生まれるのは NAT ゲートウェイ、インターフェース型 VPC エンドポイント、パブリック IPv4 アドレス、そして AZ やリージョンを跨ぐデータ転送で、箱ではなく出口と経路に課金される。

Lambda と VPC

Lambda を VPC 内に配置すると、プライベートサブネットの RDS や ElastiCache にアクセスできる。VPC に収容すること自体に料金はかからない。費用が生まれるのは、その関数が IPv4 でインターネットへ出る必要があり、そのために NAT ゲートウェイ を立てるときだ。触る相手が S3 と DynamoDB だけならゲートウェイ型の VPC エンドポイントで足りる。

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    VpcConfig:
      SubnetIds:
        - !Ref PrivateSubnet1
        - !Ref PrivateSubnet2
      SecurityGroupIds:
        - !Ref LambdaSG

VPC エンドポイント

NAT ゲートウェイを経由せずに、VPC 内から AWS サービスへプライベート接続する。ゲートウェイ型はルートテーブルに宛先プレフィックスリストの行が足される方式、インターフェース型はサブネット内に ENI が作られてそのサービスの DNS 名がそこへ向く方式で、仕組みが違うため料金の形も違う (VPC エンドポイント)。

セキュリティグループ

セキュリティグループは ENI 単位のファイアウォールで、インバウンド (受信) とアウトバウンド (送信) のトラフィックを制御する。許可ルールのみを定義するホワイトリスト方式で、明示的に許可されていないトラフィックはすべて拒否される。IP アドレスの代わりにセキュリティグループ同士を参照できるため、スケールアウトで入れ替わるインスタンスの IP を追いかけずに「この層からこの層へ」という形で許可を書ける。

LambdaSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    VpcId: !Ref VPC
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 5432
        ToPort: 5432
        DestinationSecurityGroupId: !Ref RDSSG  # RDS への接続のみ許可

セキュリティグループとネットワーク ACL

2 つのファイアウォールで最も混乱しやすいのは、戻りの通信の扱いである。セキュリティグループはステートフルで通信の状態を覚えているため、インバウンドで許可した通信の応答はアウトバウンドのルールに関係なく戻れる。ネットワーク ACL はステートレスで状態を持たないので、行きを許可しただけでは応答が戻らず、戻り方向のエフェメラルポートを明示的に開けておく必要がある。

ネットワーク ACL の規則番号は 1 から 32766 までで、小さい番号から順に評価して一致した時点で判定が終わる。後ろに厳しいルールを書いても手前の許可で確定してしまうため、番号の間隔を空けて並べる。拒否を書けるのは ACL だけなので、特定の送信元だけを落としたい場面ではこちらを使う。ただし戻り方向の穴あけを忘れると、行きは通って応答だけが落ちるという切り分けにくい症状になる。通常の制御はセキュリティグループで行い、ネットワーク ACL はサブネット全体へ効かせたい遮断に限って使うのが素直だ。

VPC の背景や設計思想は関連書籍に詳しい。