【図解】AWS CloudFrontとは。近所のコンビニ方式と「更新したのに古いまま」の直し方

対象読者: AWSをこれから触る人。 AWS勉強シリーズの11本目です。全体の地図は索引記事にあります。

この記事を読むと、次の2つの症状が自分で切り分けられるようになります。

• サイトは動いているのに、遠くの利用者からだけ「遅い」と言われる
• ファイルを更新したのに、ブラウザにはいつまでも古いのが表示される

CloudFrontとは何か

Amazon CloudFrontは、あなたのサイトのコピーを世界中の「近所」に置いて、一番近い場所から配るサービスです。CDN(コンテンツ配信ネットワーク)と呼ばれる種類のもので、上の絵のとおり本店(S3やEC2)は1軒のまま、各地のコンビニ(エッジロケーション)に商品を置いておくイメージです。利用者は本店まで行かず、近所の店から受け取ります。近いから速い。それだけの話です。

「それだけ」と書きましたが、距離の効果は想像より大きいです。東京の本店からブラジルの利用者にファイルを届けると、距離だけで数百ミリ秒かかります。近所のエッジから配れば数十ミリ秒。10倍の差になります。

何に使うか

• 静的サイトの世界配信: S3に置いたHTML・画像・動画を高速に配る。S3+CloudFrontは静的サイトの定番ペア
• 転送料の節約: S3の回で書いたとおり、S3から直接インターネットに配ると転送料が重い。CloudFront経由は無料枠が桁違いに大きく、S3からCloudFrontへの取り寄せは無料
• HTTPSの窓口: S3の静的サイト機能は素のままだとHTTPSにできない。CloudFrontを前に置くとHTTPSになる

今AWSの地図のどこにいるか

前回のRoute 53で「名前」を持てたので、今回は「速さ」です。実は役割が混ざりやすい2つで、Route 53は住所を教える電話帳、CloudFrontは商品を置く店。電話帳は店の場所を教えるだけで、商品は持っていません。

今はこれだけ分かればOK

必須の3語だけ覚えます。

エッジロケーション、ビヘイビア、OAC(オリジンアクセスコントロール)といった用語は後回しで大丈夫です。

使い方

やることは4つ。上の図がそのままコードの順番になります。

import boto3

cf = boto3.client("cloudfront", region_name="us-east-1")

# ① 配信を作る。渡すのは「本店の住所」と配り方の最低限
config = {
    "CallerReference": "ref-001",          # 二重作成防止の合言葉(自分で決める)
    "Comment": "my-first-cdn",
    "Enabled": True,
    "Origins": {"Quantity": 1, "Items": [{
        "Id": "origin1",
        "DomainName": "my-site.example.com",   # 本店(オリジン)の住所
        "CustomOriginConfig": {"HTTPPort": 80, "HTTPSPort": 443,
                               "OriginProtocolPolicy": "https-only"}}]},
    "DefaultCacheBehavior": {
        "TargetOriginId": "origin1",
        "ViewerProtocolPolicy": "redirect-to-https",
        "CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6",  # AWS管理の既定キャッシュ設定
    },
}
d = cf.create_distribution(DistributionConfig=config)["Distribution"]
print("domain:", d["DomainName"])
print("status:", d["Status"])

motoで実行した出力です(motoの使い方はシリーズSQS回参照)。

domain: mwhcgmejunu46.cloudfront.net / status: InProgress

この xxxx.cloudfront.net が新しい配布用の住所です。②はこの InProgress が Deployed になるのを待つ工程で、本物のAWSでは数分〜数十分かかります。世界中の店に在庫を並べて回っているところなので、ここは待つしかありません。③は待ち終わったらブラウザでcloudfront.netの住所を開くだけ。④の消し方には罠があるので、後の実測の節で書きます。

設定の中で見慣れないのは CallerReference だと思います。これは「同じ依頼を二重に受け付けないための合言葉」で、自分で適当な文字列を決めます。同じ合言葉で2回作ろうとするとエラーになります(これも後で実際に叩きます)。

今あなたが作ったもの

①でできたのは「本店の住所を知っていて、世界中に在庫置き場を持つ配達網」です。まだ在庫はありません。最初の利用者がアクセスした瞬間に、エッジが本店から取り寄せて在庫にします。だから同じ地域の1人目だけは遅くて、2人目から速い。別の地域の人には、その土地の「1人目」がまた発生します。この挙動を知らないと「CloudFront入れたのに速くならない」と一瞬焦ります。測るなら同じ場所から2回アクセスしてください。

1か所だけ変えてみる

