VPCセキュリティ — SG/NACL・Endpoints・Network Firewall

概要：VPCセキュリティの多層防御アーキテクチャ

VPCセキュリティは単一のレイヤーではなく、複数の防御メカニズムを組み合わせた多層防御アーキテクチャとして設計される。SCS-C03では、各レイヤーの動作原理、制約、そしてそれらを組み合わせた実装が問われる。

各レイヤーは独立した評価ロジックを持つため、設定の組み合わせが複雑になる。本講義では、各レイヤーの詳細な挙動、制約、そして正しい組み合わせ方を解説する。

VPCセキュリティレイヤー図

---

Security Groups マネジメントコンソール画面

---

第1層：Security Groups（セキュリティグループ）

ステートフルファイアウォール

Security Groupsはステートフルファイアウォールとして機能する。つまり、インバウンド通信を許可すれば、レスポンスのアウトバウンド通信は自動的に許可される（その逆も同じ）。

クライアント → EC2（インバウンドルール評価）
         → ✓ Permit → Connection established (stateful)
EC2 → クライアント（アウトバウンドルール評価は不要、ステートテーブルで自動許可）

ルール評価の順序

Security Groupのルールはすべてのルールが評価されるわけではなく、以下のロジックで判定される：

1. ルールセット全体が”許可リスト” — 許可ルールのみが存在
2. 最初にマッチしたルールで決定 — ルールの順序は関係ない（全ルールが OR 条件）
3. 明示的な拒否なし — “Deny”ルールは存在しない
4. ステートテーブルに記録された接続は自動許可

設定例:

• インバウンド TCP 443 （HTTPS）：0.0.0.0/0 から許可
• インバウンド TCP 22 （SSH）：管理用セキュリティグループから許可
• アウトバウンド：すべてのプロトコル許可

エフェメラルポートとステートフル接続

クライアントが通信を開始するとき、OSはエフェメラルポート（一時ポート）を自動割り当てする。ステートフルファイアウォールはこの往復を追跡する。

クライアント（エフェメラルポート 52143）→ EC2（ポート 443）

• アウトバウンドルール：ポート 443 許可 → OK
• インバウンドルール：ポート 52143 許可（明示的に必要）

EC2（ポート 443）→ クライアント（エフェメラルポート 52143）

• ステートテーブルで”確立済み接続”として自動許可

エフェメラルポート範囲（Linux）：49152-65535（RFC 6335）。ただし、OSやアプリケーションで異なる場合がある。

試験で狙われるポイント

• ステートテーブルの限界: RTO（Recovery Time Objective）によってステートテーブルエントリは削除される。通常300秒だが、AWSは設定不可
• ICMP の扱い: ICMP は接続指向ではないため、完全なステートフルな追跡ができない。Security GroupではIpProtocol: "icmp"でTypeとCodeを指定
• DNS（UDP 53）の特殊性: DNS応答はランダムなポートから送信される。ステートフルテーブルで追跡されるため、アウトバウンド許可が必要

{
  "IpPermissionsEgress": [
    {
      "IpProtocol": "udp",
      "FromPort": 53,
      "ToPort": 53,
      "CidrIp": "0.0.0.0/0",
      "Description": "DNS queries"
    }
  ]
}

できないこと・制約

---

第2層：Network ACLs（ネットワークアクセスコントロールリスト）

ステートレスファイアウォール

NACLはSubnet単位で適用されるステートレスファイアウォール。インバウンドとアウトバウンドのルールをそれぞれ独立して評価する。

クライアント → Subnet 内のインバウンドルール評価 → EC2
       （明示的に許可ルール必須）

EC2 → Subnet 内のアウトバウンドルール評価 → クライアント
       （明示的に許可ルール必須、レスポンス通信も別ルール）

ルール評価の順序

NACLのルールはルール番号の昇順で評価され、最初にマッチしたルールで確定する。後続のルールは評価されない。

ルール番号は100 単位で設定が推奨（100, 200, 300…）。削除・挿入時の番号管理が容易になる。

エフェメラルポートの明示的許可

ステートレスなため、レスポンス通信も明示的にアウトバウンドルールで許可する必要がある。

インバウンドルール（クライアント → EC2）

• ルール 100: TCP 443 from 0.0.0.0/0 Allow

