AWS VPC設計入門｜サブネット・セキュリティグループ・NATの基礎ハンズオン

この記事のポイント

・VPCのCIDRは作成後に変更できない——最初に余裕を持った/16で設計することが鉄則
・サブネットはパブリック（ALB）・アプリプライベート（EC2）・DBプライベート（RDS）の3層に分ける
・セキュリティグループはALB-SG→EC2-SG→RDS-SGの順にSG参照で連携させる
・S3・DynamoDB向けGateway型VPCエンドポイント（無料）でNATゲートウェイのコストを削減できる
・VPCフローログでACCEPT/REJECTを記録し、SG/NACLの設定検証と通信監査に活用する

# 10.0.1.0/24 サブネットで予約されるIPアドレス
10.0.1.0    ネットワークアドレス
10.0.1.1    VPCルーター（デフォルトゲートウェイ）
10.0.1.2    Amazon DNSサーバー
10.0.1.3    AWSが将来の利用のために予約
10.0.1.255  ブロードキャストアドレス（AWSでは使用不可）

# → 実際に使えるIPは 10.0.1.4 ～ 10.0.1.254 の 251個

# VPC全体：10.0.0.0/16（65,536アドレス）

# AZ1（ap-northeast-1a）ブロック：10.0.0.0/18（16,384アドレス）
10.0.1.0/24   public-subnet-1a    （ALB・NATゲートウェイ）
10.0.11.0/24  app-prv-1a          （EC2アプリ層・Lambda）
10.0.21.0/24  db-prv-1a           （RDS DB層）

# AZ2（ap-northeast-1c）ブロック：10.0.64.0/18（16,384アドレス）
10.0.65.0/24  public-subnet-1c    （ALB・NATゲートウェイ）
10.0.75.0/24  app-prv-1c          （EC2アプリ層・Lambda）
10.0.85.0/24  db-prv-1c           （RDS DB層）

# 予備：10.0.128.0/17（将来の追加サブネット・3AZ拡張用）

# 3AZ構成（推奨）：3AZ × 3役割 = 9サブネット
# VPC: 10.0.0.0/16  (prod-vpc)

# パブリックサブネット（ALB・NATゲートウェイ配置）
pub-1a:  10.0.0.0/24   ap-northeast-1a
pub-1c:  10.0.1.0/24   ap-northeast-1c
pub-1d:  10.0.2.0/24   ap-northeast-1d

# プライベートサブネット（EC2・ECS・Lambda配置）
priv-1a: 10.0.10.0/24  ap-northeast-1a
priv-1c: 10.0.11.0/24  ap-northeast-1c
priv-1d: 10.0.12.0/24  ap-northeast-1d

# DBサブネット（RDS・ElastiCache配置）
db-1a:   10.0.20.0/24  ap-northeast-1a
db-1c:   10.0.21.0/24  ap-northeast-1c
db-1d:   10.0.22.0/24  ap-northeast-1d

# 将来の追加分（管理・検査用に予約）
mgmt:    10.0.30.0/24 ～ 10.0.39.0/24

# VPCを作成する（東京リージョン・ap-northeast-1を前提）
$ aws ec2 create-vpc   --cidr-block 10.0.0.0/16   --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=prod-ap-northeast-1-vpc}]'

# 実行結果（抜粋）
{
    "Vpc": {
        "VpcId": "vpc-0a1b2c3d4e5f60001",
        "CidrBlock": "10.0.0.0/16",
        "State": "available"
    }
}

# VPCのDNSホスト名を有効にする（RDSのエンドポイント名解決に必要）
$ aws ec2 modify-vpc-attribute   --vpc-id vpc-0a1b2c3d4e5f60001   --enable-dns-hostnames

# ルートテーブルに以下のルートを追加する
# 送信先: 0.0.0.0/0  →  ターゲット: インターネットゲートウェイ（igw-xxxxxxxxx）
# これによりパブリックサブネット内のインスタンスはインターネットと通信可能になる

# また、EC2インスタンスには「パブリックIPの自動割り当て」を有効にする
# または Elastic IP（固定パブリックIP）を割り当てる

