SOA-5.3ネットワーク接続問題のトラブルシューティングを行う。

ヒントボタン

Site-to-Site VPN で 192.168.0.0/20 から VPC に入るパケットはプライベートサブネットの Network ACL の Inbound 8443 で通過しますが、NACL はステートレスなので戻りは Outbound で再評価されます。EC2 からの応答は送信元 8443 ではなくクライアント側の 1024-65535 エフェメラルポート宛てとなり、現状 Outbound 443 しか許可していないため VGW に届く前に破棄されタイムアウトする点に注目してください。

Security Group はステートフルでデフォルト Outbound ALL が残っており問題を生みませんし、ルートテーブルも VGW への 192.168.0.0/20 と NAT Gateway への 0.0.0.0/0 で適切です。ALB や IGW を動かす大がかりな変更より、Network ACL の Outbound にクライアントが用いる動的ポート範囲を許可する方が「最小変更で復旧」という要件に合致することを思い出しましょう。

要件は「社内からのみ 8443 でアクセスしインターネットから遮断」なので、パブリック化や 0.0.0.0/0 を VGW に流す施策は NAT Gateway や IGW 周りの設計を崩してしまいます。VPC のステートレス層である Network ACL の DENY より前にエフェメラルポート 1024-65535 を ALLOW するアウトバウンドルールを置けば往復通信が成立し、セキュリティと作業量の両面で総合的に最もバランスが取れます。

ヒントボタン

VPC Flow Logs に REJECT が出ている時点で、Security Group はステートフルゆえ戻りトラフィックを自動許可するため問題ではなく、NAT Gateway を経由した外向き HTTPS 接続が失敗する原因としてはステートレスな Network ACL が返却パケットを遮断している可能性が高いので、まずアウトバウンド側で宛先ポート 443 のみを ALLOW として最小権限を確立する設定を思い描いてみてください。さらに CIDR を 0.0.0.0/0 としておくとアドレスが限定されてもポートによる制限で十分な絞り込みが行えます。過度にアドレスを限定すると可用性の高い外部サービスの IP 変更に追随できず運用コストが増える点にも注意が必要です。
ステートレスな Network ACL ではパケットの行きと帰りを別々に判定するため、EC2 インスタンスからの TLS ハンドシェイクは送信元がエフェメラルポート 1024–65535、宛先 443 で出て行き、戻りは送信元 443、宛先 1024–65535 で入ってくるという TCP の性質を踏まえ、Flow Logs に見える拒否レンジをそのままインバウンド側に許可しなければ 3 ウェイハンドシェイクが成立せず接続数が 400/s でもゼロになる点を確認しておきましょう。このポート範囲は広く感じますが外向き通信を開始したインスタンスに限定されるため脅威は低減しています。
要件を総合すると、セキュリティグループは既存の 443 送信許可を維持してステートフル追跡を活用し、Network ACL ではアウトバウンド 0.0.0.0/0 TCP 443、インバウンド 0.0.0.0/0 TCP 1024–65535 を許可してデフォルト DENY を残す構成が、HTTPS のみを許可するリーンな Least Privilege と、VPC による接続追跡で運用負荷を抑えるという複数要件を最もバランス良く満たす判断になります。

ヒントボタン

CloudWatch に大量の TargetConnectionError が出ている状況は、Application Load Balancer がターゲットグループのヘルスチェックで接続確立に失敗しているサインです。ECS Fargate タスクは HTTP 8080 でのみ待ち受け、TLS は ALB で終端しているためタスク側では HTTPS 443 を理解できません。デフォルトのヘルスチェックがプロトコルとポートの不一致を起こすと閾値２回で Unhealthy 判定となり、３ AZ すべてが切り離されサービス停止に直結します。ログを確認し、待ち受けポートとヘルスチェック設定の乖離を最初に疑うことで原因特定が迅速になります。

最短で復旧するには ACM 証明書をコンテナへ組み込むような再ビルドではなく、ターゲットグループ設定だけを修正する方法が有効です。AWS CLI やコンソールでプロトコルを HTTP、ポートを 8080、パスをアプリが応答できる /status に変更すれば、成功閾値３回で数十秒後には Healthy に戻り、RTO ５分以内という要件を満たせます。Application Load Balancer や ECS Fargate タスクの再起動は不要で即時反映されるため、手数とリスクを最小限に抑えられます。

