CloudFront Functionsの新機能でエッジロケーション情報を取得して、オリジン切り替えを試してみた
2025年11月20日、Amazon CloudFront で、3つのCloudFront Functions機能が追加されるアップデートがありました。
今回のアップデートにより、CloudFront Functions（CFF）内でエッジロケーションの空港コードやRegional Edge Cache（REC）の情報が取得可能になり、さらに**オリジンを動的に選択（変更）**できるようになりました。
本機能の検証にあたり、今回ちょうど米国ダラス・フォートワース国際空港（DFW）周辺に滞在する機会がありました。そこで、VPNやプロキシによる擬似的なアクセスではなく、現地の物理ネットワークを利用して、実際に現在地の空港コードが DFW として正しく取得できるか、ログと実機挙動で裏付けを取りました。
現在地
新機能の概要と検証シナリオ
今回検証する主な機能は以下の通りです。
- エッジロケーション情報の取得 (
cf.edgeLocation): 空港コード（IATA）、REC、サーバーIPの取得。 - オリジンの動的変更 (
cf.selectRequestOriginById): リクエストごとに接続先オリジンを変更。
検証シナリオ
**「テキサス州ダラスからのアクセスはダラス専用のS3バケットへ、それ以外はデフォルトのS3バケットへルーティングする」**構成を構築し、アクセス元によってコンテンツが切り替わるかを確認します。
- 検証場所: 米国テキサス州 フラワーマウンド（DFW空港 近郊）
- ネットワーク: 現地ISP（Spectrum）経由の物理回線
CloudFormationによる検証環境の構築
検証の再現性を担保するため、CloudFormation（IaC）で環境を定義しました。
新機能を利用するには、CloudFront Functionsのランタイムとして cloudfront-js-2.0 を指定する必要があります。
テンプレート（抜粋）
AWSTemplateFormatVersion: '2010-09-09'
Resources:
# 1. CloudFront Function (Runtime 2.0)
RoutingFunction:
Type: AWS::CloudFront::Function
Properties:
Name: !Sub '${AWS::StackName}-routing'
AutoPublish: true
FunctionConfig:
Comment: 'Route based on Edge Location'
Runtime: cloudfront-js-2.0
FunctionCode: |
import cf from 'cloudfront';
function handler(event) {
var request = event.request;
var edge = cf.edgeLocation;
// エッジロケーション情報をヘッダーに付与（検証用）
request.headers['x-edge-code'] = { value: edge.name };
request.headers['x-edge-rec'] = { value: edge.region };
request.headers['x-server-ip'] = { value: edge.serverIp };
// ダラス（DFW）のエッジ経由の場合、専用オリジンへルーティング
if (edge.name === 'DFW') {
cf.selectRequestOriginById('dallas-origin');
} else {
cf.selectRequestOriginById('default-origin');
}
return request;
}
# 2. CloudFront Distribution
MyDistribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Enabled: true
# 2つのオリジンを定義
Origins:
- Id: default-origin
DomainName: !GetAtt DefaultBucket.DomainName
S3OriginConfig:
OriginAccessIdentity: ''
- Id: dallas-origin
DomainName: !GetAtt DallasBucket.DomainName
S3OriginConfig:
OriginAccessIdentity: ''
DefaultCacheBehavior:
TargetOriginId: default-origin # デフォルト設定
FunctionAssociations:
- EventType: viewer-request
FunctionARN: !GetAtt RoutingFunction.FunctionARN
上記テンプレートをデプロイし、2つのS3バケットにそれぞれ異なる index.html を配置しました。
- DallasBucket:
<h1>Hello from Dallas Origin (DFW)</h1> - DefaultBucket:
<h1>Hello from Default Origin</h1>
動作検証
実際にクライアントからリクエストを送信し、レスポンスとログを確認します。
1. テキサス州（ダラス近郊）からの実アクセス
滞在先のネットワークから curl を実行し、接続されたエッジロケーションと返却されたコンテンツを確認しました。
$ curl -v https://d1xxxxxxxx.cloudfront.net/index.html
実行結果（レスポンスヘッダーとBody）:
< HTTP/2 200
< date: Sun, 30 Nov 2025 23:00:00 GMT
< x-edge-code: DFW
< x-edge-rec: us-east-1
< x-server-ip: 18.160.xxx.xxx
...
<h1>Hello from Dallas Origin (DFW)</h1>
検証の結果、カスタムヘッダー x-edge-code に DFW が返却されました。
また、HTMLの内容もダラス用バケットのものが表示されており、物理的な位置情報に基づいて正しく dallas-origin が選択されたことを確認しました。
2. 日本（東京）からのアクセス
比較のため、AWS CloudShell（東京リージョン）を利用して日本からのアクセスを行いました。
[cloudshell-user@ip-10-0-xx-xx ~]$ curl -v https://d1xxxxxxxx.cloudfront.net/index.html
実行結果:
< HTTP/2 200
< x-edge-code: NRT
< x-edge-rec: ap-northeast-1
...
<h1>Hello from Default Origin</h1>
こちらは成田（NRT）のエッジロケーションが選択され、デフォルトのオリジンへルーティングされました。
まとめ
今回の検証により、以下の事実が確認できました。
- エッジロケーション情報の正確性: DFW近郊からの物理アクセスに対し、CloudFront Functionsは正確に空港コード
DFWを返却しました。 - 動的ルーティングの動作: 取得したコードに基づき、
cf.selectRequestOriginByIdによって意図通りにオリジンが切り替わりました。
これにより、従来の国単位（GeoLocation）よりも遥かに細かい、都市レベルやネットワークトポロジーに基づいたトラフィック制御が可能になることが実証されました。
日本国内においても、例えば東京（NRT/HND）と大阪（KIX）でオリジンを振り分けるような構成が可能か、帰国後に追って検証してみたいと思います。
