AWS ネットワーク構築でハマった（ハマりかけた） 5選とそこから得た教訓

NW-JAWS #22 ～タイトル持ちの長い夜(LV300-)～

Transcript

1. NW-JAWS #22 タイトル持ちの長い夜(LV300-) AWS ネットワーク構築でハマった（ハマりかけた） 5選とそこから得た教訓 ～ ～ 五味 なぎさ
2. 自己紹介 名前：五味 なぎさ（X：@nagisa_53） 仕事：SIer クラウド関連グループマネージャー 趣味：スキューバダイビング 好きなAWSサービス：NW系サービス全般（特にアプリケーション層） AWSに関する活動： • AWS Community Builder（Networking and Content Delivery） • AWS Ambassador • JAWS-UG クラウド女子会 / 彩の国埼玉支部 運営 • JAWS SONIC 2026& MIDNIGHT JAWS 2026実行委員 • JAWS DAYS 2027 実行委員長（予定）
3. 本日お話しする5選 1. 許可しているはずの通信が、ある日から通らない 2. ある日突然、ALBに接続できなくなった 3. エンドポイントを作ろうとしたら、サブネットが選べない 4. 性能試験で、名前解決だけが断続的に失敗する 5. 検査を入れたのに、ルールが動いてくれない 共通するテーマ： 机上の知識だけでは気づきづらく、 実際にやってみたから気づけたハマりどころを共有します
4. トピック 1 許可しているはずの通信が、 ある日から通らない
5. トピック1: 許可しているはずの通信が、ある日から通らない 1-1. 起きた事象 • ある構成変更のあと、通るはずの通信がタイムアウトするようになった • Security Group も NACL も変更していない • ルートテーブルも意図した通りで、宛先までのルートはある • エラーはタイムアウトだけ。どこで落ちているのか分からない
6. トピック1: 許可しているはずの通信が、ある日から通らない 1-1. 起きた事象 • ある構成変更のあと、通るはずの通信がタイムアウトするようになった • Security Group も NACL も変更していない • ルートテーブルも意図した通りで、宛先までのルートはある • エラーはタイムアウトだけ。どこで落ちているのか分からない 何を変更したか ・経路にNetwork Firewallが挿入された ※もちろんNetwork Firewallのルールで該当通信は許可されていた
7. トピック1: 許可しているはずの通信が、ある日から通らない 1-2. 何が起きていたか（1） ▪ SG参照とは • インバウンドルールのソースに、IPアドレス/CIDRではなく別のSecurity GroupのIDを指定できる機能 • アドレス管理から解放され、スケールしても破綻しない、パブリッククラウドならではの機能 ▪ ところが、経路にNetwork FirewallやGWLBを挟むと使えなくなる • AWS公式ブログの考慮事項に明記されている（※） ※ https://aws.amazon.com/jp/blogs/networking-and-content-delivery/deployment-models-for-aws-networkfirewall-with-vpc-routing-enhancements/ • SG参照は使えず、送信元をIPアドレス/CIDRで指定する必要がある
8. トピック1: 許可しているはずの通信が、ある日から通らない 1-3. 何が起きていたか（2） ▪ Network Firewallのエンドポイントの仕組み • Gateway Load Balancer 方式のエンドポイントで、 通信は一度カプセル化されてファイアウォールに転送される • SG参照はENI同士の「直接の関連」を前提とした機能なので成立しない • IPアドレスは保持される（NATされない） → 「送信元は変わらないのにSG参照だけ効かない」状態になり気づきにくい
9. トピック1: 許可しているはずの通信が、ある日から通らない 1-4. 教訓1 • Network Firewall / GWLBだけでなく、何らかのAWS内部の処理（例えばNLBなども）が挟まる だけで同じことは起こりうる • 「宛先IPアドレスは変わらないのにSG参照は効かない」は仕様。 推測で切り分ける前に、そのサービスのドキュメントを読んで仕様を確認する
10. トピック 2 ある日突然、ALB に接続できなくなった
11. トピック2: ある日突然、ALB に接続できなくなった 2-1. 起きた事象 • ALBは正常、ターゲットも正常、SGもNACLも変更なし • にも関わらず、接続タイムアウトが発生 • ミドルウェアを再起動したら復旧した
12. トピック2: ある日突然、ALB に接続できなくなった 2-2. 何が起きていたか ▪ AWS側の仕様 • ALBはDNSエントリのIPアドレス変更起こりうる 【DNSキャッシュ滞留によるタイムアウト】 • ALBのDNSエントリのTTLは60秒。 60秒ごとに引き直せば追随できる。 • ALBには静的IPアドレスがない（NLBは固定可） ▪ 起きていたこと：クライアント側がTTLを守っていなかった • ミドルウェアのプロキシ機能、JVM、HTTPクライアントなどは 独自にDNSレスポンスをキャッシュする クライアント（MW） 古いIPをキャッシュ保持し続ける ↓ 接続試行 (応答なし / タイムアウト) • TTLが切れても引き直さず、退役済みのIPアドレスに送り続けて いた 退役済み ALB IP 新 ALB IP
13. トピック2: ある日突然、ALB に接続できなくなった 2-3. どうしたか ▪ 実施した対応 • ミドルウェアのDNSキャッシュ挙動を見直し、解決結果を保持し続けないように設定を修正した ▪ （今回はそうしなかったが）設定を変更できないミドルウェアが相手なら • NLB → ALB のターゲットグループ連携を使い、NLBのAZごとの静的IPアドレスをクライアントに見せる 参考：https://repost.aws/knowledge-center/alb-ip-change-notifications-eventbridge
14. トピック2: ある日突然、ALB に接続できなくなった 2-4. 教訓2 • マネージドなエンドポイントは「名前」で扱うのが原則 • ALBに対するクライアントのDNSキャッシュ挙動は、構築時に要確認 • 設定を変えられないMWが相手なら、NLB経由で静的IPアドレスを提供する手も
15. トピック 3 エンドポイントを作ろうとしたら、 サブネットが選べない
16. トピック3: エンドポイントを作ろうとしたら、サブネットが選べない 3-1. 起きた事象 • 接続先：別アカウントのVPCエンドポイントサービス（NLBベース） • こちら側でインターフェースエンドポイントを作ろうとすると、 利用AZ（シングルAZ）は揃っているのに配置するサブネットの候補が出てこない • APIで指定すると次のエラーになる 「The VPC endpoint service vpce-svc-xxxx does not support the Availability Zone of the subnet: subnetxxxx」
17. トピック3: エンドポイントを作ろうとしたら、サブネットが選べない 3-2. 何が起きていたか ▪ AZ名とAZ IDは別物 • AZ名はアカウントごとに異なる物理AZへマッピングされる • 物理AZを一意に示すのはAZ ID（apne1-az1 など） • 「お互い1aです」でも、同じ物理AZとは限らない [アカウントA] プロバイダー NLB AZ名: ap-northeast-1a AZ ID 不一致 (≠) AZ名は同じ「1a」でも物理AZが異なり接続不可 ▪ PrivateLinkは物理AZ単位で接続する • プロバイダーが有効化したAZと同じ物理AZに、コンシューマ側 のサブネットがある場合だけ作成できる 参考：https://repost.aws/knowledge-center/interface-endpoint-availability-zone [アカウントB] コンシューマ EP サブネット AZ名: ap-northeast-1a
18. トピック3: エンドポイントを作ろうとしたら、サブネットが選べない 3-3. どうしたか ▪ 確認する • aws ec2 describe-availability-zones で ZoneName と ZoneId の対応を確認 （両アカウントで実行して突き合わせる） ▪ 揃える • プロバイダー側：サービス（NLB）を複数AZで有効化してもらう • コンシューマ側：接続に使うAZを増やし、サブネットを用意する • シングルAZ運用でも、AZ IDを指定してサブネットを作る （「1aだから」ではなく「apne1-az1だから」で設計する）
19. トピック3: エンドポイントを作ろうとしたら、サブネットが選べない 3-4. 教訓3 • 複数アカウントをまたぐ設計では、AZ名で会話すると必ずズレる。 「1a」ではなく「apne1-az1」で会話する • PrivateLink、共有VPC、キャパシティ予約など、アカウント境界を越える機能はAZ IDが基準 になる • シングルAZ構成同士の接続は、成立しない可能性がある前提で設計する
20. トピック 4 性能試験で、 名前解決だけが断続的に失敗する
21. トピック4: 性能試験で、名前解決だけが断続的に失敗する 4-1. 起きた事象 • 負荷分散配下のインスタンス全体で発生（1台だけの問題ではなかった） • ミドルウェアのログに、名前解決処理自体の失敗エラーが出ていた • DNS側には手がかりが無い • VPC Flow Logsにも出ない
22. トピック4: 性能試験で、名前解決だけが断続的に失敗する 4-2. 何が起きていたか（1） ▪1024PPSのハードリミット • 各ENIからRoute 53 Resolver宛に送れるのは 1024 PPS（引き上げ不可） 参考：https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-dns ▪補足：そんなにDNSを引く? • ミドルウェアの仕様上、A / AAAAの両方の名前解決が行われていた • 当時のOSの設定上、ショートネーム指定だと余分に一回名前解 決が行われる動作となっていた • 1024 ÷ 2 ÷2 ＝ 約256回/秒の名前解決で上限に達する • 一斉にサイトアクセスが開始するケースなどでは、 ミドルウェアの動作によっては起こりうる 【1024 PPS 超過によるパケットドロップ】 EC2 Instance (ENI) DNS Query > 1024 PPS ↓ ENI制限 で遮断 Route 53 Resolver に届かない (ログ・メトリクスに残らずドロップ) • 枠はDNS専用ではなく、IMDSやNTPと共有する 参考：https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/AmazonDNS-concepts.html
23. トピック4: 性能試験で、名前解決だけが断続的に失敗する 4-3. どうしたか ▪ 実施した対応 • 対応できる範囲で余分な問い合わせを減らした • 処理を複数インスタンス/複数ENIに水平分散した • キャッシュ対応などで緩和できるケースもあるが、その場合はトピック2で書いたTTLの件を要注意
24. トピック4: 性能試験で、名前解決だけが断続的に失敗する 4-4. 教訓4 • 1024 PPS/ENI は引き上げ不可。しかも机上では見落としやすい • こうした上限は、本番相当の負荷をかけて初めて姿を見せる → 負荷試験は「隠れた上限に当たらないか」を見る場でもある
25. トピック 5 検査を入れたのに、 ルールが動いてくれない
26. トピック5: 検査を入れたのに、ルールが動いてくれない 5-1. 起きた事象 • セキュリティ要件で、Inbound通信の検査にNetwork Firewallが必要だった（AWS WAFとは別に設置） • ただし「FWを外側・ALBを内側」に置く構成は取れなかった → VPC Originなど、インターネットからの流入がIGWを経由しない構成では、検査点はALBの後段 （VPC内部の区間）になる • ルートテーブルは設計どおりで、経路的には通っているはず • しかしInboundで攻撃通信を投げても、検知もブロックもされない
27. トピック5: 検査を入れたのに、ルールが動いてくれない 5-2. 何が起きていたか ▪ HOME_NETのデフォルト挙動（公式） • 明示しない場合、HOME_NETは「Network Firewallがデプロイさ れているVPCのCIDR」になる • EXTERNAL_NETは、指定したHOME_NETの否定として自動的に 維持される ▪ ALB後段で何が起きるか 注：検知したいのはこの通信 ↓ HTTPS ※VPC外 HOME_NET (VPC CIDR) • トラフィックはALB発、宛先はバックエンド → 送信元も宛先も VPC CIDR内、つまり両方がHOME_NETに入る • マネージドルールの多くは EXTERNAL_NET → HOME_NET が 検査条件 → HOME_NET to HOME_NET の通信は条件に入らず、 検査されない 注：FWに届く時点では送信元がALB＝HOME_NET。 EXTERNAL_NET → HOME_NET のルールに掛からない
28. トピック5: 検査を入れたのに、ルールが動いてくれない 5-3. どうしたか • ファイアウォールポリシーのポリシー変数でHOME_NETを明示的に定義する • 定義を変えたうえで、攻撃通信を投げて検知されることを確認する • 確認はアラートログで行い、どのルールにヒットしたかまで見る
29. トピック5: 検査を入れたのに、ルールが動いてくれない 5-4. 教訓5 • HOME_NETのように、明示しなければデフォルト値が入る設定がある → そのデフォルトが自分の構成に合っているかを疑う • 「どの通信が、どの条件でルールにマッチするのか」を理解しておく （EXTERNAL_NET → HOME_NET が条件なら、内部通信は検査されない） • 入れて終わりにせず、検知されることを実際に試して確認する
30. まとめ マネージドサービスは簡単に使い始められる。 でも裏側の動作をある程度意識しないと、どこかでハマる。 表面的に使えるだけで終わらせず、 手を動かして確かめ、裏側を意識して設計することが重要
31. ご清聴ありがとうございました