3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

お題は不問!Qiita Engineer Festa 2024で記事投稿!
Qiita Engineer Festa20242024年7月17日まで開催中!

ソリューションアーキテクトに求められる視点(4/14) CloudFront を活用した信頼性、可用性の高いサービス提供

Last updated at Posted at 2024-07-11

はじめに

CloudFront を活用した信頼性、可用性の高いサービス提供について考えてみました。具体的には、次の3点となります。

1.インターネット トラフィックが ALB に直接アクセスするのを防ぐ効率的な方法

2.悪意のあるリクエストを除外し、攻撃がアプリケーションに到達するのを防ぐ方法

3.ピーク時に Web サイトにアクセスしようとしたときに時々問題が発生する場合への対応

実務でも試験でも、ご参考にして頂けましたら、幸いです。

1.インターネット トラフィックが ALB に直接アクセスするのを防ぐ効率的な方法

ソリューションアーキテクトに求められる観点
インターネットに接続されたアプリケーションロードバランサー(ALB)の背後に配置されたプライベートサブネット内のAmazon EC2インスタンス群でアプリケーションを運用しています。このALBは、CloudFrontディストリビューションのオリジンとして機能しています。さらに、CloudFrontディストリビューションには、さまざまなAWSマネージドルールを含むAWS WAF Web ACLが関連付けられています。インターネット トラフィックが ALB に直接アクセスするのを防ぐ効率的なソリューションを提示して下さい。

ソリューション
ALB にセキュリティグループルールを追加して、CloudFront の AWS マネージドプレフィックスリストからのトラフィックのみを許可する。

解説
CloudFront のオリジン向けサーバーからのみオリジンへのインバウンドトラフィックを許可し、CloudFront 以外のトラフィックがオリジンに到達しないようにすることができます。オリジンがヨーロッパ (ロンドン) リージョン (eu-west-2) の Amazon EC2 インスタンスであるとします。インスタンスが VPC 内にある場合は、CloudFront マネージドプレフィックスリストからのインバウンド HTTPS アクセスを許可するセキュリティグループルールを作成できます。これにより、CloudFront のグローバルオリジン向けサーバーすべてがインスタンスに到達できるようになります。

マネージドプレフィックスリストを使用したオリジンへのアクセス制限イメージ
image.png

セキュリティグループでマネージドプレフィックスリストを使用する AWSブログ解説

CloudFront マネージドプレフィックスリストは、EC2 インスタンスや Application Load Balancer などのオリジンリソースにアタッチするセキュリティグループのインバウンドルールの一部として使用することができます。

AWS公式サイトでの解説
CloudFront マネージドプレフィックスリストには、CloudFront のグローバルに分散されたオリジン向けサーバーの IP アドレス範囲がすべて含まれています。オリジンが Amazon でホストされ、Amazon VPCセキュリティグループによって保護されている場合は、CloudFront マネージドプレフィックスリストを使用して、オリジンへのインバウンドトラフィックを CloudFront のオリジン向けサーバーからのみ許可し、CloudFront 以外のトラフィックがオリジンに到達しないようにすることができます。CloudFront はマネージドプレフィックスリストを維持しているため、常に CloudFront のグローバルなオリジン向けサーバーの IP アドレスが最新の状態に保たれます。CloudFront マネージドプレフィックスリストを使用すると、IP アドレス範囲のリストを自分で読み取ったり維持したりする必要がありません。

たとえば、オリジンがヨーロッパ (ロンドン) リージョン ( eu-west-2) の Amazon EC2 インスタンスであるとします。インスタンスが VPC 内にある場合は、CloudFront マネージドプレフィックスリストからのインバウンド HTTPS アクセスを許可するセキュリティグループルールを作成できます。これにより、CloudFront のグローバルオリジン向けサーバーすべてがインスタンスに到達できるようになります。セキュリティグループから他のすべてのインバウンドルールを削除すると、CloudFront 以外のトラフィックがインスタンスに到達できなくなります。

2.悪意のあるリクエストを除外し、攻撃がアプリケーションに到達するのを防ぐ方法

ソリューションアーキテクトに求められる観点

最近、悪意のある人物によるアプリケーションへの攻撃が増加しています。
AWS WAF を使用して直接トラフィックを ALB に制限し、CloudFront のみを通過するトラフィックを許可する方法を教えてください。

