AWS CloudFront Functions徹底解説！リダイレクト、認証、IP制限の実践ガイド

CloudFront Functionsの基本と全体像：高速処理を理解する

CloudFront Functionsとは何か？その役割と仕組み

CloudFront Functionsは、AWSのCDNエッジロケーションで動作するサーバーレスなJavaScript実行環境です。ユーザーからのリクエストが最も近いエッジロケーションに到達した際、CloudFrontがこの軽量なコードを起動し、リクエストやレスポンスをリアルタイムで操作します。その最大の特長は、サブミリ秒という驚異的な速さで処理が完了する点にあり、ウェブコンテンツの配信を遅延させることなく、URLのリダイレクト、HTTPヘッダーの書き換え、Basic認証といった処理を実現します。

具体的には、「ビューワーリクエスト」と「ビューワーレスポンス」という2つのタイミングでコードをトリガーできます。ビューワーリクエストはクライアントからCloudFrontへのリクエストが届いた直後、ビューワーレスポンスはCloudFrontからクライアントへレスポンスを返す直前を指します。これにより、クライアントとCloudFront間での通信を柔軟に制御し、コンテンツ配信の最適化やセキュリティ強化に貢献します。ランタイムはECMAScript 5.1に準拠しており、馴染みのあるJavaScript構文で記述できます。

この仕組みにより、オリジンサーバーに到達する前に不要なリクエストをフィルタリングしたり、リクエストパスを書き換えたりすることが可能となり、オリジンサーバーの負荷軽減や応答速度の向上に直結します。特に、大規模なウェブサービスやグローバル展開しているコンテンツ配信において、高いパフォーマンスと低レイテンシーなユーザー体験を提供するための強力なツールとなります。

なぜ今CloudFront Functionsが注目されるのか：市場動向とエンジニア需要

現在の日本のパブリッククラウドサービス市場は急速に拡大しており、2024年には4兆1,423億円規模に達すると総務省が予測しています。このような市場背景の中で、企業はデジタルトランスフォーメーション（DX）を加速させ、クラウドサービスの活用が不可欠となっています。これに伴い、AWSのようなクラウドプラットフォームを使いこなせるクラウドエンジニアの需要は極めて高く、厚生労働省のデータによると、ITエンジニアの新規有効求人倍率は2026年4月時点で2.6倍にも上るとされています。

CloudFront Functionsは、こうしたDX推進のニーズに応える形で注目を集めています。その理由の一つは、Webアプリケーションのパフォーマンスとセキュリティを向上させる能力です。高速なエッジ処理により、ユーザーはより快適にコンテンツにアクセスでき、企業はシステムの応答性向上とセキュリティ強化を両立できます。特に、サブミリ秒で完了する処理は、ユーザー体験に直接的な影響を与えるため、顧客満足度向上に寄与します。

また、CloudFront Functionsは非常に安価に利用できる点も魅力です。月間200万件の無料枠が提供されており、小規模なウェブサイトから大規模なアプリケーションまで、多くのユースケースでコスト効率の良い運用が可能です。クラウド市場の成長とエンジニア不足が続く中で、効率的かつ高性能なサービスを提供できるCloudFront Functionsは、開発者や企業にとって非常に価値の高い選択肢となっています。

出典：総務省、厚生労働省

Lambda@Edgeとの決定的な違い：最適な使い分け

CloudFront Functionsとよく比較されるのが、同じくCloudFrontと連携する「Lambda@Edge」です。この二つのサーバーレス機能は、どちらもエッジロケーションでコードを実行しますが、その特性と適したユースケースには明確な違いがあります。CloudFront Functionsは、まさに「高速・軽量・安価」という言葉がぴったりで、サブミリ秒単位で完了する処理に特化しています。具体的には、リクエスト/レスポンスヘッダーの変更、URLのリダイレクトや書き換え、Basic認証など、比較的シンプルなロジックをエッジで迅速に実行したい場合に最適です。