TLS をロードバランサーで終端する設計では、エンドユーザー通信の暗号化維持、タスク側変更の有無、復旧までの時間という三点を同時に考慮する必要があります。Application Load Balancer のヘルスチェックをタスク実態に合わせて修正することでセキュリティを保ちつつ可用性を即座に回復でき、ECS Fargate や ACM の追加作業が不要となるため、複数要件を俯瞰した総合判断として最もバランスの良い対応策となります。

ヒントボタン

VPC でプライベートサブネットからインターネットへ出る際に NAT Gateway が別の Availability Zone にあると、その AZ からのトラフィックは AZ 間の ENI を横断し、片方向 5 Gbps の帯域上限とクロス AZ データ転送料金が発生します。今回のバッチサーバーは合計 2 Gbps 近いスループットを要求しており、AZ-b から NAT Gateway までのリンクが飽和すると VPC フローログに RST が多発するのは自然な挙動です。AWS Well-Architected Framework でも NAT Gateway は各 AZ に配置するベストプラクティスが示されています。

可用性と運用負荷を比較すると、EC2 ベースの NAT インスタンスはパッチ管理や Auto Scaling 設計、Source/Dest Check 無効化など手作業が多く、Elastic IP を付けてパブリックサブネットへ移動する方法は Security Group ルールや IAM 制御が煩雑です。マネージドな NAT Gateway は各 Availability Zone 内で冗長化され、Route Table の 0.0.0.0/0 を同一 AZ 内のエンドポイントへ向けるだけで帯域が自動スケールし、管理コストも抑えられます。

つまり、各 Availability Zone に NAT Gateway を 1 つずつ設置し、それぞれのプライベートサブネットのデフォルトルートを同一 AZ 内のエンドポイントに変更する構成が、クロス AZ 帯域制限によるタイムアウトと障害点を同時に排除しつつ、VPC のセキュリティ、スループット、運用工数、コストという複数要件を総合的に満たす最適な対応策と判断できます。

ヒントボタン

Amazon RDS も EC2 と同様に Security Group がステートフルで動作します。sg-bastion は送信 0.0.0.0/0 を持つため発信パケットは問題なく出ますが、sg-db のインバウンドが空欄だと 3306/TCP が到達せずタイムアウトします。送信元に踏み台の SG ID を指定して 3306 を許可すれば往復通信が自動で開き、追加コストも生じません。

セキュリティグループでは FQDN を宛先に使えず、ルールは CIDR か SG ID で指定する仕組みです。したがって送信側だけを調整しても根本解決になりません。また RDS を Public accessibility に切り替え 0.0.0.0/0 で 3306 を開放すると SaaS 金融という前提で求められるプライベート運用と最小権限の原則に反します。受信側をピンポイントで開ける方法が安全かつ簡潔です。

問題文には「NACL 変更不可」「追加コストと運用負荷を最小に」という制約が明示されています。ネットワーク ACL はステートレスゆえ戻りポートまで許可が必要で工数が増え、そもそも変更できません。プライベートな Amazon RDS とステートフルな Security Group のみで通信を許可すれば、設定箇所は１カ所、費用ゼロで要件すべてを同時に満たせるという総合判断になります。

ヒントボタン

VPC フローログは S3 や CloudWatch Logs への転送を開始した後は TrafficType や logDestination を UpdateFlowLog で変更できないイミュータブルなリソースです。そのため Direct Connect 越しに利用するプライベートサブネットの eni-1234 で ALL から REJECT だけに絞りたい場合は、既存設定を書き換えるのではなく同じ ENI に新しい FlowLog を追加作成するというアプローチが前提になります。

調査期間中の取りこぼしを防ぐ最も安全な流れは、まず REJECT フィルターの VPC フローログを作成して CloudWatch Logs Insight や Athena で拒否トラフィックの到達を確認し、その後に旧 ALL ログを停止する手法です。これなら ENI あたり 10 本という Service Quotas 内で二重取得しても僅か 2 本に留まり、キャパ不足や過大な課金を招かずにログ欠損ゼロを実現できます。

