CloudFrontでIP制限をかける方法は2つあります。AWS WAFのIPセットを使う方法と、CloudFront Functionsで自前で判定する方法です。
どちらを選ぶかは、ほぼコストと運用しやすさで決まります。
| AWS WAF + IPセット | CloudFront Functions | |
|---|---|---|
| 設定方法 | マネジメントコンソールでIPセットを作りWeb ACLに紐づける | JavaScriptで判定コードを書く |
| CIDR・IPv6 | 標準で対応 | 自分で実装が必要 |
| 費用 | Web ACLの月額+リクエスト課金が発生(月5 USD程度〜) | リクエスト単価のみで安価 |
| 変更のしやすさ | 画面からIPアドレスを追加・削除できる | コードの書き換えとデプロイが必要 |
| 向いているケース | 本番環境、IP制限以外のWAFルールも使いたい | ステージング環境、単純なIP制限だけしたい |
IP制限だけが目的なら CloudFront Functions のほうが安く済みます。 一方、許可するIPアドレスを非エンジニアが管理する運用や、SQLインジェクション対策などのWAFルールも一緒に使いたい場合はWAFが向きます。
この記事の前提
本文の仕様・料金は2026年8月時点の情報です。AWSの料金体系は変わることがあるため、導入前にAWS公式の料金ページでご確認ください。
IPアドレスの例示にはドキュメント用の 203.0.113.0/24 などを使っています。
IP制限そのものの仕組みと、許可リスト方式で運用するときの前提はIP制限(IPアドレス制限)とは?仕組みと設定方法を解説にまとめています。
方法1:AWS WAFのIPセットで制限する
手順
203.0.113.10/32)。IPv4とIPv6は別々のIPセットになります。「許可リスト以外を拒否」の作り方に注意
IPセットのルールをそのまま Allow にすると、IPセットに一致したものを許可するだけで、それ以外は素通りします。許可リスト運用にするには、上の手順4のように「一致しない(NOT)」+ Block の組み合わせにするか、デフォルトアクションを Block にしてIPセット一致を Allow にする、のどちらかを選びます。
方法2:CloudFront FunctionsでIP制限する
CloudFront Functions は、ビューワーリクエストのタイミングでエッジロケーション上で実行される軽量なJavaScriptです。event.viewer.ip でアクセス元IPアドレスが取れるので、許可リストに載っていなければ403を返します。
function handler(event) {
var allowed = ['203.0.113.10', '198.51.100.25']
var clientIp = event.viewer.ip
if (allowed.indexOf(clientIp) === -1) {
return {
statusCode: 403,
statusDescription: 'Forbidden',
body: { encoding: 'text', data: 'Forbidden' },
}
}
return event.request
}
作成した関数は、ディストリビューションのビヘイビアで ビューワーリクエスト の関数として関連付けます。
CIDR(範囲指定)に対応させる場合
上のコードは完全一致の判定です。203.0.113.0/24 のような範囲で許可したい場合は、IPアドレスを数値に変換してマスクと比較する処理を自分で書く必要があります。
function ipToLong(ip) {
var p = ip.split('.')
return ((+p[0] << 24) >>> 0) + (+p[1] << 16) + (+p[2] << 8) + +p[3]
}
function inCidr(ip, cidr) {
var parts = cidr.split('/')
var mask = (-1 << (32 - parseInt(parts[1], 10))) >>> 0
return (ipToLong(ip) & mask) === (ipToLong(parts[0]) & mask)
}
この方式はIPv4しか扱えません。 IPv6も許可リストで扱う必要があるなら、実装の手間を考えるとWAFのほうが現実的です。
つまずきやすい落とし穴
IPv6が原因で意図せず403になる
もっとも多いトラブルです。 CloudFrontはIPv6が有効な状態で配信されており、クライアント側の環境によってはIPv4を許可していてもIPv6アドレスでアクセスしてしまい、許可リストに載っていないためブロックされます。
対処は次のいずれかです。
- 許可リストにIPv6アドレスも登録する(WAFならIPv6用のIPセットを作り、同じWeb ACLにルールとして追加する)
- ディストリビューションの IPv6 を無効にする(他の要件に影響しないか確認したうえで)
「自分のIPアドレスを登録したはずなのに403になる」場合は、まずグローバルIPアドレスの確認方法でIPv4とIPv6の両方を確認してください。
反映に時間がかかる
CloudFrontの設定変更は全エッジロケーションに配布されるため、反映まで数分かかります。保存直後にアクセスできてしまっても、設定が効いていないとは限りません。
許可するIPアドレスが変わってしまう
これは設定の問題ではなく前提の問題です。許可リストに登録したグローバルIPアドレスが変わると、その瞬間に全員がアクセスできなくなります。
一般的なインターネット回線で割り当てられる動的IPアドレスは、ルーターの再起動や回線の切断で変わります(IPアドレスが変わる原因とタイミング)。ステージング環境の保護であっても、開発メンバーが自宅から作業する体制なら、全員のアクセス元IPアドレスを1つに揃える構成にしておくのが確実です。
ロリポップ!固定IPアクセスのようなVPN型の固定IPサービスを使えば、回線を変えずに、どこから接続しても同じ固定グローバルIPアドレスになります。CloudFrontのIPセットに登録するのも、AWS以外のSaaSの許可リストに登録するのも、その1つで済みます。
⇒【ロリポップ!固定IPアクセス】 月額490円(税込539円)〜、すぐに使えて最大2ヶ月間無料!
CloudFrontのIP制限に関するよくある質問
WAFとCloudFront Functionsはどちらを選ぶべきですか?
IP制限だけが目的で、許可リストの変更頻度が低いならCloudFront Functionsが安く済みます。IP制限以外のWAFルールも使いたい場合や、許可するIPアドレスを画面から追加・削除できる運用にしたい場合はAWS WAFを選びます。
S3をオリジンにしている場合もCloudFrontでIP制限できますか?
できます。ただしS3バケットへ直接アクセスされる経路が残っていると意味がないため、Origin Access Control(OAC)などでCloudFront経由以外のアクセスを塞いだうえでIP制限をかけてください。
IPアドレスを登録したのに403になるのはなぜですか?
IPv6でアクセスしている可能性が高いです。IPv4アドレスだけを許可リストに登録していると、クライアントがIPv6で接続した場合にブロックされます。IPv6アドレスも登録するか、ディストリビューションのIPv6を無効にしてください。
特定のパスだけIP制限をかけられますか?
かけられます。AWS WAFならルールのステートメントにURIパスの条件を組み合わせます。CloudFront Functionsなら、関数を関連付けるビヘイビアをパスパターンで分けるか、関数内で event.request.uri を見て判定します。
CloudFront FunctionsとLambda@Edgeはどちらを使うべきですか?
単純なIP判定であればCloudFront Functionsで十分です。実行時間が短く単価も安いためです。外部APIの呼び出しなど重い処理が必要な場合にLambda@Edgeを検討します。
まとめ
CloudFrontのIP制限は、AWS WAFのIPセットかCloudFront Functionsのどちらかで実装します。単純なIP制限ならFunctionsが安く、運用のしやすさとIPv6対応を優先するならWAFです。
そして、どちらを選んでも成否を分けるのは許可リストに登録するグローバルIPアドレスが固定されているかという一点です。AWS側の設定は数分で終わりますが、その前提が崩れると全員が締め出されます。
AWS関連ではAWSで固定IPを設定する方法|Elastic IPの取得手順と料金、API GatewayのIP制限設定ガイドもあわせてご覧ください。