一方で、Lambda@Edgeはより「複雑・長時間実行・外部通信」が必要な処理に適しています。実行時間は最大で30秒まで許容され、外部のデータベースやAPIとの連携、画像のリサイズや動画のトランスコーディング、認証情報の検証ロジックとの連携など、より高度なコンピューティングリソースを必要とするシナリオでその真価を発揮します。また、リクエストボディへのアクセスやバイナリ操作が可能な点も大きな違いです。

つまり、どちらを選ぶべきかは、実現したい機能の複雑さと実行要件によって決まります。シンプルで高速性が求められる処理にはCloudFront Functionsを、外部リソースとの連携や重い処理にはLambda@Edgeを選択することが、パフォーマンスとコスト効率の両面で最も効果的な戦略となります。適材適所の原則を理解し、両者の強みを最大限に活かすことが重要です。

主要機能の設定手順：リダイレクト、Basic認証、IP制限の実装

高速リダイレクトの実践：ユーザー体験を損なわない遷移

CloudFront Functionsを利用した高速リダイレクトは、ユーザーの利便性を高め、SEO対策にも有効な手段です。例えば、サイトリニューアルでURL構造が変わった場合や、特定のキャンペーンページに一時的に誘導したい場合などに活用できます。実装は非常にシンプルで、CloudFront FunctionsにJavaScriptコードを記述し、CloudFrontディストリビューションのビヘイビアに紐付けるだけです。

具体的なコードとしては、event.request.uri を評価し、特定の条件に合致した場合に response.statusCode = 302; （一時的なリダイレクト）または 301; （恒久的なリダイレクト）を設定し、response.headers.location.value = 'https://new-domain.com/new-path'; のようにリダイレクト先のURLを指定します。この処理はオリジンサーバーにリクエストが到達する前にエッジで完結するため、ユーザーは瞬時に新しいページへ遷移でき、表示速度の遅延を最小限に抑えられます。

設定手順としては、まずAWSマネジメントコンソールでCloudFront Functionsを作成し、JavaScriptコードを記述します。次に、その関数を公開し、CloudFrontディストリビューションのキャッシュビヘイビア設定で「ビューワーリクエスト」または「ビューワーレスポンス」イベントにその関数を関連付けます。これにより、該当するパスへのアクセスがあった際に、エッジでリダイレクト処理が実行されます。テストはCloudFront Functionsのプレビュー機能で行い、意図通りの動作を確認することが重要です。

Basic認証の実装：手軽にアクセス制限をかける方法

特定のコンテンツや管理画面など、一般公開したくないリソースに対して手軽にアクセス制限をかけたい場合、CloudFront FunctionsによるBasic認証が非常に有効です。複雑な認証システムを構築することなく、エッジで認証処理を行うため、オリジンサーバーへの負荷をかけずにセキュリティを強化できます。この方法は、例えば開発中のサイトを関係者のみに公開したり、特定のクライアントにのみ提供する資料サイトなどで活用されることがあります。

実装方法は、CloudFront FunctionsのJavaScriptコード内で、リクエストヘッダーに含まれる Authorization ヘッダーの値をチェックします。このヘッダーには、ユーザー名とパスワードをBase64エンコードした文字列が含まれています。コード内で定義した正しいユーザー名とパスワード（Base64エンコード済み）と比較し、一致しない場合は response.statusCode = 401; （Unauthorized）を返して認証ダイアログを表示させます。重要なのは、パスワードを直接コードにハードコードせず、AWS Secrets Managerなどを利用して安全に管理することを検討することです。

設定する際は、認証情報をBase64でエンコードした文字列を事前に用意します。CloudFront Functionsのコードに検証ロジックを記述し、ディストリビューションの該当するキャッシュビヘイビアに「ビューワーリクエスト」イベントとして関数をアタッチします。これにより、ユーザーが対象のコンテンツにアクセスしようとすると、CloudFrontエッジで認証が試みられ、正しい認証情報が提供されない限りコンテンツへのアクセスがブロックされます。手軽ながらも効果的なアクセス制御として、多くの場面で活躍するでしょう。