# アプリ層用プライベートサブネット（ap-northeast-1a）
$ aws ec2 create-subnet   --vpc-id vpc-0a1b2c3d4e5f60001   --cidr-block 10.0.11.0/24   --availability-zone ap-northeast-1a   --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=app-prv-1a}]'

# アプリ層用プライベートサブネット（ap-northeast-1c）
$ aws ec2 create-subnet   --vpc-id vpc-0a1b2c3d4e5f60001   --cidr-block 10.0.12.0/24   --availability-zone ap-northeast-1c   --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=app-prv-1c}]'

# DB層用プライベートサブネット（ap-northeast-1a）
$ aws ec2 create-subnet   --vpc-id vpc-0a1b2c3d4e5f60001   --cidr-block 10.0.21.0/24   --availability-zone ap-northeast-1a   --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=db-prv-1a}]'

# DB層用プライベートサブネット（ap-northeast-1c）
$ aws ec2 create-subnet   --vpc-id vpc-0a1b2c3d4e5f60001   --cidr-block 10.0.22.0/24   --availability-zone ap-northeast-1c   --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=db-prv-1c}]'

# 環境ごとにVPCを分けてCIDRを管理する例（第2オクテットで環境を区別）
本番VPC          10.0.0.0/16   (ap-northeast-1)
ステージングVPC   10.1.0.0/16   (ap-northeast-1)
開発VPC           10.2.0.0/16   (ap-northeast-1)
DR用VPC           10.3.0.0/16   (ap-northeast-3)

# インバウンドルール（受信許可）設定例（Webサーバー用セキュリティグループ）
# ルール1: HTTP (TCP 80)   送信元: 0.0.0.0/0  インターネットからのアクセスを許可
# ルール2: HTTPS (TCP 443) 送信元: 0.0.0.0/0  HTTPS接続を許可
# ルール3: SSH (TCP 22)    送信元: 203.0.113.50/32  自分のPCのIPアドレスのみ許可

# アウトバウンドルール（送信許可）
# デフォルト: すべてのアウトバウンドを許可（0.0.0.0/0）
# ステートフルのため、インバウンドで受けた通信のレスポンスは別途許可不要

# DBサーバーのセキュリティグループのインバウンドルール
# ポート: MySQL/Aurora (TCP 3306)
# 送信元: sg-0123456789abcdef0 (Webサーバー用セキュリティグループのID)
# →「WebサーバーのSGがアタッチされたインスタンスからのみ3306番を許可」という意味
# IPアドレスではなくSGを参照することで、インスタンスのIP変動に依存しない柔軟な設計になる

# Lambda関数用SGの例（外部からの着信がないリソースはインバウンド不要）
# sg-lambda: インバウンドルール=なし、アウトバウンドルール=すべて許可
# sg-rds:    インバウンド TCP 3306  送信元: sg-lambda  ← LambdaからDBへの接続を許可

# ステップ1: ALB-SG（インターネットからHTTPS/HTTPを受け付ける）
$ aws ec2 create-security-group   --group-name alb-sg   --description "SG for ALB web layer"   --vpc-id vpc-0a1b2c3d4e5f60001
# 実行結果: {"GroupId": "sg-0alb1234567890ef0"}

# インターネットからHTTPS（443）とHTTP（80）を許可する
$ aws ec2 authorize-security-group-ingress   --group-id sg-0alb1234567890ef0   --protocol tcp --port 443 --cidr 0.0.0.0/0
$ aws ec2 authorize-security-group-ingress   --group-id sg-0alb1234567890ef0   --protocol tcp --port 80 --cidr 0.0.0.0/0

# ステップ2: EC2-SG（ALB-SGからのみアプリポートを受け付ける）
$ aws ec2 create-security-group   --group-name ec2-app-sg   --description "SG for EC2 app layer"   --vpc-id vpc-0a1b2c3d4e5f60001
# 実行結果: {"GroupId": "sg-0ec21234567890fg0"}

# --source-group でSGIDを指定（IPアドレスではなくSG参照）
$ aws ec2 authorize-security-group-ingress   --group-id sg-0ec21234567890fg0   --protocol tcp --port 8080   --source-group sg-0alb1234567890ef0
# → EC2へのアクセスはALBを経由したものだけに限定される

