クラウドネットワークアーキテクチャ トラブルシューティング完全ガイド — AWS・GCP・Azure実践デバッグ

トラブルシューティングの順序:
1. アプリケーション層 (L7) — DNS確認、HTTPレスポンスコード
2. トランスポート層 (L4) — ポート接続性、TCPハンドシェイク
3. ネットワーク層 (L3) — IPルーティング、サブネットCIDR
4. セキュリティ層 — Security Group、NACL、ファイアウォールルール
5. インフラ層 — IGW、NAT GW、VPN、Peeringの状態

# 基本的な接続テスト
ping -c 4 10.0.1.50

# 特定ポートの接続性確認
nc -zv 10.0.1.50 443 -w 5

# TCPルートの詳細トレース
traceroute -T -p 443 10.0.1.50

# DNS検索テスト
dig +trace example.com
nslookup example.com 10.0.0.2

# curlによるHTTPレベルデバッグ
curl -vvv --connect-timeout 5 https://api.internal.example.com/health

Security Group（ステートフル）:
  ・インバウンド許可時、対応するレスポンストラフィックを自動許可
  ・インスタンス（ENI）レベルで適用
  ・許可ルールのみ指定可能（暗黙的な拒否）
  ・ルール評価：全ルールを評価してアクセスを決定

NACL（ステートレス）:
  ・インバウンド/アウトバウンドルールを別々に設定する必要あり
  ・サブネットレベルで適用
  ・許可ルールと拒否ルールの両方を指定可能
  ・ルール評価：ルール番号順に処理（最初のマッチを適用）

# AWS CLIでSecurity Groupルールを確認
aws ec2 describe-security-groups \
  --group-ids sg-0abc1234def56789 \
  --query 'SecurityGroups[*].{
    GroupId:GroupId,
    Ingress:IpPermissions,
    Egress:IpPermissionsEgress
  }' \
  --output json

# 特定インスタンスに関連付けられたSecurity Groupを確認
aws ec2 describe-instances \
  --instance-ids i-0abcdef1234567890 \
  --query 'Reservations[*].Instances[*].SecurityGroups' \
  --output table

問題: EC2から外部APIの呼び出しに失敗
原因: Security Groupのデフォルトアウトバウンドルール（0.0.0.0/0許可）が削除された

修正:
aws ec2 authorize-security-group-egress \
  --group-id sg-0abc1234def56789 \
  --protocol tcp --port 443 \
  --cidr 0.0.0.0/0

問題: 同じSecurity Group内のインスタンス間で通信できない
原因: SGが自分自身をソースとして許可するルールがない

修正:
aws ec2 authorize-security-group-ingress \
  --group-id sg-0abc1234def56789 \
  --protocol -1 \
  --source-group sg-0abc1234def56789

# NACLルールの確認
aws ec2 describe-network-acls \
  --network-acl-ids acl-0abc1234 \
  --query 'NetworkAcls[*].Entries' \
  --output json

問題: アウトバウンドHTTPリクエストのレスポンスが受信できない
原因: NACLにエフェメラルポート範囲（1024-65535）のインバウンドルールがない

NACLルールの例（正しい設定）:
インバウンド:
  Rule 100: TCP 443       ALLOW (0.0.0.0/0)
  Rule 110: TCP 1024-65535 ALLOW (0.0.0.0/0)  <-- これが必須
  Rule *:   全トラフィック DENY

アウトバウンド:
  Rule 100: TCP 443       ALLOW (0.0.0.0/0)
  Rule 110: TCP 1024-65535 ALLOW (0.0.0.0/0)  <-- レスポンストラフィック
  Rule *:   全トラフィック DENY

VPC Peeringの制約:
  x トランジティブピアリングは不可
    VPC-A <-> VPC-B <-> VPC-C: AからCへの直接通信は不可
  x CIDRの重複は不可
  x クロスリージョンピアリングではSecurity Group参照が制限される場合あり

# VPC Peeringの状態確認
aws ec2 describe-vpc-peering-connections \
  --filters "Name=status-code,Values=active,pending-acceptance" \
  --query 'VpcPeeringConnections[*].{
    PeeringId:VpcPeeringConnectionId,
    Status:Status.Code,
    Requester:RequesterVpcInfo.{VpcId:VpcId,CidrBlock:CidrBlock},
    Accepter:AccepterVpcInfo.{VpcId:VpcId,CidrBlock:CidrBlock}
  }'

# ルーティングテーブルのPeering経路確認
aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0abc1234" \
  --query 'RouteTables[*].Routes[?GatewayId!=`local`]'

