AWS CloudFrontとWAFで実現する堅牢なIP制限設定ガイド

CloudFrontとWAF連携によるIP制限の基本と全体フロー

増加するサイバー脅威とクラウドセキュリティの現状

近年、サイバー攻撃はますます巧妙化し、その脅威は深刻さを増しています。独立行政法人情報処理推進機構（IPA）が発行する「情報セキュリティ白書2025」や「情報セキュリティ10大脅威 2026」によると、ランサムウェアやDDoS攻撃は引き続き拡大しており、特に社会インフラを標的とする攻撃の増加が指摘されています。このような背景の中、国内企業におけるクラウドサービス利用率は83.5%に達しており（総務省「令和7年通信利用動向調査」）、多くの企業が業務の基盤をクラウドへ移行しています。

クラウド環境は利便性が高い一方で、インターネットに公開される部分が多いため、適切なセキュリティ対策が不可欠です。特に、特定のアクセス元を制限するIPアドレス制限は、不正アクセスを防ぐための基本的ながら非常に重要な対策となります。この対策を怠ると、情報漏洩やサービス停止のリスクが高まります。

AWS CloudFrontとAWS WAFを組み合わせることで、グローバルなコンテンツ配信を維持しつつ、エッジロケーションで効果的なIPベースのアクセス制御を実装し、企業の資産を保護することが可能です。

AWS CloudFrontとWAFによるIP制限のメリット

AWS CloudFrontとAWS WAFを連携させたIP制限は、従来のオンプレミス環境や単一のサーバーでのIP制限と比較して、いくつかの大きなメリットを提供します。まず、WAFはCloudFrontのエッジロケーションで動作するため、不正なリクエストがオリジンサーバー（S3やALBなど）に到達する前にブロックされます。これにより、オリジンサーバーへの負荷が軽減され、サービス全体の可用性が向上します。DDoS攻撃のような大量の不正アクセス試行に対しても、エッジで防御することで、アプリケーションへの影響を最小限に抑えることができます。

また、CloudFrontは世界中のエッジロケーションを通じてコンテンツを高速配信するため、WAFを導入してもパフォーマンスを損なうことなく、高いセキュリティレベルを維持できます。グローバルに展開するサービスであっても、地域ごとに異なるIP制限ポリシーを適用するなど、柔軟な設定が可能です。さらに、AWS WAFはマネージドサービスであるため、インフラの管理やパッチ適用などの運用負荷が大幅に軽減され、セキュリティ専門家が不足している企業でも導入しやすいという利点があります。

IP制限設定の全体フローと考慮点

AWS CloudFrontとWAFによるIP制限は、主に以下の3つのステップでエッジでの防御を実現します。最初のステップは、AWS WAFコンソールで許可または拒否したいIPアドレス（CIDR表記）をリスト化し、「IPセット」を作成することです。CloudFrontを保護する場合、リージョンは必ず「Global (CloudFront)」を選択する必要があります。次に、作成したIPセットをAWS WAFの「Webアクセスコントロールリスト（Web ACL）」にルールとして紐付けます。この際、許可するIPアドレスのリスト（Allowリスト）と拒否するIPアドレスのリスト（Blockリスト）を明確に区別し、それぞれ適切なアクションを設定することが重要です。

最後のステップは、設定したWeb ACLを保護したいCloudFrontディストリビューションに関連付けることです。これにより、リクエストがオリジンに到達する前に、CloudFrontのエッジサーバー側でWeb ACLのルールに基づいてアクセス判定が行われます。設定時には、IPv4だけでなくIPv6でのアクセスも考慮した設計が不可欠です。また、複数のルールを適用する場合、ルールの評価順序（優先度）によって意図しないアクセス拒否が発生する可能性があるため、設定後の確認とテストが必須となります。

出典：総務省「令和7年通信利用動向調査」、IPA「情報セキュリティ白書2025」、IPA「情報セキュリティ10大脅威 2026」

AWS WAF WebACLとCloudFrontディストリビューション連携の具体的な手順

AWS WAFでIPセットを作成する

AWS WAFでIP制限を始める第一歩は、IPセットの作成です。AWSマネジメントコンソールにログインし、WAFのサービス画面へ移動します。ナビゲーションペインから「IP sets」を選択し、「Create IP set」をクリックしてください。IPセット名には、そのIPセットの目的がわかるような具体的な名前を付けましょう（例: “Allowed-Office-IPs” や “Blocked-Malicious-IPs”）。地域（Region）の選択が非常に重要で、CloudFrontを保護する場合は必ず「Global (CloudFront)」を選択してください。この選択を誤ると、CloudFrontにWeb ACLを関連付けることができません。