# ステップ3: RDS-SG（EC2-SGからのみDBポートを受け付ける）
$ aws ec2 create-security-group   --group-name rds-db-sg   --description "SG for RDS DB layer"   --vpc-id vpc-0a1b2c3d4e5f60001
# 実行結果: {"GroupId": "sg-0rds1234567890gh0"}

$ aws ec2 authorize-security-group-ingress   --group-id sg-0rds1234567890gh0   --protocol tcp --port 3306   --source-group sg-0ec21234567890fg0

# ルール確認（IpRangesが空でUserIdGroupPairsのみが正しい状態）
$ aws ec2 describe-security-groups   --group-ids sg-0rds1234567890gh0   --query 'SecurityGroups[0].IpPermissions'

# 通信フロー（プライベートサブネットからインターネットへ）
# プライベートサブネット内のEC2（10.0.11.10）
#   → NATゲートウェイ（パブリックサブネット・10.0.1.x）
#     → インターネットゲートウェイ（IGW）
#       → インターネット（yumリポジトリ等）

# 設定のポイント:
# 1. NATゲートウェイ自体はパブリックサブネットに置く（必須）
# 2. NATゲートウェイにはElastic IP（固定パブリックIP）を割り当てる
# 3. プライベートサブネットのルートテーブルに追加するルート:
#    送信先: 0.0.0.0/0  →  ターゲット: nat-xxxxxxxxxxxxxxxxx

# Step 1: Elastic IPを取得する
# VPCコンソール → Elastic IP → 新しいElastic IPの割り当て

# Step 2: NATゲートウェイを作成する
# VPCコンソール → NATゲートウェイ → NATゲートウェイを作成
# - サブネット: パブリックサブネットを選択（プライベートサブネットではない）
# - 接続タイプ: パブリック
# - Elastic IP割り当てID: Step1で取得したEIPを選択

# Step 3: プライベートサブネットのルートテーブルを更新する
# VPCコンソール → ルートテーブル → プライベートサブネット用ルートテーブルを選択
# → ルートを編集 → ルートの追加
# 送信先: 0.0.0.0/0  /  ターゲット: NATゲートウェイ（nat-xxxxxxxxxxxxxxxxx）

# S3用Gatewayエンドポイントを作成（プライベートサブネットのルートテーブルに自動追加）
$ aws ec2 create-vpc-endpoint   --vpc-id vpc-0a1b2c3d4e5f60001   --service-name com.amazonaws.ap-northeast-1.s3   --route-table-ids rtb-xxxxAZa rtb-xxxxAZc

# DynamoDB用Gatewayエンドポイントも同様に作成する
$ aws ec2 create-vpc-endpoint   --vpc-id vpc-0a1b2c3d4e5f60001   --service-name com.amazonaws.ap-northeast-1.dynamodb   --route-table-ids rtb-xxxxAZa rtb-xxxxAZc

# SSM Parameter Store用Interfaceエンドポイントを作成（Private DNS有効化）
$ aws ec2 create-vpc-endpoint   --vpc-id vpc-0a1b2c3d4e5f60001   --vpc-endpoint-type Interface   --service-name com.amazonaws.ap-northeast-1.ssm   --subnet-ids subnet-app1a subnet-app1c   --security-group-ids sg-0ec21234567890fg0   --private-dns-enabled

# ALBを作成する（2つのパブリックサブネットを指定）
$ aws elbv2 create-load-balancer   --name web-prod-alb   --subnets subnet-0pub1a234567890ab subnet-0pub1c234567890cd   --security-groups sg-0alb1234567890ef0   --scheme internet-facing   --type application

# 実行結果（抜粋）
{
    "LoadBalancers": [{
        "DNSName": "web-prod-alb-1234567890.ap-northeast-1.elb.amazonaws.com",
        "AvailabilityZones": [
            {"ZoneName": "ap-northeast-1a", "SubnetId": "subnet-0pub1a234567890ab"},
            {"ZoneName": "ap-northeast-1c", "SubnetId": "subnet-0pub1c234567890cd"}
        ],
        "State": {"Code": "active"}
    }]
}