IP制限の基本：不正アクセスからサイトを守る第一歩

ウェブサイトやアプリケーションへの不正アクセスを防ぐための基本的なセキュリティ対策の一つがIP制限です。特定のIPアドレスからのアクセスのみを許可したり、特定の国や地域からのアクセスをブロックしたりすることで、悪意のある攻撃のリスクを低減できます。CloudFront Functionsを活用すれば、このIP制限をCloudFrontのエッジレベルで実装でき、オリジンサーバーに到達する前に不要なトラフィックを遮断することが可能です。

CloudFront FunctionsでIP制限を実装するには、event.request.clientIp を利用してアクセス元のIPアドレスを取得します。この取得したIPアドレスを、あらかじめJavaScriptコード内に記述した許可リストや拒否リスト（IPアドレスの配列など）と照合します。例えば、特定の管理画面には社内IPアドレスからのみアクセスを許可し、それ以外のIPアドレスからのアクセスは response.statusCode = 403; （Forbidden）を返すといった制御が可能です。これにより、組織内部からのアクセスのみを許可し、外部からの不正アクセス試行をエッジでブロックできます。

この機能は、特にVPNなどを利用して固定IPアドレスからアクセスする環境で有効です。設定する際には、許可したいIPアドレスやIPアドレスレンジ（CIDR形式）を正確にリストアップし、Functionsのコードに埋め込みます。その後、対象となるコンテンツパスのキャッシュビヘイビアに「ビューワーリクエスト」トリガーとして関数をアタッチします。IPアドレスのリストが頻繁に変わる可能性がある場合は、コードの更新とデプロイのプロセスを考慮する必要があります。WAFとの併用で、より多層的なセキュリティ対策を実現することも検討してください。

状況に応じた活用例：Index書き換えとCIDRによるIP制限

動的なIndexドキュメント書き換えでSEOとUXを向上

ウェブサイトでは、ディレクトリへのアクセス時に自動的に表示される「index.html」のようなIndexドキュメントが一般的です。CloudFront Functionsを活用することで、このIndexドキュメントの挙動を動的に変更し、ユーザー体験の向上やSEO対策に役立てることが可能です。例えば、モバイルデバイスからのアクセス時に、専用のモバイル版Indexドキュメントを表示したり、特定の時期にのみプロモーション用のIndexページに書き換えたりといった柔軟な運用が実現できます。

具体的な実装は、リクエストされたURIがディレクトリのルート（例: /blog/）であった場合に、event.request.uri を /blog/mobile-index.html や /blog/campaign-index.html のように書き換えるJavaScriptコードを記述します。これにより、オリジンサーバーは書き換えられたURIに基づいてコンテンツを返し、ユーザーはデバイスや条件に応じた最適なIndexページを閲覧できるようになります。この処理はエッジで実行されるため、オリジンサーバーのロジックを変更することなく、高速にコンテンツを出し分けられます。

この機能は、A/Bテストを実施してどのIndexページがより効果的かを検証する際や、多言語サイトでユーザーのロケールに応じたIndexページを出し分ける際にも応用できます。設定の際は、CloudFront FunctionsのコードでURI書き換えロジックを実装し、CloudFrontディストリビューションの該当キャッシュビヘイビアに「ビューワーリクエスト」イベントとして紐付けます。これにより、サーバーレスで手軽に動的なIndexドキュメントの制御が可能となり、ユーザー体験のパーソナライズとマーケティング戦略の柔軟性を高めることができます。

CIDRを使ったより高度なIPアドレス制限の実装

単一のIPアドレスだけでなく、複数のIPアドレス範囲をまとめて制限したい場合には、CIDR（Classless Inter-Domain Routing）表記を用いたIPアドレス制限が非常に有効です。CloudFront Functionsでは、このCIDR表記を利用して、より柔軟かつ効率的なアクセス制御をエッジレベルで実現できます。これにより、特定のオフィスネットワーク全体や、信頼できるパートナー企業のVPN接続元IPアドレスなど、広範囲なIPアドレスを一度に許可または拒否することが可能になります。