次に、許可または拒否したいIPアドレスをCIDR表記で入力します。例えば、「192.0.2.0/24」や「203.0.113.1/32」のように記述します。AWS WAFのIPセットあたりのCIDR最大数は10,000個であり（AWS公式「AWS WAF クォータ」）、多くのアドレスを管理できます。IPv4アドレスとIPv6アドレスの両方に対応可能ですので、企業のネットワーク環境やユーザーのアクセス元に応じて、両方のバージョンを考慮したリストを作成することが推奨されます。すべてのIPアドレスを入力したら、「Create IP set」をクリックして保存します。

Web ACLにIP制限ルールを追加する

IPセットが作成できたら、次にWeb ACLを作成し、IP制限ルールを追加します。AWS WAFコンソールで「Web ACLs」を選択し、「Create web ACL」をクリックします。Web ACL名とDescriptionを入力し、「Associated AWS resources」で「Add AWS resources」を選択して、保護したいCloudFrontディストリビューションを指定します。Web ACLが作成されたら、「Rules」タブに移動し、「Add rules」から「Add my own rules and rule groups」を選択します。

ここでは、「IP set rule」を選択し、先ほど作成したIPセットを指定します。Rule nameにはわかりやすい名前を付け（例: “Allow-Office-IP-Rule”）、Typeを「IP set」に設定します。次に、このルールに一致したリクエストに対してどのようなアクションを実行するかを決定します。許可したいIPセットであれば「Allow」、拒否したいIPセットであれば「Block」を選択します。複数のルールを設定する場合、ルールの優先順位（Priority）が非常に重要です。番号が小さいルールほど先に評価されるため、一般的には「拒否したいIPリスト（Block）」のルールを「許可したいIPリスト（Allow）」より低い優先順位に設定し、デフォルトで「Block」するか、あるいは「許可したいIPリスト」を先に評価し、それ以外をブロックする構成を検討することが安全です。ルール追加後、「Next」と進んでWeb ACLを完成させます。

CloudFrontディストリビューションにWeb ACLをアタッチする

Web ACLが完成したら、最後にこれを保護したいCloudFrontディストリビューションにアタッチします。これはWeb ACL作成時に同時に行うことも可能ですが、後からでも追加できます。AWS WAFコンソールで該当するWeb ACLを選択し、「Associated AWS resources」タブを開いて「Add AWS resources」をクリックします。表示されるリストから、IP制限を適用したいCloudFrontディストリビューションをチェックし、「Add」ボタンをクリックします。

この操作により、CloudFrontディストリビューションへの全てのリクエストは、まずWAFによって評価されるようになります。Web ACLのアタッチには、数分から十数分程度の時間がかかる場合があります。アタッチが完了すると、CloudFrontのエッジロケーションでIP制限が有効になり、指定したIPアドレスからのアクセスのみがオリジンサーバーに到達できるようになります。設定後は、実際にテストを行い、意図した通りにIP制限が機能しているか、そして正当なアクセスが阻害されていないかを必ず確認してください。予期せぬアクセス拒否を防ぐためにも、慎重な検証が重要です。

出典：Amazon CloudFront デベロッパーガイド「AWS WAF 保護を使用する」、AWS公式「AWS WAF クォータ」

多様なAWSリソースに対するCloudFront WAF IP制限の応用例

S3バケットへの静的ウェブサイトホスティングにおける保護

Amazon S3は、静的ウェブサイトのホスティングに広く利用されています。しかし、S3バケットを直接インターネットに公開すると、不要なアクセスやセキュリティリスクに晒される可能性があります。このリスクを軽減するため、S3バケットへのアクセスをCloudFront経由に限定し、さらにAWS WAFでIP制限をかけることが効果的です。具体的には、まずS3バケットをオリジンとするCloudFrontディストリビューションを設定し、S3バケットへの直接アクセスをブロックするために、オリジンアクセス制御（OAC）またはオリジンアクセスアイデンティティ（OAI）を構成します。

これにより、ユーザーはCloudFrontのエッジを経由しないとS3のコンテンツにアクセスできなくなります。次に、このCloudFrontディストリビューションにAWS WAFのWeb ACLをアタッチし、IPセットを利用して特定のIPアドレス範囲からのアクセスのみを許可するように設定します。例えば、社内IPアドレスからのアクセスのみを許可することで、管理画面や特定のコンテンツへのアクセスを限定し、外部からの不正なコンテンツ閲覧や改ざん試行を防ぐことができます。この構成は、高いセキュリティを保ちながら、S3の持つスケーラビリティと可用性を享受する上で非常に有効な手段です。

ALB/EC2をバックエンドとする動的アプリケーションの保護