フローログが編集不可という仕様面、CloudWatch Logs での履歴保持を維持しつつダウンタイムを許さない運用面、そして不要な転送コストを削減したい経済面という複数要件を俯瞰すると、まず REJECT ログを追加し確認後に ALL ログを削除する段階的切り替えこそが総合的に最も合理的な判断となります。

ヒントボタン

VPC Flow Logs に action=REJECT が大量に出ているときは、まずステートフルな Security Group ではなくステートレスな Network ACL を疑います。特に Amazon S3 への 443/TCP 通信では戻りパケットが 1024 以降のエフェメラルポートを使うため、アウトバウンド側で pl- から始まるプレフィックスリスト宛てと 1024-65535 の ALLOW がないと一方向通信となり拒否が続くことを覚えておくと分析が進みます。
ゲートウェイ VPC エンドポイントはプライベートサブネットから Amazon S3 への経路をリージョン内で冗長に提供し、データ転送料も NAT Gateway 経由より安価です。これを外して Internet Gateway を通すルートに変えると、可用性設計や料金面で追加検討が必要になり、今回の通信失敗という根本原因にも直接影響を与えない点を比較して整理しましょう。
今回の要件は可用性を落とさずセキュリティも保ったまま最小の変更で通信を復旧させることですから、既存のルートテーブルと Security Group はそのままに、Network ACL のアウトバウンドに S3 プレフィックスリスト宛て 443/TCP と戻りポート 1024-65535/TCP を ALLOW するルールを追加する方法が複数の観点を満たす解決策になると総合的に判断できます。

ヒントボタン

Amazon VPC の Network ACL はステートレスで、インバウンドで 3306/TCP を許可しても応答パケット用にアウトバウンド側の許可が別途必要です。MySQL から返るパケットは 1024〜65535 のエフェメラルポート宛に送信されるため、アウトバウンドが DENY ALL だと戻りが遮断されタイムアウトになります。直前にインバウンドだけを追加したという経緯がそのヒントとなります。

セキュリティグループはステートフルなので一度許可すると戻り通信は自動で通過しますが、Network ACL はイン／アウトの両方向を明示する必要がある点が本質です。同一 VPC 内のサブネット間通信は既定の local ルートで完結するためルートテーブルを触る余地はありません。したがって経路や SG ではなく NACL のアウトバウンドに RDS からの応答ポートを開けることが最短の解決手段となります。

停止時間を抑え RPO 5 分以内を維持するには、リソース再配置やデータベースの再構築といった大掛かりな変更は避け、既存 Amazon VPC 内で必要最小限の設定のみ修正することが合理的です。Network ACL のアウトバウンドに 10.0.2.0/24 から 10.0.1.0/24 へのエフェメラルポート帯を Allow すれば要件を満たし即時復旧できるという総合判断につながります。

ヒントボタン

VPC フローログに記録された「10.0.3.100 から 10.0.2.15 への 3306→51834」の REJECT は、MySQL からの応答が EC2 のエフェメラルポートに届く途中で遮断されている証拠です。ネットワーク ACL はステートレスのため往路と復路を個別に許可する必要があります。10.0.2.0/24 のインバウンド側で TCP 1024–65535 を許可するルールを追加し、評価順序が既存の拒否より前になるよう配置する案を意識してみてください。

EC2 から Amazon RDS への接続はアウトバウンドで TCP 3306 が既に許可されており問題は発生していません。課題は RDS から返るレスポンスがエフェメラルポートに到達する際、セキュリティグループのステートフル許可を通過した後で NACL が拒否してしまう点です。アウトバウンド側の拡張や SG 変更では NACL の拒否を回避できません。どの層でブロックが起きているかを整理し、ステートレス機構を調整する方向で検討してみましょう。

短時間で通信を復旧し追加コストも抑えたいという要件を総合的に見ると、ネットワーク ACL にエフェメラルポート範囲の許可を 1 行追加し優先度を調整するだけで解決できる構成が最もシンプルです。NACL の評価順序、ステートレス制御、エフェメラルポートの仕組みを俯瞰し、最小変更で要件を満たす手段を選択する視点を持ちましょう。