AWS CloudFront障害時にRoute 53のフェイルオーバーが効かない設定を見直した話

はじめに

久しぶりの投稿です。
毎週記事を書くといいながら2ヶ月も記事の投稿がストップしていました。
あ、サボっていたわけではありません。
実はこの2ヶ月間は資格の勉強をしていてAWS認定資格もちゃんと２つ取りました。
その後ワールドカップというイベントに参加して、世界のサッカートレンドを学習したり、なんやかんやで投稿を先送りにしていました。
言い訳はこのあたりにしまして、本題に参りたいと思います。

今回担当案件でインフラ構成にまずい部分がありました。
改善しましたので備忘録として残したいと思います。
説明下手でわかりにくい箇所等あるかと思います。ご了承ください。
また、ご指摘ご意見ありましたら教えてください！お待ちしています。

前提

構成は下の図のようになっています。
実際の構成はもっと複雑で冗長化もしているのですが、今回は必要な箇所だけ。

• CloudFrontからALB、そしてEC2インスタンスへ通信が進む。
• CloudFront障害時はRoute 53のフェイルオーバールーティングによりALBへトラフィックをルーティングする。
• 特定のIPアドレスのみ許可するため、ALBリスナールールに次を設定
  • HTTP Header
  • X-Forwarded-Forが通信OKのIPアドレスの場合、ターゲットのEC2インスタンスへトラフィックをルーティングする。
    
• CloudFrontからALBへcustom headerは渡さない
  • フェイルオーバー時にCloudFrontを経由しないため、custom headerを設定するとフェイルオーバールーティングがALBではじかれるため

課題

CloudFrontに障害が発生し、Route 53によりALBへフェイルオーバールーティングが行なわれた場合

CloudFrontを経由しないため、X-Forwarded-Forのリスナールールに一致せず、ALBでエラーを返してしまう。

custom headerを渡さないだけでなく、次の両者ともにALBのターゲットであるEC2インスタンスへの通信を可能な状態にしたい。

• トラフィックがCloudFront経由（X-Forwarded-For）でALBに来る場合
• トラフィックがCloudFrontを経由せずにALBに来る場合

改善案

ALBにおいてCloudFront経由（X-Forwarded-For）で来る場合とCloudFrontを経由しない場合のどちらのIPアドレスにもtargetへのルーティングを許可します。

解決策としては以下の2点を考えました。

1. ALBリスナールールにX-Forwarded-Forに加え、送信元IPアドレスを追加し、targetへ通信を許可する
   

   • メリット
     • 無料で設定可能
   • デメリット
     • リスナールールには上限あり
     • リスナールールが煩雑になり、管理しにくく漏れが発生する可能性あり。

2. AWS WAFを利用してIPのホワイトリストを設定し。ALBにアタッチ

   • メリット
     • 管理がしやすい
   • デメリット
     • 料金がかかる

設定方法等はこちらがわかりやすかったです。

解決

結局、管理面を考慮し、AWS WAFにルールを設けることになりました。
え、リスナールールの方が簡単だし、無料じゃん！とも思われますが、実際の環境ではたくさんの許可IPアドレスが存在し、さらにいくつかのパスも指定しなければいけませんでした。
リスナールールが複雑になってわかりにくいためWAFを利用しました。

最後に

AWSの業務をする時が一番楽しいなと感じる今日このごろ。
設計も答えは一つではなく、様々なパターンがあるんだなと日々勉強になっています。
そもそもCloudFrontに障害が起こる可能性ってどれくらいなのかなーと思ったりします。
調べてみるとちょこちょこあってるみたいですねー！
日々勉強です！
もっとこういう設計にすればいいじゃないという意見があればください！

参考