動的なウェブアプリケーションの場合、Elastic Load Balancing (ALB)やAmazon EC2インスタンスがオリジンとして利用されることが一般的です。このような構成においても、CloudFrontとAWS WAFを組み合わせることで、アプリケーションレイヤーでのIP制限とセキュリティ強化を実現できます。CloudFrontをALB/EC2の前に配置することで、クライアントからのリクエストはまずCloudFrontのエッジに到達し、ここでWAFのルールに基づいて評価されます。

WAFのIP制限ルールによって、許可されたIPアドレスからのリクエストのみがALBを経由してEC2インスタンスに転送されるため、バックエンドのアプリケーションサーバーへの不正アクセス試行を大幅に減少させることができます。IP制限だけでなく、WAFの他のマネージドルール（例えば、SQLインジェクションやクロスサイトスクリプティング（XSS）対策）やカスタムルールと組み合わせることで、より多層的な防御を構築できます。これにより、ウェブアプリケーションの脆弱性を狙った攻撃に対しても、エッジで効果的に防御し、アプリケーションサーバーの負荷を軽減しながら、サービス全体のセキュリティを高めることが可能です。

複数の環境やサービスでのWAF活用戦略

企業が複数の開発環境、ステージング環境、本番環境を運用している場合、それぞれの環境で適切なWAF活用戦略を検討することが重要です。一般的に、本番環境では最も厳格なIP制限やセキュリティルールを適用しますが、開発環境やステージング環境では、開発者やテスターからのアクセスを確保しつつ、不必要な外部からのアクセスを制限するためにWAFを活用できます。例えば、開発チームのVPN接続元のIPアドレスのみを許可し、それ以外のアクセスをブロックすることで、開発中の情報を保護することが可能です。

また、AWS WAFのWeb ACLは、複数のCloudFrontディストリビューションにアタッチすることができます。これにより、共通のIP制限ポリシーを複数のサービスや環境に適用することが容易になります。ただし、環境ごとにアクセス要件が大きく異なる場合は、個別のWeb ACLを作成することも選択肢の一つです。WAFの設定変更を行う際は、いきなり本番環境に適用するのではなく、必ずテスト環境で十分な検証を行うことが推奨されます。WAFには「Count」モード（ルールに一致してもブロックせず、ログを記録するのみ）があるため、これを活用して、本番環境での影響を事前に評価することも有効な戦略となります。

CloudFront WAF運用時の注意点：リージョン、ログ、エラーハンドリング

AWS WAFリージョン選択と課金体系の理解

AWS WAFをCloudFrontと連携させる際、リージョン選択は非常に重要です。CloudFrontを保護する場合、WAFのWeb ACLは必ず「Global (CloudFront)」リージョンで作成する必要があります。この設定を誤ると、CloudFrontディストリビューションにWeb ACLを関連付けることができません。他のAWSリソース（例えばALBやAPI Gateway）を保護する場合は、それらのリソースがデプロイされているリージョンでWAFを設定することになるため、利用するサービスのオリジンに合わせて適切なリージョンを選択する知識が求められます。

次に、AWS WAFの課金体系について理解しておくことが重要です。WAFは、Web ACL単位の月額料金と、Web ACLに設定したルール数に応じた従量課金、さらに処理されたWebリクエスト数に応じた従量課金が発生します。例えば、Web ACLは月額$5程度、各ルールは月額$1程度（レートは利用状況により変動）の費用がかかります。これは、検証環境での利用後、不要なリソースを削除し忘れると、予期せぬコストが発生する可能性があることを意味します。常にAWSの公式ドキュメントで最新の料金情報を確認し、不要なWAFリソースは速やかに削除することで、コストを最適化できます。

ログとメトリクスによるWAFの効果的な監視

AWS WAFを導入したら、その効果を最大限に引き出すためには、継続的な監視が不可欠です。AWS WAFは、すべてのリクエストとそれに対するWAFの処理結果（許可/ブロック）を詳細なログとして記録できます。これらのログはAmazon CloudWatch LogsまたはAmazon S3に送信設定が可能です。WAFログを有効化することで、どのIPアドレスから、どのルールによって、いつ、どのようなリクエストがブロックされたのかを正確に把握できます。

ログを分析することで、潜在的な攻撃パターンを発見したり、意図しないアクセス拒否（誤検知）の原因を特定したりすることが可能になります。また、AWS CloudWatchメトリクスを利用すれば、WAFがブロックしたリクエスト数や許可したリクエスト数、特定のルールが適用された回数などをグラフで可視化できます。これらのメトリクスを監視することで、WAFが適切に機能しているか、あるいは攻撃を受けている兆候がないかをリアルタイムで確認し、迅速な対応へと繋げることができます。定期的なログ分析とメトリクス監視は、WAF運用の要とも言えます。

エラーハンドリングとルールの優先順位管理