実装のポイントは、CloudFront FunctionsのJavaScriptコード内で、アクセス元のIPアドレス (event.request.clientIp) が、あらかじめ定義されたCIDRブロックのリストに含まれるかを判定するロジックを記述することです。例えば、社内ネットワークのIPアドレスレンジが「192.168.1.0/24」や「10.0.0.0/8」といった複数のCIDRブロックで構成されている場合でも、これらを配列として管理し、ループ処理で一つずつ照合することで、効率的にアクセスを制御できます。

この高度なIP制限を設定する際は、まず許可または拒否したいCIDRブロックのリストを正確に洗い出します。次に、それらを処理するJavaScriptコードをCloudFront Functionsに実装し、対象のCloudFrontディストリビューションにデプロイします。特に、セキュリティを目的としたIP制限の場合、リストの誤りや漏れがないかを厳重に確認することが不可欠です。複数のCIDRブロックを管理する際は、コードの見通しを良くし、将来的な変更にも対応しやすいように設計することが望ましいです。必要に応じて、AWS WAFとの連携も検討することで、さらに堅牢なセキュリティ体制を構築できます。

その他の応用例：ヘッダー操作とカスタムレスポンス

CloudFront Functionsの活用範囲は、リダイレクトやIP制限に留まりません。リクエストやレスポンスのHTTPヘッダーを柔軟に操作したり、特定の条件に基づいてカスタムレスポンスを返したりすることも可能です。これにより、コンテンツのキャッシュ制御を細かく調整したり、セキュリティヘッダーを追加して脆弱性対策を強化したり、あるいはAPIの認証トークンを動的に処理したりと、多岐にわたるユースケースに対応できます。

例えば、セキュリティヘッダーの追加では、Strict-Transport-Security や Content-Security-Policy などのヘッダーをレスポンスに動的に付与することで、Webアプリケーションの安全性を向上させることができます。また、A/Bテストを実施する際に、特定のユーザーグループに対してカスタムヘッダーを付与し、バックエンドサーバーでそのヘッダーを元に異なるコンテンツを返すといった使い方も考えられます。これにより、オリジンサーバーに大幅な変更を加えることなく、高度な制御が実現します。

さらに、カスタムレスポンス機能を利用すれば、オリジンサーバーがダウンしている場合や、メンテナンス中である場合に、CloudFront Functionsから直接、特定のHTMLコンテンツやエラーメッセージを返すことが可能です。これにより、ユーザーはサーバーエラー画面ではなく、事前に定義された友好的なメッセージを受け取ることができ、ユーザー体験の低下を最小限に抑えられます。これらの応用例を組み合わせることで、CloudFront Functionsは単なるCDNの補助機能を超え、Webアプリケーションの柔軟性と堅牢性を高める強力なツールとして機能します。

利用時の注意点：Lambda@Edgeとの選定基準と制限事項

Lambda@Edgeとの選定基準を理解する：どちらを選ぶべきか

CloudFront FunctionsとLambda@EdgeはどちらもCloudFrontのエッジでコードを実行しますが、特性が異なるため、目的に応じた選択が重要です。両者の主な違いを理解し、最適なサービスを選定することで、パフォーマンスとコストのバランスを最適化できます。以下の比較表を参考に、あなたの要件に合致する方を選んでください。

この表からわかるように、CloudFront Functionsは高速で軽量な処理に特化しており、安価に利用できる点が魅力です。一方、Lambda@Edgeは外部リソースとの連携や複雑なロジック、リクエストボディへのアクセスが必要な場合に選択すべきサービスです。例えば、単純なURLリダイレクトであればCloudFront Functions、ユーザー認証後に外部のDBと連携してパーソナライズされたコンテンツを生成するならLambda@Edgeが適しています。

選定の際は、まず最もシンプルなCloudFront Functionsで要件が満たせるか検討し、不足があればLambda@Edgeへの移行を検討するのが一般的なアプローチです。不要な機能に対してLambda@Edgeを使うと、コストが増大するだけでなく、実行時間の増大によりユーザー体験に影響を与える可能性もあります。それぞれの特性を理解し、プロジェクトの要件と予算に合わせて最適な選択を行うことが成功への鍵となります。

