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

この記事のポイント

・VPCはAWS上の仮想ネットワーク。CIDRブロックで範囲を決める
・サブネットはパブリック（ALB）・アプリプライベート（EC2）・DBプライベート（RDS）の3層に分ける
・セキュリティグループはALB-SG→EC2-SG→RDS-SGの順にSG参照で連携させる
・VPCフローログでACCEPT/REJECTを記録し、SG/NACLの設定検証と通信監査に活用する

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

# インバウンドルール（受信許可）設定例（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変動に依存しない柔軟な設計になる

# ステップ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）

# 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='$Latest'   --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

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

# 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==`3306`]'

# 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以外ならアプリのヘルスチェック実装を確認する