WAFのルール設定は非常に強力ですが、その分、意図しないアクセス拒否を引き起こすリスクも伴います。特に、複数のIP制限ルールを適用する場合、ルールの評価順序（優先度）によって予期せぬ結果が生じることがあります。例えば、特定のIPアドレスを許可するルール（Allow）と、広範囲のIPアドレスをブロックするルール（Block）がある場合、BlockルールがAllowルールより先に評価されると、許可したかったIPアドレスからのアクセスもブロックされてしまう可能性があります。

このような問題を回避するためには、ルールの優先順位を慎重に設計し、変更を適用する前に必ずテスト環境で検証を行うことが重要です。WAFには「Count」モードという機能があり、ルールに一致したリクエストをブロックせず、ログに記録するのみの設定が可能です。これにより、実際にブロックする前にルールの影響範囲を評価できます。また、CloudFrontのカスタムエラーページ機能を利用して、WAFによってアクセスが拒否された際にユーザーに分かりやすいメッセージを表示したり、特定のリダイレクト先に誘導したりする設定も検討できます。適切なエラーハンドリングは、ユーザー体験を損なうことなくセキュリティを維持するために不可欠です。

【ケース】意図しないアクセス拒否発生からのWAF設定改善

架空のケーススタディ：WAF設定ミスによるサービス停止

ここでは架空のケースとして、とある企業がCloudFrontとAWS WAFを導入し、特定の管理画面へのアクセスを社内IPアドレスのみに制限していました。しかし、ある日、新しく導入されたリモートワーク用のVPN環境から管理画面にアクセスしようとしたところ、全ユーザーがアクセス拒否される事態が発生しました。このとき、既存のWAF設定では、社内IPアドレスを許可するAllowルールと、それ以外のアクセスをすべて拒否するDefault Blockルールが適用されていました。新VPN環境のIPアドレスをAllowリストに追加した際、担当者がルール追加手順を誤り、新しいAllowルールが既存のDefault Blockルールよりも低い優先順位に設定されてしまったのです。

結果として、WAFはDefault Blockルールを先に評価し、新しいVPN環境からのアクセスを全て拒否してしまいました。サービス停止とまではいかなくとも、管理業務が一時的に滞り、緊急対応が必要となりました。幸い、影響範囲は管理画面に限定されており、顧客向けサービスへの影響はなかったものの、IP制限設定一つで業務が中断する可能性を改めて認識する出来事となりました。このような問題は、設定変更時の確認不足やルールの優先順位に対する理解不足によって発生する可能性があります。

問題解決のためのログ分析とルール修正

上記のケースにおいて、問題解決のためにまず行われたのは、AWS WAFのログ（Amazon CloudWatch Logsに設定済み）の分析でした。ログには、どのIPアドレスからのリクエストが、どのWAFルールによってブロックされたかの詳細情報が含まれています。ログをフィルターして、新VPN環境のIPアドレスからのアクセスが、Default Blockルールによって拒否されていることを特定しました。これにより、新しいAllowルールが正しく機能していないことが判明しました。

原因がルールの優先順位にあると判明した後、AWS WAFコンソールでWeb ACLのルールリストを確認し、新VPN環境のIPアドレスを許可するAllowルールの優先順位を、Default Blockルールよりも高い（数字の小さい）値に修正しました。具体的には、既存のDefault BlockルールがPriority 100だった場合、新しいAllowルールをPriority 90に設定するといった対応です。この変更を適用した後、再び新VPN環境から管理画面へのアクセスを試行し、問題なくアクセスできることを確認しました。ログ分析とルールの優先順位の理解が、迅速な問題解決に繋がりました。

再発防止と継続的なWAF運用改善策

今回の事態を受けて、再発防止とWAF運用改善のためにいくつかの対策が講じられました。まず、WAFルールを変更する際には、必ずテスト環境で影響を検証するプロセスを確立しました。AWS WAFの「Count」モードを活用し、本番環境への影響を最小限に抑えながらルールの有効性を事前確認する運用を取り入れました。次に、WAFの設定変更を行う担当者に対して、ルールの優先順位の重要性と、Allow/Blockルールの適切な配置に関するトレーニングを実施しました。これにより、今後の設定ミスを防ぐための知識を共有しました。

また、IPアドレスリストの更新頻度を明確化し、VPN接続元IPアドレスやオフィスIPアドレスなど、変化する可能性のあるIPアドレスリストを定期的に見直す体制を構築しました。さらに、新しいIPアドレス範囲を追加する際は、既存のルールとの競合がないかをクロスチェックする手順を導入しました。これにより、偶発的なアクセス拒否のリスクを低減し、堅牢かつ柔軟なWAF運用を目指しました。継続的な改善活動を通じて、セキュリティと利便性のバランスを適切に保つことが重要です。