アウトバウンドルール（EC2 → クライアント）

• ルール 100: TCP 49152-65535 to 0.0.0.0/0 Allow（エフェメラルポート範囲を明示的に許可）
• ルール 200: TCP 0-65535 to 10.0.0.0/8 Allow（内部通信は全ポート許可）

Security Group との比較

試験で狙われるポイント

• 拒否ルールの活用: 特定IPアドレスをブロック（例：DDoS対策）する場合、NACLで拒否ルール使用
• エフェメラルポート範囲の理解: すべてのOSが 49152-65535 を使うわけではない。Windows は 1024-65535 の場合も
• “ALL”プロトコルルール: IpProtocol: "-1"ですべてのプロトコルを指定（ただしルール番号で評価順序制御）

# AWS CLI: NACL に拒否ルール追加
aws ec2 create-network-acl-entry \
  --network-acl-id acl-12345678 \
  --rule-number 50 \
  --protocol tcp \
  --port-range FromPort=22,ToPort=22 \
  --cidr-block 203.0.113.0/24 \
  --egress false \
  --entry-action deny

できないこと・制約

---

第3層：VPC Endpoints

ゲートウェイ型エンドポイント vs インターフェース型エンドポイント

VPC Endpointsは、インターネットを経由せずに AWSサービスへアクセスするための仕組みである。

ゲートウェイ型エンドポイント（S3 / DynamoDB）

Route Table に直接エントリが追加され、ルーティングレベルで通信がリダイレクトされる。

EC2 → Route Table 評価 → VPC Endpoint Gateway → S3
       （s3.us-east-1.amazonaws.com の CIDR プリフィックス）

特徴:

• 料金: 無料（データ転送量に応じた課金のみ）
• 対応サービス: S3, DynamoDB のみ
• ネットワーク設定: Route Table に設定するだけ
• セキュリティ: リソースベースのエンドポイントポリシーで制御

エンドポイントポリシー例:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": "vpc-12345678"
        }
      }
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:DeleteObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

インターフェース型エンドポイント（EC2 / SNS / SQS / RDS / Secrets Manager など）

ENI（Elastic Network Interface）を Subnet に作成し、PrivateLink で接続される。

EC2 → DNS（vpce-1234567890abcdef.ec2.us-east-1.vpce.amazonaws.com）
   → ENI（10.0.1.50）→ AWS service

特徴:

• 料金: 時間単位 + データ処理料金（ゲートウェイ型より高額）
• 対応サービス: ほぼすべての AWS サービス
• ネットワーク設定: Subnet / Security Group で制御
• DNS: Private hosted zone で CNAME 設定可能（AWS-provided DNS も利用可能）

設定例（AWS CLI）:

# インターフェース型エンドポイント作成
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.ec2 \
  --subnet-ids subnet-12345678 subnet-87654321 \
  --security-group-ids sg-0123456789abcdef0 \
  --private-dns-enabled true

Private Hosted Zone 設定（Route 53）:

Name: secretsmanager.us-east-1.amazonaws.com
Type: A
Alias: vpce-12345.vpce.us-east-1.amazonaws.com

エンドポイントポリシーの詳細な評価

エンドポイントポリシーはリソースベースのポリシーで、以下のレイヤーで評価される：

1. VPC Endpoint Policy（最初の関門）
2. IAM Policy（プリンシパルが持つ権限）
3. リソースベースのポリシー（例：S3 Bucket Policy）
4. Security Group（インターフェース型のみ）

すべてのレイヤーで Allow である必要がある

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Principal": "*",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalAccount": "123456789012"
        }
      }
    }
  ]
}

試験で狙われるポイント

• クロスリージョンアクセス: VPC Endpoint はシングルリージョン。別リージョンのリソースアクセスにはプリフィックスリスト（pl-xxxxx）を使用しても、ルーティングが解決されない
• DNS 解決の自動化: PrivateDnsEnabled: true を設定すれば、AWS-provided DNS（169.254.169.253）が自動的に VPCE の IP に名前解決
• 複数 Subnet への分散: HA 構成では複数 Subnet に ENI を配置。Route 53 Health Check で監視可能

できないこと・制約

---

第4層：VPC Flow Logs

フローログの構造と解析

VPC Flow Logs は、VPC / Subnet / ENI レベルでネットワークパケットのメタデータをキャプチャする。

