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

## はじめに
CloudFront を活用した信頼性、可用性の高いサービス提供について考えてみました。具体的には、次の３点となります。
#### **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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2920213/22b805db-87cf-8349-d9fa-79a09703f19d.png)

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

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


https://aws.amazon.com/jp/blogs/news/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/

**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 以外のトラフィックがインスタンスに到達できなくなります。

https://docs.amazonaws.cn/en_us/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html



## **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 ヘッダーシークレット値を含まないリクエストをブロックするルールを作成する。

https://repost.aws/ja/knowledge-center/waf-restrict-alb-allow-cloudfront


## **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 つのオリジンを含むディストリビューションのオリジングループを作成します。最後に、オリジングループを使用するようにキャッシュ動作を作成または更新します。

https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html


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

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