Lambda@Edgeのログ出力先リージョンを把握し有効期限を設定する

こんにちは、ひるたんぬです。

電子レンジ、生活の中に当たり前のように溶け込んでいる存在ですよね。
でも、「レンジ」とはどこからやってきた要素でしょうか？
発明元のアメリカ（英語）でも”microwave (oven)”であり、「レンジ」の要素は見当たりません。。
歴史を辿るとヒントがありました。

電子レンジの加熱原理は、アメリカのレイセオン社によって、レーダー装置の実験中にお菓子がレーダーのマイクロ波によって溶けていることに気が付き、これにヒントを得て、マグネトロンを使った調理器「レーダーレンジ」として製品化されました。

引用：一般社団法人日本電機工業会「電子レンジの歴史」

「電子レンジ」という言葉もここから生まれたのかも知れないですね¹。

¹ 「レンジ」の由来やその意味について、明確な文献を見つけることはできませんでした。日本ではその前から「ガスレンジ（ガスコンロ）」という名称が広がっており、電気的に加熱料理できる調理器具として「電子レンジ」とつけられたのではないか、という説もあるようです。

さて、今回はCloudFrontの機能の一つ、Lambda@Edgeにおけるログについて少し紐解いていきます。

やりたいこと
終わりに

やりたいこと

Amazon CloudFrontを使っており、その中でLambda@Edgeを使用しています。
ここで、Lambda@Edgeから出力されるログについて、予めログの有効期限を設定しておきたい場合を考えます。

既定では…

AWSの公式ドキュメントなどにも記載がありますが、Lambda@Edgeでは関数が実行された場所に最も近いAWSリージョンにロググループが自動で作成され、ログイベントが保管されます。

チュートリアル: 基本的な Lambda@Edge 関数 (コンソール) を作成する - Amazon CloudFront

Amazon CloudFront で実行される基本的な Lambda@Edge 関数をコンソールを使用して作成する方法について説明します。

エッジ関数のログ - Amazon CloudFront

Amazon CloudWatch Logs を使用して、Lambda@Edge 関数と CloudFront Functions の両方のエッジ関数のログを取得してください。

また、自動で作成されるロググループは有効期限が未設定（失効しない）のため、明示的に削除しないとログが残りつづけます。
コンプライアンスや規約上、ログはすべて保管する必要がある場合などはこの設定でも問題はありませんが、ログイベントの保存にも料金は発生します。

2026年1月現在では、東京リージョンにおいて1GBあたり$0.033の保存費用が発生します。

課題点

以上のことから、Lambda@Edgeでログを保管する場合、デフォルトの設定では無期限でログが残り続け、主に費用面での負担が増大しかねない点をご説明しました。

では、予めロググループを作成し、ロググループに対して有効期限を設定したいのですが…それにはLambda@Edgeがどこで実行されうるのか（どこのAWSリージョンにログが出力されうるのか）、を知る必要があります。

Lambda@Edgeが実行される場所

これを理解するためには、Amazon CloudFrontについても知る必要があります。
CloudFrontは「エッジロケーション（≠ リージョン）」と呼ばれる場所でキャッシュサーバーとして機能しています。
エッジロケーションにてキャッシュヒットしなかった場合は「リージョン別エッジキャッシュ（≠ リージョン）」にアクセスし、それでもヒットしなかった場合はオリジンからコンテンツを取得します。

引用：AWS Black Belt Online Seminar – Amazon CloudFront 基礎編(P. 15)

そして、Lambda@Edgeは、上記の「リージョン別エッジキャッシュ」にデプロイされています。

CloudFront Functionsについては「エッジロケーション」にデプロイされています。
そのため、CloudFront Functionsの方が実行時間が早い一方、キャッシュ容量が少ないためコード容量の制限が厳しいものだと分かります。
パソコンのCPUにおけるL1・L2キャッシュとイメージすると少し分かりやすいでしょうか…？

引用：AWS Black Belt Online Seminar – Amazon CloudFront (CloudFront Functions / Lambda@Edge 編) (P. 17)

では、その「リージョン別エッジキャッシュ」はどこにあるのでしょうか？
2026年1月現在では13個所に設定されています。

米国東部 (バージニア北部) – us-east-1
米国東部 (オハイオ) – us-east-2
米国西部 (北カリフォルニア) – us-west-1
米国西部 (オレゴン) – us-west-2
アジアパシフィック (ムンバイ) – ap-south-1
アジアパシフィック (ソウル) – ap-northeast-2
アジアパシフィック (シンガポール) – ap-southeast-1
アジアパシフィック (シドニー) – ap-southeast-2
アジアパシフィック (東京) – ap-northeast-1
欧州 (フランクフルト) – eu-central-1
欧州 (アイルランド) – eu-west-1
欧州 (ロンドン) – eu-west-2
南米 (サンパウロ) – sa-east-1

明示的な一覧は公式サイトからは見ることができなかったので、以下の資料から読み取りました。
（すべてAWSが提供する資料です）

また、CloudFrontのユーザーマニュアルからもLambda@Edgeのサービスにリンクされたロールの使用がサポートされているリージョンにて、同様のものを挙げています。

デベロッパーガイド – Amazon CloudFront
└ P. 935（「Lambda@Edge サービスリンクロールでサポートされている AWS リージョン」）にリージョン一覧の記載があります。

以上のことから、すべてのAWSリージョンでリージョン別エッジキャッシュが提供されているわけではないことが分かりました。（例えば、大阪リージョンでは提供されていないことが分かりやすいかと思います。）

結論

以上のことから、予めロググループを作成し、ロググループに対して有効期限を設定したい場合は、上述しました13個のリージョンに対して、所定の命名規則や設定に沿ったロググループを作成すれば良い、ということになります。

Lambda@Edgeにおけるロググループ名の規則については、以下をご参照ください。

エッジ関数のログ - Amazon CloudFront

Amazon CloudWatch Logs を使用して、Lambda@Edge 関数と CloudFront Functions の両方のエッジ関数のログを取得してください。

なお、今後リージョン別エッジキャッシュが拡大することも考えられますので、先んじて他リージョン（大阪リージョンなど）でロググループを作成しておく、というのも一手かと思われます。
ロググループの作成自体にはAWSの利用料金は発生しません。

一方、日本国内にアクセスを限定しており、海外からのアクセスは遮断している場合などについては、更に事前に作成するリージョンを絞ってよい（東京リージョンのみ、など…）かと思います。

終わりに

今回は、CloudFrontにLambda@Edgeを組み合わせて使用する場合において、どのリージョンにロググループが必要なのか（≒ Lambda@Edgeの実行に関連するAWSリージョンがどこなのか）調査しご紹介しました。
公式ドキュメントなどでも言及がほとんどされておらず情報収集に苦戦しましたが、参考になる方がいらっしゃいましたら幸いです。

余談ですが、「レンジでチン」という言葉は死語になってしまう日もくるのでしょうか。
テレビにおける「チャンネル回す」も死語になりつつあるようです…
最近の電子レンジは、「ピー」という音がなったり、おしゃれな音楽が流れるようです。「レンジでピー」…？