デフォルトフォーマット:

version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-1a2b3c4d 10.0.0.10 10.0.1.20 52143 443 6 10 2560 1596394081 1596394140 ACCEPT OK

フィールド解説:

カスタムフォーマット（v3, v4, v5）

バージョン3以降、カスタムフィールドを追加可能：

{
  "LogDestinationType": "cloud-watch-logs",
  "LogFormat": "${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${tcp-flags} ${type} ${pkt-srcaddr} ${pkt-dstaddr} ${region} ${subnet-id} ${instance-id} ${interface-type} ${eni-id} ${flow-logs-id} ${traffic-type} ${vpc-id}"
}

重要なカスタムフィールド:

• tcp-flags: TCP フラグ（SYN, ACK, FIN, RST など）
• type: トラフィックタイプ（IPv4, IPv6, EBS）
• pkt-srcaddr / pkt-dstaddr: パケットのネットワーク層アドレス（トンネルの場合、実際のパケット送信元）
• region: EC2 リージョン
• traffic-type: ACCEPT / REJECT / ALL

配信先の選択と分析

Flow Logs は複数の配信先へ同時送信可能：

VPC Flow Logs
  ├─ CloudWatch Logs（リアルタイムモニタリング）
  ├─ S3（長期保存・アーカイブ）
  └─ Kinesis Data Firehose（リアルタイム処理・第三者ツール連携）

CloudWatch Logs での検索：

[version, account_id, eni_id, src_addr, dst_addr="10.0.1.20", src_port, dst_port, protocol, ...]
action = REJECT

AWS CLI での設定:

# VPC Flow Logs 作成（CloudWatch Logs）
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345678 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs \
  --deliver-logs-permission-role-arn arn:aws:iam::123456789012:role/flowlogsRole \
  --log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${action} ${log-status} ${tcp-flags} ${type}'

試験で狙われるポイント

• NODATA vs SKIPDATA: NODATA は Flow Logs が有効になっていない ENI、SKIPDATA はデータが集約されて送信されなかったケース
• アグリゲーション時間: 最大600秒（10分）ごとに Flow Logs が送信される（リアルタイムではない）
• 除外トラフィック: DHCP, Amazon DNS, ライセンスサーバー, Route 53 Health Checks は記録されない

できないこと・制約

---

第5層：AWS Network Firewall

ステートフル・ステートレスルール

Network Firewall はアプリケーション層（L7）まで検査可能なマネージドファイアウォール。VPC の入口に配置され、すべてのトラフィックを検査する。

ステートフルルール

接続状態を追跡し、確立済み接続のリターントラフィックを自動許可。

Client → Firewall（ステートフルルール評価）→ VPC
         SYN パケット → Allow → Connection Established
         ACK/データ → Established connection table → Auto Allow

{
  "RuleGroups": [
    {
      "Name": "stateful-rules",
      "Capacity": 100,
      "Type": "STATEFUL",
      "RuleGroupConfig": {
        "StatefulRuleOptions": {
          "RuleOrder": "STRICT_ORDER"
        },
        "Rules": [
          {
            "Header": {
              "Direction": "FORWARD",
              "Protocol": "TCP",
              "Destination": "10.0.0.0/8",
              "DestinationPort": "443",
              "Source": "ANY",
              "SourcePort": "ANY"
            },
            "RuleOptions": [
              {
                "Keyword": "sid",
                "Settings": ["1"]
              },
              {
                "Keyword": "rev",
                "Settings": ["1"]
              }
            ]
          }
        ]
      }
    }
  ]
}

ステートレスルール

パケット単位で評価。往復トラフィックを別ルールで指定する必要がある。

Client → Firewall（ステートレスルール評価）→ VPC
         送信元ポート・プロトコルのマッチング必須
VPC → Firewall（戻りのステートレスルール評価）→ Client
         相互方向のルール必須

Suricata 互換ルール

Network Firewall は Suricata ルール構文をサポート。L7 検査が可能。

alert http any any -> any 80 (msg:"Detect SQL Injection"; content:"UNION"; http_uri; sid:1000001;)
alert dns any any -> any 53 (msg:"Block DNS to suspicious domain"; content:"malware.com"; http_host; sid:1000002;)
alert tls any any -> any 443 (msg:"Block weak SSL/TLS"; tls_version:"1.0"; sid:1000003;)