# ターゲットグループを作成する（EC2のアプリポート8080に転送）
$ aws elbv2 create-target-group   --name web-prod-tg   --protocol HTTP   --port 8080   --vpc-id vpc-0a1b2c3d4e5f60001   --health-check-path /health   --health-check-interval-seconds 30

# Auto Scalingグループを作成する（2つのプライベートサブネットを指定）
$ aws autoscaling create-auto-scaling-group   --auto-scaling-group-name web-prod-asg   --launch-template LaunchTemplateId=lt-0abcdef1234567890,Version='\'   --min-size 2   --max-size 6   --desired-capacity 2   --vpc-zone-identifier "subnet-0app1a234567890ef,subnet-0app1c234567890gh"   --target-group-arns arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/web-prod-tg/abc   --health-check-type ELB   --health-check-grace-period 60

# EC2インスタンスが2つのAZに分散されているか確認する
$ aws ec2 describe-instances   --filters "Name=tag:aws:autoscaling:groupName,Values=web-prod-asg"   --query 'Reservations[*].Instances[*].{ID:InstanceId,AZ:Placement.AvailabilityZone,State:State.Name}'   --output table

# 実行結果
# +-------------------+------------------+------------------+
# |        AZ         |       ID         |      State       |
# +-------------------+------------------+------------------+
# |  ap-northeast-1a  |  i-0abc1234ef56  |  running         |
# |  ap-northeast-1c  |  i-0def5678gh90  |  running         |
# +-------------------+------------------+------------------+

# 踏み台サーバー経由でプライベートEC2に接続するSSH設定例（~/.ssh/config）

Host bastion
  HostName 203.0.113.10        # 踏み台サーバーのElastic IP
  User ec2-user
  IdentityFile ~/.ssh/mykey.pem

Host private-web
  HostName 10.0.11.20          # プライベートサブネット内のEC2プライベートIP
  User ec2-user
  IdentityFile ~/.ssh/mykey.pem
  ProxyJump bastion

# 使い方（自分のPCから実行）
# $ ssh private-web
# → 踏み台（203.0.113.10）を経由してプライベートEC2（10.0.11.20）に接続される

# フローログレコードの例（v2フォーマット: version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status）

# 203.0.113.45からポート443へのHTTPS通信（ACCEPT）
2 123456789012 eni-0a1b2c3d4e5f 203.0.113.45 10.0.1.50 52341 443 6 15 1823 1688000000 1688000059 ACCEPT OK

# 198.51.100.22からSSH（22番ポート）への接続試行（REJECT）
# → SGでSSHの送信元IPが制限されているため弾かれた
2 123456789012 eni-0a1b2c3d4e5f 198.51.100.22 10.0.1.50 54321 22 6 3 180 1688000000 1688000059 REJECT OK

# EC2（10.0.1.50）からRDS（10.0.2.30）の3306番への通信（ACCEPT）
# → プライベートサブネット間の正常な通信
2 123456789012 eni-0a1b2c3d4e5f 10.0.1.50 10.0.2.30 49152 3306 6 8 1024 1688000000 1688000059 ACCEPT OK

# CIDRブロック管理台帳（例）
環境              CIDR           リージョン/拠点
--------------------------------------------------
本番 (AWS)        10.0.0.0/16    ap-northeast-1 本番VPC
ステージング      10.1.0.0/16    ap-northeast-1 ステージングVPC
開発              10.2.0.0/16    ap-northeast-1 開発VPC
DR (AWS)          10.3.0.0/16    ap-northeast-3 DR用VPC
オンプレ拠点A     10.100.0.0/16  東京データセンター
オンプレ拠点B     10.101.0.0/16  大阪データセンター
将来予備          10.10.0.0/16   未使用（拡張用）

# アカウント内のVPC一覧とCIDRブロックを表示する（デフォルトVPCを除外）
# requires: aws configure 設定済み・ec2:DescribeVpcs 権限が必要
$ aws ec2 describe-vpcs     --filters Name=isDefault,Values=false     --query 'Vpcs[*].{VpcId:VpcId,CIDR:CidrBlock,Name:Tags[?Key==]|[0].Value,State:State}'     --output table

