CloudFront | さゆフィクション

ALB(ロードバランサー)でCloudFront経由のアクセスに絞るときは、カスタム HTTP ヘッダーとマネージドプレフィックスリストを併用する

sayu — Sun, 30 Jun 2024 07:40:39 +0000

ALB(ロードバランサー)でCloudFront経由のアクセスに絞る方法として、以下の方法があると思います。

マネージドプレフィックスリスト(managed prefix list)によりアクセスを絞る
カスタム HTTP ヘッダーによりアクセスを絞る

上記はよく知られた方法かと思いますので、詳細は割愛します。

本記事で記載したいことは、上記2つを併用した方が安心だよということです。

まずは、用語の説明からです。

用語の説明

マネージドプレフィックスリスト(managed prefix list)とは

AWS Managed Prefix Listは、AWSによって管理されるIPアドレスのプレフィックスリストです。特定のAWSサービス（例えばCloudFrontやAmazon S3など）のIPアドレス範囲を含んでおり、ネットワーク設定やセキュリティ設定を簡素化するために使用されます。

本記事では、「マネージドプレフィックスリスト＝CloudFrontのIP」として記載します。

カスタム HTTP ヘッダー

カスタム HTTP ヘッダーは、HTTP リクエストやレスポンスに含まれるユーザー定義のヘッダーであり、標準の HTTP ヘッダーではカバーされない追加の情報を送信するために使用されるものです。

なぜ併用した方がいいのか

ALB(ロードバランサー)でCloudFront経由のアクセスに絞る際に、マネージドプレフィックスリストとカスタム HTTP ヘッダーを併用する場合、以下のようになります。

マネージドプレフィックスリスト(managed prefix list)によるアクセス制限
- IP制限により、CloudFront経由のアクセスを絞る
  - CloudFront経由であれば、別アカウントのものでも許可してしまう
カスタム HTTP ヘッダーによるアクセス制限
- カスタムHTTPヘッダーにより、CloudFront経由にアクセスを絞る
  - 自分が作成したCloudFrontのみにアクセスを絞ることができる
→マネージドプレフィックスリストとカスタム HTTP ヘッダーを併用することで、自分が作成したCloudFrontのみにアクセスを絞ることができる

マネージドプレフィックスリスト(managed prefix list)だけでは、CloudFrontのIP制限のため、CloudFrontからの接続であれば、別アカウントのものでも許可してしまいます。

そのため、カスタム HTTP ヘッダーも併用が必要となります。カスタム HTTP ヘッダーにより、自分が作成したCloudFrontのみにアクセスを絞ることができます。

2段階で網をかけておいた方が安心ですね。

カスタム HTTP ヘッダーとマネージドプレフィックスリストの設定方法

公式記事に詳しく書いてあるので、以下の公式の記事をご参照ください。

Application Load Balancer へのアクセスを制限する - Amazon CloudFront

Amazon CloudFront でカスタムオリジンヘッダーを使用して、ユーザー（閲覧者）が Application Load Balancer に直接アクセスできないようにします。

まとめ

ALB(ロードバランサー)でCloudFront経由のアクセスに絞るときは、カスタム HTTP ヘッダーとマネージドプレフィックスリストを併用するのが良いです。

マネージドプレフィックスリスト単体でも、https(443)の通信にしているから問題とならないケースもあると思いますが、基本的にはカスタム HTTP ヘッダーとマネージドプレフィックスリストを併用した方が安心かと思います。

CloudFrontログのHTTP ステータスコード000について調べてみた

sayu — Sat, 13 May 2023 03:11:24 +0000

CloudFrontログのHTTP ステータスコード000について、どのような場合に発生するか調べてみました。

CloudFrontログでHTTP ステータスコードが000のモノをよく見るけど、これはどういった時に発生するのか、無視していいモノなのか分かりませんでしたので、調べましたーという内容になります！

公式ガイドでは、以下の記載があります。

000。この値は、サーバーがリクエストに応答する前に、ビューワーが接続を閉じたことを示します。サーバーがレスポンスの送信を開始した後にビューワーが接続を閉じた場合、このフィールドには、サーバーが送信を開始したレスポンスの HTTP ステータスコードが含まれます。

標準ログ (アクセスログ) の設定および使用 - Amazon CloudFront
ログファイルを使用してオブジェクトに対するユーザーリクエストに関する情報を取得します。
docs.aws.amazon.com

「ビューワーが接続を閉じたこと＝ブラウザを閉じた」と考えていいものかという疑問です。

Lambda@Edgeを使ってSleepを入れながら確認した結果、HTTP ステータスコードが000は、ブラウザを閉じた場合など接続が切れた場合に発生することが分かりました！

接続が切れた場合なので、基本的に無視して良い(どうしようも無い)ログということです。

ポイント

＜疑問＞
CloudFrontログでHTTP ステータスコードが000のものは何者？
＜調査方法＞
Lambda@Edgeを使ってSleepを入れながら確認
＜調査結果＞
ブラウザを閉じた場合など接続が切れた場合に発生する

調査方法の詳細と調査結果を書いていきます！

調査方法

CloudFrontのオリジンをS3にして作成し、Lambda@Edgeを使ってSleepを入れながら確認しました。

まずは、調査の準備について記載します。

調査準備

CloudFrontとS3の作成

S3バケットを作成
CloudFrontのディストリビューションをオリジン：S3に設定して作成

次にSleepを入れるLambda@Edgeを作成します！

リクエスト時のLambda@Edge

以下のものを作成しておきます。

const sleep = (m) => {
  return new Promise((resolve) => setTimeout(resolve, m));
};
export const handler = async(event) => {
    await sleep(2000);
    return event['Records'][0]['cf']['request'];
};

レスポンス時のLambda@Edge

以下のものを作成しておきます。

const sleep = (m) => {
  return new Promise((resolve) => setTimeout(resolve, m));
};
export const handler = async(event, context, callback) => {
    await sleep(2000);
    callback(null, event.Records[0].cf.response);
};

調査実施

以下のイベントのタイミングで、上記で用意したLambda@Edgeを実行し、Sleepするようにします。Sleepしている間に接続を切ったら、どのようになるか確認していきます。

ビューワーリクエスト
オリジンリクエスト
ビューワーレスポンス
オリジンレスポンス

各イベントの詳細は以下をご参照ください。

Lambda@Edge 関数をトリガーできる CloudFront イベント - Amazon CloudFront

特定の CloudFront イベントを使用して、Lambda 関数の実行をトリガーできます。

ビューワーリクエスト

ビューワーリクエストに「リクエスト時のLambda@Edge」を設定して、CloudFrontにアクセスし、Sleep中に通信を切断します。

動作確認には「ブラウザ」と「curlコマンド」を使用しました。