メタデータフィールド:

• msg: ルール説明
• content: 検索対象のペイロード
• http_uri / http_host / http_method: HTTP 層の検査
• tls_version: TLS バージョン制限
• sid / rev: ルール ID・リビジョン
• classtype / priority: ルール分類・優先度

Network Firewall とネットワークアーキテクチャ

Network Firewall はVPCの入口に配置され、複数のSubnetへのトラフィックを一元制御。

Internet Gateway
        ↓
Network Firewall（VPC Endpoint）
        ↓
Route Table（Firewall を経由するようにルーティング）
        ├→ Public Subnet 1
        ├→ Public Subnet 2
        └→ Private Subnet

デプロイ方式：

# Network Firewall Policy 作成
aws network-firewall create-firewall-policy \
  --firewall-policy-name "my-policy" \
  --firewall-policy-text file://policy.json

# Firewall を VPC にデプロイ
aws network-firewall create-firewall \
  --firewall-name "my-firewall" \
  --firewall-policy-name "my-policy" \
  --vpc-id vpc-12345678 \
  --subnet-mappings SubnetId=subnet-12345678,IPAddressType=IPV4

試験で狙われるポイント

• Suricata ルールとネイティブルールの違い: Suricata ルールはテキストベース（より柔軟）。ネイティブルールは AWS マネージメントコンソール UI で作成
• パフォーマンスへの影響: ステートフル検査は CPU 集約的。大規模トラフィックではスケーリングが必須
• ルール優先度: classtype で優先度が決まる（参考：NCSA 分類体系）

できないこと・制約

---

第6層：PrivateLink とサービス公開

サービスプロバイダーとしての PrivateLink 設定

独自のサービスを他の VPC へ公開する場合、NLB（Network Load Balancer）を介して PrivateLink で公開。

Consumer VPC
  └─ VPC Endpoint Interface
     (com.amazonaws.vpce.us-east-1.vpce-svc-12345678)
        ↓
        PrivateLink（プライベートネットワーク経由）
        ↓
Provider VPC
  └─ Network Load Balancer
     ├─ Target Group → EC2 / Lambda / On-premises
     └─ Service Configuration（エンドポイントサービス）

エンドポイントサービス作成:

# NLB ターゲットグループ作成
aws elbv2 create-target-group \
  --name my-targets \
  --protocol TCP \
  --port 443 \
  --vpc-id vpc-12345678

# NLB 作成
aws elbv2 create-load-balancer \
  --name my-nlb \
  --subnets subnet-12345678 subnet-87654321 \
  --type network \
  --scheme internal

# ターゲットグループをリスナーにアタッチ
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/my-nlb/12345678 \
  --protocol TCP \
  --port 443 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/12345678

# エンドポイントサービス設定
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/net/my-nlb/12345678 \
  --acceptance-required false

エンドポイントサービスのリソースベースポリシー:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": "ec2:CreateVpcEndpoint",
      "Resource": [
        "arn:aws:ec2:us-east-1:123456789012:vpc-endpoint-service/vpce-svc-12345678"
      ]
    }
  ]
}

Consumer VPC からのアクセス

# VPC Endpoint 作成（Consumer VPC）
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-87654321 \
  --vpc-endpoint-type GatewayLoadBalancer \
  --service-name com.amazonaws.vpce.us-east-1.vpce-svc-12345678 \
  --subnet-ids subnet-87654321

試験で狙われるポイント

• PrivateLink vs VPC Peering: PrivateLink はインターネットを経由しないプライベート接続。IP アドレス空間が重複しても可能
• エンドポイントサービスの受け入れ: AcceptanceRequired: true の場合、プロバイダーが接続要求を明示的に承認
• 複数リージョンへの公開: PrivateLink はリージョナル。複数リージョンでのサービス公開には、各リージョンで個別設定

できないこと・制約

---

第7層：Transit Gateway（TGW）とセグメンテーション

ルーティングの一元化

Transit Gateway は複数 VPC / On-premises ネットワークを単一のハブで接続し、ルーティングを一元管理。

VPC A ──┐
VPC B ──┼─ Transit Gateway ─┬─ On-premises (Site-to-Site VPN)
VPC C ──┤                   └─ Corporate Network (Direct Connect)
VPC D ──┘

