Amazon CloudFront ディストリビューションで複数種類のリクエストを特定のオリジンサーバーにルーティングする設定を行いたいです。各リクエストを、URL パスに応じて適切なオリジンに送信したいです。
解決策
パスパターンを定義する
CloudFront ディストリビューションの作成時に、キャッシュ動作を定義します。複数定義する場合、各動作には一意のパスパターンが必要です。その場合、CloudFront は、ディストリビューション内のリスト順でリクエストパスをパスパターンと照合します。
次の例は、パスパターンが関連するリクエストパスを照合する動作を示しています。
- /images/* では、/images/cat.jpg と /images/dog.png が一致します。
- /en/* では、/en/about と /en/contact が一致します。
- /app1/* では /app1/index.html が一致しますが、/app1app2/index.html は一致しません。
重要:
- パスパターンでは大文字と小文字が区別されます。たとえば、/images/cat.jpg は /Images/cat.jpg と一致しません。
- CloudFront は # 文字をフラグメント識別子として処理します。パスパターン照合では、フラグメント識別子は含まれません。# 文字を含む URL を照合する CloudFront 関数を作成してください。
- CloudFront は、パスを照合する前にパスを正規化します。たとえば、/path//file は**/path/** というパターンに一致します。
複数のオリジンを使用する
デフォルトでは、キャッシュ動作の各パスパターンには、1 つのオリジンのみを関連付けられます。
同じパスパターンを含むリクエストを複数のオリジンにルーティングするには、次の手順を実行します。
- クエリ文字列パラメータを使用してオリジンを区別します (例: /.jpg?origin=origin1 と /*.jpg?origin=origin2)。
- 同じパスパターンで使用するオリジンごとに、個別の CloudFront ディストリビューションを作成します。
- リクエストを検査し、リクエストを動的にオリジンにルーティングするためのカスタムコードを CloudFront Functions または Lambda@Edge を使用して記述します。
地理的位置に基づいてリクエストをルーティングする
CloudFront 関数を使用して cloudfront-viewer-country ヘッダーを検査し、ビューワーの地理的位置に基づいてリクエストを複数のオリジンにルーティングします。
次のコード例は、特定の国からのリクエストを別のキャッシュ動作にリダイレクトする CloudFront 関数を示しています。
function handler(event) {
var request = event.request;
var headers = request.headers;
var country = headers['cloudfront-viewer-country'];
// List of country codes to route to the first origin
var allowedCountries = ['US', 'CA'];
// Create the new URI to redirect to
var newUri = request.uri.replace('/api/', '/api-geo/');
if (allowedCountries.includes(country.value)) {
return request;
} else {
var response = {
statusCode: 302,
statusDescription: 'Found',
headers: {
location: {
value: newUri
}
}
};
return response;
}
}
この関数は、ビューワーの国が allowedCountries リストに含まれているかどうかを確認します。国がリストにある場合、この関数は、リクエストを /api/ 動作に進行させます。国がリストにない場合、この関数は、リクエストを /api-geo/ 動作にリダイレクトします。この関数は、リダイレクトを行うために URI を新規作成し、302 redirect 応答を返します。
キャッシュの問題を防ぐ
デフォルトでは、CloudFront はリクエスト URI と特定のヘッダーに基づいてレスポンスをキャッシュします。リクエスト URI またはヘッダーがオリジンに到達する前に、CloudFront 関数または Lambda@Edge を使用してそれらの値を変更した場合、キャッシュの不整合が発生する可能性があります。
キャッシュの問題を防ぐには、次のいずれかの手順を実行します。
- オリジンに到達する前にのみリクエストを変更する必要があり、現在のキャッシュ戦略を維持したい場合は、Lambda@Edge 関数を使用します。オリジンリクエストイベントは、この関数をトリガーする必要があります。リクエスト変更ロジックは、Lambda@Edge 関数に移動することをおすすめします。この関数は、キャッシュルックアップ後に有効化されたオリジンリクエストトリガーで実行する必要があります。その場合、キャッシュキーは、ビューワーによる本来のリクエストに基づいて決定されます。
- 特定のリクエスト属性に基づいて個別のキャッシュエントリを作成し、キャッシュを詳細に制御するには、カスタムキャッシュポリシーを作成します。キャッシュキーに追加のリクエストヘッダーまたはクエリ文字列を含めると、複数のリクエストに対し、一意のキャッシュキーを使用できます。
キャッシュ動作を変更する場合は、CloudFront から提供された既存のキャッシュファイルを削除することを推奨します。そうすることで、キャッシュ動作の更新が即時反映されます。
関連情報
すべてのディストリビューション設定に関するリファレンス
クエリ文字列パラメータに基づいてコンテンツをキャッシュする
Amazon CloudFront ジオロケーションヘッダーを州レベルの地理的ターゲティングに活用する