問題: Peering接続はActiveだが通信できない
原因: 両方のVPCのルーティングテーブルにPeering経路を追加していない

修正:
# VPC-AのルーティングテーブルにVPC-BのCIDRを追加
aws ec2 create-route \
  --route-table-id rtb-aaa111 \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-0abc1234

# VPC-BのルーティングテーブルにVPC-AのCIDRを追加
aws ec2 create-route \
  --route-table-id rtb-bbb222 \
  --destination-cidr-block 10.0.0.0/16 \
  --vpc-peering-connection-id pcx-0abc1234

# Transit Gatewayルーティングテーブルの確認
aws ec2 describe-transit-gateway-route-tables \
  --transit-gateway-route-table-ids tgw-rtb-0abc1234

# Transit Gatewayアタッチメントの状態確認
aws ec2 describe-transit-gateway-attachments \
  --filters "Name=transit-gateway-id,Values=tgw-0abc1234" \
  --query 'TransitGatewayAttachments[*].{
    AttachmentId:TransitGatewayAttachmentId,
    ResourceType:ResourceType,
    State:State
  }'

# TGWルーティングテーブルの経路照会
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-0abc1234 \
  --filters "Name=type,Values=static,propagated"

問題: TGWに接続されたVPC間の通信が失敗
チェックリスト:
  □ TGW Attachmentが「available」状態か？
  □ TGW Route Tableにルートが伝播（propagated）されているか？
  □ 各VPCのサブネットルーティングテーブルにTGWルートがあるか？
  □ TGW Route Table Associationが正しいか？

# VPC Reachability Analyzerの使用（強力な診断ツール）
aws ec2 create-network-insights-path \
  --source i-0abc1234 \
  --destination i-0def5678 \
  --protocol TCP \
  --destination-port 443

aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0abc1234

# 結果の確認
aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids nia-0abc1234 \
  --query 'NetworkInsightsAnalyses[*].{
    Status:Status,
    PathFound:NetworkPathFound,
    Explanations:Explanations
  }'

# GCPファイアウォールルールの確認
gcloud compute firewall-rules list \
  --filter="network=my-vpc" \
  --format="table(name,direction,priority,allowed,sourceRanges,targetTags)"

# Connectivity Testの実行（GCPのReachability Analyzer）
gcloud network-management connectivity-tests create my-test \
  --source-instance=projects/my-project/zones/us-central1-a/instances/vm-1 \
  --destination-instance=projects/my-project/zones/us-central1-b/instances/vm-2 \
  --protocol=TCP \
  --destination-port=8080

# 結果の確認
gcloud network-management connectivity-tests describe my-test

# NSGルールの確認
az network nsg rule list \
  --nsg-name my-nsg \
  --resource-group my-rg \
  --output table

# Network Watcherによる接続性確認
az network watcher test-connectivity \
  --resource-group my-rg \
  --source-resource vm-source \
  --dest-resource vm-dest \
  --dest-port 443

# 有効なルートの確認
az network nic show-effective-route-table \
  --name my-nic \
  --resource-group my-rg

# AWS VPC Flow Logsの有効化
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-0abc1234 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/flow-logs \
  --deliver-logs-permission-arn arn:aws:iam::123456789012:role/flowlogsRole \
  --max-aggregation-interval 60

Flow Logレコードフォーマット:
<version> <account-id> <interface-id> <srcaddr> <dstaddr> <srcport> <dstport> <protocol> <packets> <bytes> <start> <end> <action> <log-status>

例:
2 123456789012 eni-0abc1234 10.0.1.50 10.0.2.100 49152 443 6 20 4000 1625000000 1625000060 ACCEPT OK
2 123456789012 eni-0abc1234 203.0.113.5 10.0.1.50 0 0 1 4 336 1625000000 1625000060 REJECT OK

-- 拒否されたトラフィックのソースIP Top 10
fields @timestamp, srcAddr, dstAddr, dstPort, action
| filter action = "REJECT"
| stats count(*) as rejectedCount by srcAddr
| sort rejectedCount desc
| limit 10

-- 特定IPのトラフィックパターン分析
fields @timestamp, srcAddr, dstAddr, srcPort, dstPort, protocol, action
| filter srcAddr = "10.0.1.50" or dstAddr = "10.0.1.50"
| sort @timestamp desc
| limit 100

-- 異常なポートスキャンの検出
fields srcAddr, dstPort, action
| filter action = "REJECT"
| stats count(dstPort) as portCount by srcAddr
| filter portCount > 100
| sort portCount desc