ルーティング表と Transit Gateway Attachments

各 Attachment（VPC / On-premises）は個別のルーティング表を持ち、通信ルールを制御。

# Transit Gateway 作成
aws ec2 create-transit-gateway \
  --description "Multi-VPC connectivity" \
  --options AmazonSideAsn=64512,DefaultRouteTableAssociation=enable,DefaultRouteTablePropagation=enable

# VPC を TGW にアタッチ
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-12345678 \
  --vpc-id vpc-12345678 \
  --subnet-ids subnet-12345678 subnet-87654321 \
  --tag-specifications ResourceType=transit-gateway-attachment,Tags=[{Key=Name,Value=vpc-a-attachment}]

# TGW ルーティング表にルート追加
aws ec2 create-transit-gateway-route \
  --transit-gateway-route-table-id tgw-rtb-12345678 \
  --destination-cidr-block 10.0.0.0/8 \
  --transit-gateway-attachment-id tgw-attach-12345678

ネットワークセグメンテーション

Transit Gateway Attachments をルーティング表で分離し、VPC 間の通信を制御。

ルーティング表 A（開発環境）
  ├─ VPC A（Dev）→ VPC B（Dev）許可
  └─ VPC A（Dev）→ VPC C（Prod）拒否

ルーティング表 B（本番環境）
  ├─ VPC C（Prod）→ VPC D（Prod）許可
  └─ VPC C（Prod）→ VPC A（Dev）拒否

Attachment に異なるルーティング表を関連付け：

# VPC A を Dev ルーティング表に関連付け
aws ec2 associate-transit-gateway-route-table \
  --transit-gateway-route-table-id tgw-rtb-dev-123 \
  --transit-gateway-attachment-id tgw-attach-vpc-a

# VPC C を Prod ルーティング表に関連付け
aws ec2 associate-transit-gateway-route-table \
  --transit-gateway-route-table-id tgw-rtb-prod-123 \
  --transit-gateway-attachment-id tgw-attach-vpc-c

試験で狙われるポイント

• デフォルトルーティング表の動作: DefaultRouteTableAssociation: enable の場合、新規 Attachment は自動的にデフォルト表に関連付けられる
• ルート伝播（Route Propagation）: BGP で学習したルートは自動的に ルーティング表に追加可能（ただし手動設定も可能）
• Transit Gateway MTU: デフォルト 8500 bytes（VPC: 1500 bytes）。Jumbo frames に対応

できないこと・制約

---

多層防御のベストプラクティス

マイクロセグメンテーション

大規模エンタープライズでは、Security Groups + NACL + Transit Gateway を組み合わせ、最小限の通信路を確保。

インターネットアクセスなしでの AWS サービス利用

VPC Endpoints + Network Firewall で、インターネット経由を回避し、プライベートネットワーク内で AWS サービスにアクセス。

EC2（Private Subnet）

• S3 → VPC Endpoint Gateway → S3
• Secrets Manager → VPC Endpoint Interface → Secrets Manager
• CloudWatch → Network Firewall（L7検査）→ CloudWatch
• Internet アクセス：なし

ポリシー設定:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpc": "vpc-12345678"
        }
      }
    }
  ]
}

ハイブリッド接続セキュリティ

Site-to-Site VPN / Direct Connect + Transit Gateway + Network Firewall で、オンプレミスネットワークのセキュアな接続。

On-Premises Network
       ↓
Site-to-Site VPN / Direct Connect
       ↓
Transit Gateway（ルーティング一元管理）
       ↓
Network Firewall（トラフィック検査）
       ↓
VPC / Private Subnet

集中型エグレスフィルタリング

NAT Gateway の前に Network Firewall を配置し、アウトバウンドトラフィックを一元検査。

EC2（Private Subnet）
  ↓
Network Firewall（アウトバウンド検査、Suricata ルール）
  ↓
NAT Gateway / VPN
  ↓
Internet / On-Premises

---

他サービスとの連携

Route 53 Resolver（Hybrid DNS）

オンプレミス DNS と AWS の VPC DNS を統合解決。

EC2 → Route 53 Resolver Endpoint
  ├─ Forward Rule: corp.internal → On-premises DNS
  └─ Resolver Query Logging → CloudWatch Logs（監査ログ）