"Enabled": True を False にして作ってみてください。配信は作れますが、住所にアクセスしても配られません。「作ること」と「配ること」は別のスイッチ。その構造が1行で見えます。この2段構えが、後述する削除手順の伏線になります。

実際に叩くと止まるところ

作り方を間違えたときに何が返るか、4パターンmotoで実際に叩きました(エラーの種類名は本物のAWSと同じです)。

get_distribution(Id="E2QWRUHAPOMQZL")     # 無いID
 → NoSuchDistribution - The specified distribution does not exist.
delete_distribution(Id=...)                # ETag無しで削除
 → InvalidIfMatchVersion - The If-Match version is missing or not valid
create_distribution(オリジン0個)
 → ParamValidationError - Invalid length for parameter Origins.Items
create_distribution(同じCallerReferenceでもう一度)
 → DistributionAlreadyExists - The caller reference that you are using...

2つ目が今回の主役級の罠です。CloudFrontの削除は delete_distribution(Id=...) だけでは通りません。ETagという「今の設定のバージョン札」を IfMatch で渡すのが必須で、しかもその前に配信を無効化(Enabled: False に更新)しておかないといけない。つまり正規の消し方は「①ETagを取って無効化に更新→②StatusがDeployedに戻るまで待つ(数分〜十数分)→③ETagを取り直す→④IfMatch付きで削除」。無効化はリクエストが受理されただけでは足りず、世界中の店じまいが終わるまで削除は弾かれます。ETagも無効化で変わるので、古い札で④を叩いてもだめです。自分も最初のスクリプトは削除まわりの想定が甘く、順番を崩して一度こけました。上の4手はその書き直し後の形です。

白状しておくと、この「有効なまま削除するとDistributionNotDisabledで怒られる」挙動は、motoでは再現できませんでした。motoは有効なままでも削除を通してしまいます。エラーの型を手元で全部確認したかったのですが、ここだけは本物のAWSのドキュメントと挙動が頼りです。

似たサービスとの使い分け

料金の考え方

課金は主に2つです。

• 転送料: エッジから利用者への送信。日本向けで1GBあたり0.114 USD前後。毎月1TBまでの無料枠あり(2025年7月以降に作った新規アカウントは無料枠の仕組みがクレジット制に変わっているので、公式の料金ページで自分のプランを確認してください)
• リクエスト料: 100万リクエストで1 USD前後

見どころは無料枠の大きさです。S3から直接配ると無料枠は100GB、CloudFront経由なら1TB。個人のサイトや学習用途なら、CloudFrontを挟んだ方が速くなった上でタダになります。この逆転は普通に起きます。「CDNは大規模サービス用の高い道具」。この先入観は、少なくとも料金については当てはまりません。

よくある注意点

• 更新が反映されないのは故障ではなく仕様。 近所の店は在庫(キャッシュ)が切れるまで古い商品を配り続けます。急いで反映したいときは、インバリデーション(在庫を捨てさせる指示)を出します。create_invalidation で /* を指定するのが定番。ただし月1,000パス超は有料
• 消すのは2段階+待ち。 上で書いたとおり、無効化→Deployed待ち→ETag取り直し→削除。有効なまま消そうとしても DistributionNotDisabled で弾かれます
• 配信の反映は遅い。 作成も設定変更も数分〜数十分待ちます。EC2やS3の感覚で「即反映」を期待すると不安になりますが、世界中の店に配って回っているためです
• S3をオリジンにするなら入り口を絞る。 CloudFront経由で配るのに、S3バケット自体も公開のままだと裏口が開いています。OACという仕組みで「CloudFrontからしか読めない」ようにするのが定石ですが、これは入門の次の一歩です

まとめ

冒頭の2つの症状に答えます。遠くの利用者からだけ遅いのは、本店1軒から世界に配っているから。CloudFrontで近所に在庫を置けば解決します。更新したのに古いままなのは、その在庫が残っているから。急ぐならインバリデーションで捨てさせます。速さの源と事故の源は、同じ「キャッシュ」。これが今回の一番の持ち帰りです。

次に手を動かすなら、motoで①を作って DomainName が生えるところまで、それから削除の4手(ETag取り直し込み)をやってみてください。ETagを取り直さずに削除して弾かれたら、それが今回の学びが身についた瞬間です。

次回はELB(ロードバランサー)を予定しています。「1軒の本店を、複数の厨房で回す」話です。

参考

• Amazon CloudFront 公式ドキュメント
• Amazon CloudFront の料金
• シリーズ索引: AWSとは何か
• 前回: Route 53とは