-- Athenaテーブルの作成
CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
  version int,
  account_id string,
  interface_id string,
  srcaddr string,
  dstaddr string,
  srcport int,
  dstport int,
  protocol bigint,
  packets bigint,
  bytes bigint,
  start bigint,
  end bigint,
  action string,
  log_status string
)
PARTITIONED BY (dt string)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ' '
LOCATION 's3://my-flow-logs-bucket/AWSLogs/123456789012/vpcflowlogs/';

-- 時間帯別の拒否トラフィック推移
SELECT
  from_unixtime(start) as event_time,
  srcaddr,
  dstaddr,
  dstport,
  protocol,
  sum(packets) as total_packets,
  sum(bytes) as total_bytes
FROM vpc_flow_logs
WHERE action = 'REJECT'
  AND dt = '2026/03/08'
GROUP BY 1, 2, 3, 4, 5
ORDER BY total_packets DESC
LIMIT 50;

IGW経由のインターネットアクセス チェックリスト:
  □ VPCにIGWがアタッチされているか？
  □ パブリックサブネットのルーティングテーブルに 0.0.0.0/0 -> IGW のルートがあるか？
  □ インスタンスにパブリックIPまたはElastic IPが割り当てられているか？
  □ Security Groupのアウトバウンドで該当トラフィックが許可されているか？
  □ NACLのインバウンド/アウトバウンドの両方で許可されているか？

# IGWのアタッチ状態確認
aws ec2 describe-internet-gateways \
  --filters "Name=attachment.vpc-id,Values=vpc-0abc1234" \
  --query 'InternetGateways[*].{IGWId:InternetGatewayId,State:Attachments[0].State}'

# パブリックサブネットのルーティング確認
aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-pub123" \
  --query 'RouteTables[*].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

# NAT Gatewayの状態確認
aws ec2 describe-nat-gateways \
  --filter "Name=vpc-id,Values=vpc-0abc1234" \
  --query 'NatGateways[*].{
    NatGatewayId:NatGatewayId,
    State:State,
    SubnetId:SubnetId,
    PublicIp:NatGatewayAddresses[0].PublicIp,
    PrivateIp:NatGatewayAddresses[0].PrivateIp
  }'

問題 1: NAT Gateway経由でインターネットにアクセスできない
  原因: NAT Gatewayがプライベートサブネットに配置されている
  修正: NAT Gatewayは必ずパブリックサブネットに配置する必要がある

問題 2: 間欠的な接続切断
  原因: NAT Gatewayのコネクション追跡制限超過
  確認: CloudWatchメトリクス > ErrorPortAllocation
  修正: 複数のNAT Gatewayに分散するか、サービスエンドポイントを使用

問題 3: NAT Gatewayのコスト急増
  原因: S3、DynamoDB等のAWSサービストラフィックがNATを経由
  修正: VPC Endpoint（Gatewayタイプ）を作成してプライベートルートを使用

# VPC Endpointの作成（S3の例 — NATコスト削減）
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc1234 \
  --service-name com.amazonaws.ap-northeast-2.s3 \
  --route-table-ids rtb-priv111 rtb-priv222

# NAT Gateway CloudWatchメトリクスの確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway \
  --metric-name ErrorPortAllocation \
  --dimensions Name=NatGatewayId,Value=nat-0abc1234 \
  --start-time 2026-03-07T00:00:00Z \
  --end-time 2026-03-08T00:00:00Z \
  --period 3600 \
  --statistics Sum

クロスリージョン接続オプション:
  1. Inter-Region VPC Peering — 1対1接続、シンプルな構成
  2. Transit Gateway Inter-Region Peering — ハブ・スポーク、大規模構成
  3. AWS Cloud WAN — グローバルネットワーク管理（最新）

# Inter-Region TGW Peeringの状態確認
aws ec2 describe-transit-gateway-peering-attachments \
  --filters "Name=state,Values=available,pendingAcceptance" \
  --query 'TransitGatewayPeeringAttachments[*].{
    AttachmentId:TransitGatewayAttachmentId,
    RequesterTgw:RequesterTgwInfo.TransitGatewayId,
    AccepterTgw:AccepterTgwInfo.TransitGatewayId,
    State:State
  }'

# Site-to-Site VPNトンネルの状態確認
aws ec2 describe-vpn-connections \
  --vpn-connection-ids vpn-0abc1234 \
  --query 'VpnConnections[*].{
    VpnId:VpnConnectionId,
    State:State,
    Tunnel1Status:VgwTelemetry[0].Status,
    Tunnel1StatusMessage:VgwTelemetry[0].StatusMessage,
    Tunnel2Status:VgwTelemetry[1].Status,
    Tunnel2StatusMessage:VgwTelemetry[1].StatusMessage
  }'