# 実行結果の例
# +--------------+-------------+----------+----------------------+
# |    CIDR      |    Name     |  State   |       VpcId          |
# +--------------+-------------+----------+----------------------+
# | 10.0.0.0/16 | prod-vpc    | available| vpc-0a1b2c3d4e5f60001|
# | 10.1.0.0/16 | stg-vpc     | available| vpc-0b2c3d4e5f670002 |
# | 10.2.0.0/16 | dev-vpc     | available| vpc-0c3d4e5f67890003 |
# +--------------+-------------+----------+----------------------+
# 環境ごとに第2オクテットが異なることをひと目で確認できる

# 特定VPCのサブネット一覧（AZとCIDRをまとめて確認）
$ aws ec2 describe-subnets     --filters Name=vpc-id,Values=vpc-0a1b2c3d4e5f60001     --query 'Subnets[*].{AZ:AvailabilityZone,CIDR:CidrBlock,Name:Tags[?Key==]|[0].Value,Public:MapPublicIpOnLaunch}'     --output table

# ピアリング前のCIDR重複チェック（既存ピアリング接続のCIDRを確認）
$ aws ec2 describe-vpc-peering-connections     --query 'VpcPeeringConnections[*].{Status:Status.Code,Requester:RequesterVpcInfo.CidrBlock,Accepter:AccepterVpcInfo.CidrBlock}'     --output table

# チェックリスト（上から順に確認する）

# 1. NATゲートウェイが「利用可能」状態か確認
# AWSコンソール → VPC → NATゲートウェイ → ステータスを確認

# 2. プライベートサブネットのルートテーブルを確認
# 「0.0.0.0/0 → nat-xxxxxxxxxx」のルートが存在するか確認

# 3. NATゲートウェイがパブリックサブネットに配置されているか確認
# NATゲートウェイがプライベートサブネットに作られているとアウトバウンドが通らない

# 4. EC2からpingで確認
# $ ping 8.8.8.8
# → 到達できれば外部通信OK。できなければルートテーブルかセキュリティグループを再確認

# 5. フローログが有効な場合：プライベートサブネットのENIのフローログを確認
# EC2からNATゲートウェイへの通信がACCEPTされているか確認する

# 自分のPCの現在のグローバルIPアドレスを確認する
$ curl -s https://checkip.amazonaws.com
203.0.113.50

# このIPアドレスをセキュリティグループのインバウンドルールに設定する
# 送信元: 203.0.113.50/32  ポート: SSH(22)

# フローログが有効な場合：踏み台サーバーのENIのフローログで
# 自分のIPからSSH（22番）への通信がREJECTされていないか確認する

# RDS-SGの設定確認（UserIdGroupPairsにEC2-SGのみが入っているか）
$ aws ec2 describe-security-groups   --group-ids sg-0rds1234567890gh0   --query 'SecurityGroups[0].IpPermissions[?FromPort==]'

# RDSのエンドポイントDNS名を名前解決して疎通確認する
$ nslookup web-prod-mysql.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
# プライベートIP（10.0.21.x）が返れば名前解決は正常
# 失敗する場合はVPCのenableDnsHostnames/enableDnsSupportを確認する

$ aws ec2 describe-vpc-attribute   --vpc-id vpc-0a1b2c3d4e5f60001   --attribute enableDnsHostnames

# 確認1: EC2-SGでALB-SGからのアクセスが許可されているか
$ aws ec2 describe-security-groups   --group-ids sg-0ec21234567890fg0   --query 'SecurityGroups[0].IpPermissions'
# ポート8080・送信元sg-0alb1234567890ef0 のルールが存在するか確認する

# 確認2: EC2上でアプリが指定ポートでlistenしているか
# （AWS Systems Manager Session Managerでポート確認）
$ ss -tlnp | grep 8080
# 正常時の出力例:
# LISTEN  0  128  0.0.0.0:8080  0.0.0.0:*  users:(("java",pid=1234,fd=42))
# 何も返らない場合はアプリが起動していないか別ポートでlistenしている

# 確認3: ヘルスチェックパスが200を返すか
$ curl -o /dev/null -s -w "%{http_code}" http://localhost:8080/health
# 200が返れば正常。200以外ならアプリのヘルスチェック実装を確認する