出典：Amazon CloudFront デベロッパーガイド、CloudFront Functions と Lambda@Edge の違い

CloudFront Functionsの機能制限と回避策

CloudFront Functionsは、その高速性と低コストを実現するために、いくつかの機能制限が設けられています。これらの制限を事前に理解しておくことで、開発時の予期せぬ問題を防ぎ、適切なサービス選定に役立ちます。最も重要な制限事項は、外部ネットワークへのアクセスができないことです。これは、データベースへの問い合わせや外部APIとの連携が必要な場合には、CloudFront Functionsを利用できないことを意味します。

また、リクエストボディへのアクセスやバイナリ操作もできません。例えば、POSTリクエストのペイロードを解析して処理を変更したい場合や、画像などのバイナリデータを処理したい場合には、CloudFront Functionsは利用できません。これらの機能が必要な場合は、迷わずLambda@Edgeを選択する必要があります。Lambda@Edgeであれば、より広範なコンピューティング機能とネットワークアクセスが提供されます。

さらに、ランタイム環境においては、一部のESモジュールやconst/let構文の制限など、JavaScriptの最新機能が完全にはサポートされていない場合があります（ECMAScript 5.1準拠が基本）。これはランタイムバージョンに依存するため、常にAWS公式ドキュメントで最新のサポート状況を確認することが重要です。これらの制限があるからといってCloudFront Functionsが劣っているわけではなく、高速・軽量な処理に特化しているがゆえの制約です。制限事項を把握し、それが必要な場合はLambda@Edgeという上位互換サービスを選ぶという明確な切り分けが、開発効率とパフォーマンスの両面で重要となります。

コスト最適化の秘訣：無料枠と適材適所

AWSのサービスを利用する上で、コストの最適化は常に重要な課題です。CloudFront Functionsは、その圧倒的な低コスト性が大きな魅力の一つであり、賢く利用することで大幅なコスト削減が期待できます。まず、特筆すべきは月間200万件という無料枠が提供されている点です。これにより、小規模なウェブサイトや開発環境であれば、実質的にコストをかけずにエッジでの処理を導入できます。

コスト最適化の秘訣は、まさに「適材適所」の原則を徹底することにあります。例えば、URLリダイレクトやヘッダーの変更といったシンプルな処理であれば、Lambda@Edgeよりもはるかに安価なCloudFront Functionsを利用すべきです。Lambda@Edgeは、その強力な機能と柔軟性ゆえに、CloudFront Functionsよりも高いコストがかかります。したがって、不必要な場面でLambda@Edgeを利用すると、想定外の費用が発生する可能性があります。

具体的なコスト削減戦略としては、まず現状のウェブアプリケーションでエッジ処理が必要な箇所を洗い出し、CloudFront Functionsで実現可能なタスクとLambda@Edgeが必要なタスクに分類します。可能な限りCloudFront Functionsを活用し、どうしても外部通信や複雑な処理が必要な場合にのみLambda@Edgeを導入することで、全体的なクラウド費用を抑えながら高いパフォーマンスを維持できます。定期的に使用状況を監視し、コストパフォーマンスを評価することも忘れないようにしましょう。

【ケース】セキュリティ強化を目指したIP制限の実装と改善

架空のケース：情報漏洩リスクを低減するIP制限の導入

ここでは、架空の企業「株式会社ウェブプロテクト」が抱えるセキュリティ課題と、それに対するCloudFront Functionsを用いたIP制限の導入事例を紹介します。ウェブプロテクト社は、従業員向けの機密情報共有サイトを運用しており、社内ネットワークからのみアクセスを許可したいと考えていました。しかし、従来のVPNアクセスでは遅延が発生しやすく、出張先からのアクセスも課題となっていました。情報漏洩リスクを最小限に抑えつつ、利便性を向上させる方法を模索していました。