# Resolver Endpoint 作成（Inbound）
aws route53resolver create-resolver-endpoint \
  --name onprem-dns \
  --direction Inbound \
  --ip-address-type IPV4 \
  --ip-addresses SubnetId=subnet-12345678,Ip=10.0.1.100

# Forwarding Rule 作成
aws route53resolver create-resolver-rule \
  --name corp.internal \
  --rule-type FORWARD \
  --domain-name corp.internal \
  --target-ip-addresses Ip=192.168.1.100,Port=53

Direct Connect と VPN の組み合わせ

Direct Connect（専用接続）と Site-to-Site VPN（バックアップ）の HA 構成。

On-Premises
  ├─ Direct Connect（Primary: 1Gbps 専用線）
  └─ Site-to-Site VPN（Backup: インターネット経由、自動フェイルオーバー）
         ↓
    Transit Gateway（ルーティング自動切り替え）
         ↓
       VPC

GuardDuty とフローログの連携

VPC Flow Logs からセキュリティ脅威を検出。

VPC Flow Logs（CloudWatch Logs）
  ↓
GuardDuty（ML ベース脅威検知）
  ↓
EventBridge（自動レスポンス）
  └─ Lambda / SNS（アラート）

CloudWatch / CloudTrail との監視

# CloudWatch Alarm: 異常なエグレストラフィック検知
aws cloudwatch put-metric-alarm \
  --alarm-name "unusual-outbound-traffic" \
  --metric-name BytesOutNetwork \
  --namespace AWS/EC2 \
  --statistic Sum \
  --period 300 \
  --threshold 10737418240 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:alerts

# CloudTrail: VPC セキュリティ設定変更の監査ログ
aws cloudtrail create-trail \
  --name vpc-security-trail \
  --s3-bucket-name my-cloudtrail-bucket

AWS Firewall Manager（一元管理）

複数アカウント・リージョンの Security Groups / Network Firewall を一元管理。

# Firewall Manager ポリシー作成
aws fms create-policy \
  --policy \
  '
  {
    "PolicyName": "global-vpc-policy",
    "SecurityServicePolicyData": {
      "Type": "WAF",
      "ManagedServiceData": "{...}"
    },
    "ResourceType": "AWS::EC2::SecurityGroup",
    "Tags": [{"Key": "Environment", "Value": "Production"}]
  }
  '

---

試験での頻出問題パターン

パターン1：SG + NACL のトラブルシューティング

Q: EC2（10.0.1.20、SG-A）から RDS（10.0.2.30、SG-B）への通信が失敗する。
   SG-A: アウトバウンド 3306 → 10.0.2.0/24 許可
   SG-B: インバウンド 3306 ← 10.0.1.0/24 許可
   NACL（Subnet A）: インバウンド・アウトバウンドすべて許可
   NACL（Subnet B）: インバウンド 3306 許可、アウトバウンド All 許可

A: NACL（Subnet A）のアウトバウンド"エフェメラルポート"許可ルールが不足
   → アウトバウンドルールに 49152-65535 の許可を追加

パターン2：VPC Endpoint ポリシーの絞り込み

Q: VPC Endpoint Gateway（S3）を使用し、特定バケット内の特定プレフィックスのみアクセス許可。
   他のバケット・プレフィックスはアクセス拒否。

A: エンドポイントポリシーで Resource を制限
   "Resource": "arn:aws:s3:::my-bucket/production/*"

パターン3：Flow Logs で接続を追跡

Q: VPC Flow Logs から、夜間に unusual outbound traffic（宛先ポート 443）を検出。
   送信元は Private Subnet の EC2、宛先は external IP。
   原因を特定するには？

A: Flow Logs の`srcaddr`, `dstaddr`, `dstport`, `action`を分析
   → Security Group のアウトバウンドルール確認
   → Network Firewall で Suricata ルール適用（宛先ドメイン検査）

---

まとめ：実装チェックリスト

---

参考リンク・さらに学ぶ

• AWS VPC Security Groups Documentation
• Network ACLs Documentation
• VPC Endpoints Documentation
• AWS Network Firewall Documentation
• VPC Flow Logs Documentation
• Transit Gateway Documentation
• SCS-C03 Exam Guide