ソリューション
ALB をオリジンとして Amazon CloudFront ディストリビューションを作成します。CloudFront ドメインにカスタム ヘッダーとランダム値を追加します。ヘッダーと値が一致する場合に条件付きでトラフィックを転送するように ALB を設定します。

適切なルールグループを含む AWS WAF ウェブ ACL をデプロイします。ウェブ ACL を Amazon CloudFront ディストリビューションに関連付けます。

解説
CloudFront ドメインにカスタム ヘッダーとランダム値を追加し、ヘッダーと値が一致する場合に条件付きでトラフィックを転送するように ALB を設定することで、リクエスト検証の形式を実装できます。これにより、潜在的に悪意のあるリクエストを除外し、攻撃がアプリケーションに到達するのを防ぐことができます。

適切なルール グループを含む AWS WAF ウェブ ACL をデプロイし、それを Amazon CloudFront ディストリビューションに関連付けると、保護のレイヤーが追加されます。 ウェブ ACL には、一般的な攻撃パターンをブロックし、SQL インジェクションやクロスサイト スクリプティング (XSS) などのさまざまな種類の攻撃に対する保護を提供するルールを含めることができます。

AWS re:Postでの解説
AWS WAF を使用して直接トラフィックを ALB に制限し、CloudFront のみを通過するトラフィックを許可する方法を教えてください。

解決方法
ALB への直接トラフィックを制限し、AWS WAF を使用して CloudFront のみを通過するトラフィックを許可するには、以下を実行します。

CloudFront が ALB に送信するリクエストにシークレット値を持つカスタム HTTP ヘッダーを追加するように CloudFront を設定する。
ALB に関連付けられた AWS WAF ウェブ ACL で、カスタム HTTP ヘッダーシークレット値を含まないリクエストをブロックするルールを作成する。

3.ピーク時に Web サイトにアクセスしようとしたときに時々問題が発生する場合への対応

ソリューションアーキテクトに求められる観点
一部のユーザーから、ピーク時に Web サイトにアクセスしようとしたときに時々問題が発生するという報告がありました。運用チームは、ALB が HTTP 503 Service Unavailable エラーを返すことがあることを発見しました。この会社では、これらのエラーが発生したときにカスタムエラーメッセージページを表示したいと考えています。

ソリューション
2 つのオリジンを持つ CloudFront オリジン グループを作成します。ALB エンドポイントをプライマリ オリジンとして設定します。セカンダリ オリジンには、静的 Web サイトをホストするように設定された S3 バケットを設定し、CloudFront ディストリビューションのオリジン フェイルオーバーを設定します。カスタム エラー ページを組み込むように S3 静的 Web サイトを更新します。

解説
2 つのオリジンを持つ CloudFront オリジングループを使用することで、ALB エンドポイントと静的ウェブサイトをホストしている S3 バケット間のフェイルオーバーを設定できます。これにより、ALB が HTTP 503 Service Unavailable エラーを返す場合、CloudFront は自動的に S3 バケットにフェイルオーバーし、カスタム エラー ページを提供します。CloudFront ディストリビューションのオリジン フェイルオーバーを設定すると、プライマリ オリジンが利用できない場合にセカンダリ オリジンに即座にフェイルオーバーできます。これにより、ALB エラーの影響が最小限に抑えられ、カスタム エラー ページを表示することでユーザーにシームレスなエクスペリエンスが提供されます。カスタム エラー ページを組み込むように S3 静的ウェブサイトを更新すると、エラー ページがすぐに利用可能になり、追加の処理や遅延なしでユーザーに提供できるようになります。

AWS公式サイトでの解説
高可用性が必要なシナリオでは、オリジンフェイルオーバーを使用するように CloudFront を設定できます。 開始するには、プライマリとセカンダリの 2 つのオリジンを持つオリジングループを作成します。プライマリオリジンが使用できない場合、または障害を示す特定の HTTP レスポンスステータスコードを返す場合、CloudFront は自動的にセカンダリオリジンに切り替わります。

オリジンフェイルオーバーを設定するには、少なくとも 2 つのオリジンを持つディストリビューションが必要です。次に、1 つをプライマリとして設定した 2 つのオリジンを含むディストリビューションのオリジングループを作成します。最後に、オリジングループを使用するようにキャッシュ動作を作成または更新します。

ソリューションは、あくまで、一例です。他の解決方法もあるので、参考程度にしてください。

読んでいただき、ありがとうございました。

3
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?