同社は、特定のWebアプリケーションの管理画面や、社内資料をホストしているS3バケットへのアクセスを、許可されたIPアドレスからのみに限定する必要がありました。従来のオリジンサーバー側でのIP制限は、CDNを経由するためアクセス元IPアドレスがCloudFrontのIPになってしまい、機能しないという問題に直面していました。そこで、CloudFrontのエッジレベルでIP制限をかけることが解決策として浮上しました。

この状況に対し、CloudFront Functionsを活用することで、オリジンサーバーに到達する前に不正なIPアドレスからのアクセスをブロックするアプローチを検討しました。これにより、情報漏洩のリスクを大幅に低減し、同時にオリジンサーバーへの負荷も軽減できると判断しました。目的は、社内IPアドレスからのアクセスのみを許可し、それ以外のアクセスは403 Forbiddenを返すという明確なセキュリティポリシーの実装です。

実装と改善のステップ：CIDRブロックと複数のアクセスルール

株式会社ウェブプロテクトは、まず社内ネットワークのIPアドレス範囲をCIDRブロック形式で正確に特定しました。これには、本社の固定IPアドレスや、一部の拠点で使用しているVPN接続元の固定IPアドレスなどが含まれます。次に、CloudFront Functionsを作成し、JavaScriptコードにこれらのCIDRブロックをリストとして埋め込みました。コードでは、event.request.clientIp で取得したアクセス元IPアドレスが、この許可されたCIDRブロックリストのいずれかに含まれるかを判定するように記述しました。

実装の初期段階では、単一のCIDRブロックのみを許可するシンプルな構成でしたが、その後、特定の部署の管理者のみがアクセスできる「さらに重要な管理画面」があることが判明しました。そこで、CloudFront Functionsのコードを改修し、パスごとに異なるIP制限ルールを適用するように改善しました。例えば、/admin/* 以下のパスは全社内CIDRブロックを許可し、/super-admin/* 以下のパスは特定の管理者用IPアドレス（これもCIDRブロックで指定）のみを許可する、といった多層的なアクセス制御を実装しました。

さらに、出張先からのアクセスに対応するため、ウェブプロテクト社は契約しているセキュアなVPNサービス経由のアクセスを許可リストに追加しました。これにより、従業員は場所を問わず、VPN接続を介して安全に情報共有サイトにアクセスできるようになりました。これらの変更は、CloudFront Functionsのコードを更新し、関連するキャッシュビヘイビアに再デプロイすることで、ダウンタイムなしに適用されました。

導入後の注意点と運用改善：継続的なセキュリティ対策

CloudFront FunctionsによるIP制限の導入後も、株式会社ウェブプロテクトは継続的な運用改善とセキュリティ対策に注力しました。まず、最も重要なのはIPアドレスリストの定期的な見直しと更新です。社内ネットワーク構成の変更、新たな拠点やVPN接続の追加、あるいは従業員の異動などにより、許可すべきIPアドレスが変わる可能性があります。これらの変更があった際には、迅速にCloudFront Functionsのコードを更新し、再デプロイすることが求められます。

また、IP制限はあくまでセキュリティ対策の一部であり、万能ではありません。例えば、許可されたIPアドレスを持つ内部の人間による不正アクセスや、許可IPアドレスを偽装するスプーフィング攻撃のリスクは完全に排除できません。そのため、IP制限と合わせて、Basic認証（これもCloudFront Functionsで実装可能）や多要素認証、AWS WAFによるSQLインジェクションやクロスサイトスクリプティング対策など、複数のセキュリティレイヤーを組み合わせることが推奨されます。

運用面では、IPアドレスリストの管理をGitなどのバージョン管理システムで行い、変更履歴を追跡できるようにすることが重要です。また、CloudFront FunctionsのログをAmazon CloudWatch Logsで監視し、不正アクセス試行や予期せぬ挙動がないかを定期的にチェックすることも欠かせません。これらの継続的な運用と改善によって、株式会社ウェブプロテクトは情報漏洩のリスクを低減し、安全な情報共有環境を維持することを目指しています。