VPNトンネルがDOWNの場合のチェックリスト:
  □ カスタマーゲートウェイ（CGW）設定の確認
    - IKEバージョン（v1またはv2）
    - Pre-shared keyの一致
    - Phase 1/Phase 2暗号化パラメータの一致
  □ オンプレミスファイアウォールでUDP 500、UDP 4500が許可されているか
  □ NAT-Traversalの設定確認
  □ BGPセッション状態の確認（動的ルーティング使用時）
  □ Dead Peer Detection（DPD）設定の一致

AWS <-> GCP 接続オプション:
  1. IPSec VPN (AWS VPN + GCP Cloud VPN)
  2. Partner Interconnectの使用
  3. サードパーティSD-WANソリューション

AWS <-> Azure 接続オプション:
  1. IPSec VPN (AWS VPN + Azure VPN Gateway)
  2. ExpressRoute + Direct Connect（専用線）
  3. Megaport等のCloud Exchangeの活用

# GCP VPNトンネルの状態確認
gcloud compute vpn-tunnels describe my-tunnel \
  --region=us-central1 \
  --format="value(status,detailedStatus)"

# Azure VPN接続状態の確認
az network vpn-connection show \
  --name my-vpn-connection \
  --resource-group my-rg \
  --query '{Status:connectionStatus,EgressBytes:egressBytesTransferred,IngressBytes:ingressBytesTransferred}'

# Route 53ホストゾーンのレコード確認
aws route53 list-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --query 'ResourceRecordSets[?Name==`api.example.com.`]'

# Route 53 Resolverクエリログの確認（VPC内部DNS）
aws route53resolver list-resolver-query-log-configs

# DNS解決テスト
aws route53 test-dns-answer \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --record-name api.example.com \
  --record-type A

問題: VPC内でプライベートDNSレコードが解決されない
チェックリスト:
  □ プライベートホストゾーンが該当VPCに関連付けられているか？
  □ VPCのenableDnsSupportがtrueか？
  □ VPCのenableDnsHostnamesがtrueか？
  □ DHCP Options SetでAmazonProvidedDNSを使用しているか？

# VPC DNS設定の確認
aws ec2 describe-vpc-attribute \
  --vpc-id vpc-0abc1234 \
  --attribute enableDnsSupport

aws ec2 describe-vpc-attribute \
  --vpc-id vpc-0abc1234 \
  --attribute enableDnsHostnames

# Cloud DNSレコードの確認
gcloud dns record-sets list \
  --zone=my-dns-zone \
  --filter="name=api.example.com."

# プライベートDNSゾーンの関連VPC確認
gcloud dns managed-zones describe my-private-zone \
  --format="value(privateVisibilityConfig.networks)"

# DNSポリシーの確認
gcloud dns policies list

VPC Peering環境でのDNS解決の問題:
  - Route 53 Resolverインバウンド/アウトバウンドエンドポイントの設定が必要
  - オンプレミス → AWS: Inbound Endpointを使用
  - AWS → オンプレミス: Outbound Endpoint + Forwarding Ruleを設定

                +-----------------------------+
                |     Route 53 Resolver       |
  オンプレ  --> |  Inbound     Outbound       | --> オンプレDNS
  DNSクエリ     |  Endpoint    Endpoint        |    フォワーディング
                +-----------------------------+

# Route 53 Resolverエンドポイントの状態確認
aws route53resolver list-resolver-endpoints \
  --query 'ResolverEndpoints[*].{
    Id:Id,
    Name:Name,
    Direction:Direction,
    Status:Status,
    IpAddressCount:IpAddressCount
  }'

# フォワーディングルールの確認
aws route53resolver list-resolver-rules \
  --query 'ResolverRules[*].{
    Id:Id,
    DomainName:DomainName,
    RuleType:RuleType,
    Status:Status,
    TargetIps:TargetIps
  }'

症状: ECS Fargateタスクから外部API呼び出し時に接続タイムアウトが発生
環境: プライベートサブネットにデプロイされたFargateタスク

デバッグ手順:
  1. タスクのネットワークモードを確認（awsvpc）
  2. タスクのENIに関連付けられたSecurity Groupのアウトバウンドルールを確認
  3. サブネットルーティングテーブルのNAT Gatewayルートを確認
  4. NAT Gatewayの状態と配置（パブリックサブネット）を確認
  5. NACLルールの確認（アウトバウンド + エフェメラルポートのインバウンド）

根本原因: NAT Gatewayが削除されたが、ブラックホールルートが残っていた
修正: 新しいNAT Gatewayを作成し、ルーティングテーブルを更新

症状: VPC-AのアプリケーションからVPC-BのRDSにTCP 3306で接続できない
環境: VPC-A (10.0.0.0/16) <-> Peering <-> VPC-B (10.1.0.0/16)

デバッグ手順:
  1. Peeringの状態確認 → Active
  2. VPC-Aルーティングテーブル → 10.1.0.0/16 → pcx-xxx (OK)
  3. VPC-Bルーティングテーブル → 10.0.0.0/16 → pcx-xxx (OK)
  4. RDS Security Groupのインバウンド確認 → 10.0.0.0/16からの3306が未許可（問題発見!）
  5. RDSはVPC-BのSG参照のみ許可していた

修正: RDS Security Groupに、VPC-AのCIDR（10.0.0.0/16）からの3306インバウンド許可を追加

症状: VPC接続のLambda関数からElastiCacheにアクセスできず、インターネットも不可
環境: Lambdaがプライベートサブネットに接続

デバッグ手順:
  1. Lambda実行ロールのVPC関連権限を確認
     - ec2:CreateNetworkInterface
     - ec2:DescribeNetworkInterfaces
     - ec2:DeleteNetworkInterface
  2. 割り当てられたサブネットの確認（最低2 AZ推奨）
  3. Lambda SG → ElastiCache SGの接続許可を確認
  4. インターネットアクセス: プライベートサブネット + NAT Gatewayが必要

根本原因: LambdaのSecurity Groupアウトバウンドが制限的で、
  ElastiCacheポート（6379）が許可されていなかった
修正: Lambda SGのアウトバウンドにTCP 6379許可を追加

症状: us-east-1とap-northeast-2間のデータレプリケーション遅延が急増
環境: Inter-Region VPC Peeringを使用

デバッグ手順:
  1. VPC Peeringの状態確認 → Active
  2. ネットワーク帯域幅の確認 → CloudWatch BytesIn/BytesOutメトリクス
  3. インスタンスタイプ別のネットワーク性能上限を確認
  4. TCP Window Scalingとバッファサイズの最適化
  5. AWS Global AcceleratorまたはCloudFrontの活用を検討

最適化:
  - 大量転送時は並列ストリームを使用
  - TCPウィンドウサイズのチューニング: sysctl -w net.core.rmem_max=16777216
  - S3 Transfer Accelerationの活用（ファイル転送の場合）

#!/bin/bash
# cloud-network-diag.sh — クラウドネットワーク総合診断スクリプト

TARGET_IP=$1
TARGET_PORT=${2:-443}
VPC_ID=${3:-"auto"}

echo "=== クラウドネットワーク診断開始 ==="
echo "対象: ${TARGET_IP}:${TARGET_PORT}"
echo ""

# 1. 基本的な接続性確認
echo "--- 1. 基本接続性確認 ---"
ping -c 3 -W 2 $TARGET_IP 2>/dev/null
nc -zv -w 3 $TARGET_IP $TARGET_PORT 2>&1

# 2. DNS解決確認
echo "--- 2. DNS解決確認 ---"
dig +short $TARGET_IP 2>/dev/null || echo "IPアドレスのためDNS検索をスキップ"

# 3. ルートトレース
echo "--- 3. ルートトレース ---"
traceroute -m 15 -w 2 $TARGET_IP 2>/dev/null

# 4. AWSセキュリティグループ確認（インスタンスで実行時）
echo "--- 4. メタデータベースのSecurity Group確認 ---"
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 60" 2>/dev/null)
if [ ! -z "$TOKEN" ]; then
  SG_IDS=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/security-groups 2>/dev/null)
  echo "関連付けられたSecurity Groups: $SG_IDS"
fi

echo "=== 診断完了 ==="

# NAT Gateway ErrorPortAllocationアラーム
aws cloudwatch put-metric-alarm \
  --alarm-name "NATGateway-PortAllocation-Error" \
  --metric-name ErrorPortAllocation \
  --namespace AWS/NATGateway \
  --dimensions Name=NatGatewayId,Value=nat-0abc1234 \
  --statistic Sum \
  --period 300 \
  --threshold 100 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:ap-northeast-2:123456789012:network-alerts

# VPNトンネルダウンアラーム
aws cloudwatch put-metric-alarm \
  --alarm-name "VPN-Tunnel-Down" \
  --metric-name TunnelState \
  --namespace AWS/VPN \
  --dimensions Name=VpnId,Value=vpn-0abc1234 \
  --statistic Maximum \
  --period 300 \
  --threshold 0.5 \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:ap-northeast-2:123456789012:network-alerts