AWS Well-Architected Framework 入門：パフォーマンス効率の柱を S3 + CloudFront でハンズオンしてみた
はじめに
こんにちは。クラスメソッドオペレーションズの藤瀨です。
Well-Architected Framework ハンズオンシリーズの第 5 回です。
今回は「パフォーマンス効率（Performance Efficiency）」の柱に沿って筆者が作成したハンズオンを実践していきます。
この柱が目指すのは、コンピューティングリソースを効率的に活用し、システムの要件を満たしながら、ビジネスの成長や技術トレンドの変化にも柔軟に対応し続けることです。単に「速く動かす」だけでなく、適切なリソースを適切な量だけ、適切なタイミングで使うという考え方が根底にあります。
このブログでは以下の 3 点を体験します。
- S3 に配置した静的コンテンツを CloudFront でキャッシュ配信する
- レスポンスヘッダーと応答時間でキャッシュのヒット・ミスを確認する
- キャッシュ無効化（Invalidation）を試す
パフォーマンス効率とは
改めてこの柱の中身を整理しておきます。公式ドキュメントでは、パフォーマンス効率は「パフォーマンス要件を満たすためにクラウドリソースを効率的に使用し、需要や技術の変化に応じてその効率を維持する能力」と定義されています。
この柱には 5 つの設計原則があります。
- 高度な技術を誰でも使えるようにする: NoSQL や機械学習など専門知識が必要な技術も、マネージドサービスとして消費できる
- 数分でグローバル展開する: 複数リージョンへのデプロイで、低コストのまま低レイテンシーを実現する
- サーバーレスアーキテクチャを使う: サーバーの運用・保守を意識せず、必要な分だけ使う
- 実験を頻繁に行う: 仮想化・自動化されたリソースで、複数の構成を気軽に比較検証する
- メカニカルシンパシーを持つ: データのアクセスパターンに合った技術（データベースやストレージの種類）を選ぶ
今回のハンズオンでは、この中でも「メカニカルシンパシーを持つ」（静的コンテンツには S3+CloudFront のキャッシュ配信が適している、という技術選定の感覚）を中心に、キャッシュによる効率化を体感していきます。
具体的な手順
大まかな手順は以下の通りです。
- S3 バケットに静的コンテンツを配置する
- CloudFront ディストリビューションを作成する
- キャッシュ効果を計測する
- キャッシュ無効化（Invalidation）を試す
前提条件
このハンズオンを行う前に、以下を確認しておくことをおすすめします。
- 検証用に用意した AWS アカウントで実施し、本番環境では行わないこと
- 本記事の内容および画面表示は、公開直前に実際に確認した時点の AWS マネジメントコンソールの情報に基づいていること（コンソールの UI や項目名は更新される場合があります）
- S3、CloudFront の利用について、条件によっては料金が発生する可能性があること（詳細は後述の「使用したサービスと料金の考え方」を参照）
① S3 バケットに静的コンテンツを配置する
- AWS マネジメントコンソール上部の検索ボックスで S3 を検索してクリックします。
- 左側のナビゲーションペインで「バケット」を選び、［バケットを作成］をクリックします。
- 「バケット名」に、全世界で一意な名前（例:
waf-perf-handson-bucket-任意の文字列）を入力します。「AWS リージョン」はお好みのリージョン（本記事ではアジアパシフィック（東京）ap-northeast-1）を選びます。 - 「オブジェクト所有者」は「ACL 無効（推奨）」のデフォルトのまま進めます。
- 「このバケットのブロックパブリックアクセス（バケット設定）」は「パブリックアクセスをすべてブロック」にチェックが入ったデフォルトのまま進めます。この後の手順で CloudFront から OAC（Origin Access Control）経由でのみアクセスできるようにするため、バケット自体を公開する設定は行いません。
- 「バケットのバージョニング」「デフォルトの暗号化」など、それ以外の項目もすべてデフォルトのまま、画面下部の［バケットを作成］をクリックします。
- お使いのエディタの新規ファイルに、以下の内容を張り付け、ファイル名を
index.htmlとして保存しておきます。「Hello from S3 + CloudFront」だけを表示するシンプルなウェブページの HTML ファイルです。
<!DOCTYPE html>
<html>
<head><title>Performance Efficiency Handson</title></head>
<body><h1>Hello from S3 + CloudFront</h1></body>
</html>
- 作成したバケットを開き、「オブジェクト」タブの［アップロード］→［ファイルを追加］から、
index.htmlを選択します。「アクセス許可の設定」もデフォルトのまま、画面下部の［アップロード］をクリックします。
② CloudFront ディストリビューションを作成する
- 検索ボックスで CloudFront を検索してクリックし、左側のナビゲーションペインで「Distributions」を選び、［Create distribution］をクリックします。
- 「Choose a plan」画面で Free プラン（$0/月、月間利用枠は 100 万リクエスト・100 GB のデータ転送）を選択し、画面下部の［Next］をクリックします。Free プランには、常時オンの DDoS 保護（AWS Shield Standard）、AWS WAF による保護、Route 53 との DNS 連携、無料の TLS 証明書、キャッシュ機能などが追加料金なしで含まれています。今回のハンズオンで発生するアクセス量であれば、この月間利用枠に達する可能性は極めて低いです。
- 「Get started」画面の「Distribution name」に、分かりやすい名前（例:
waf-perf-handson）を入力します（動作には影響しない、リソースのタグ用の名前です）。「Description」は空欄のままにします。「Distribution type」は「Single website or app」が選択されたデフォルトのまま進めます。下部の「Domain」欄（Route 53 に登録済みの独自ドメインと連携させる設定）は使用しないため、空欄のまま［Next］をクリックします。
-
「Specify origin」画面の「Origin type」で「Amazon S3」が選択されていることを確認します。「Origin」の「S3 origin」欄は、右側の［Browse S3］をクリックし、①で作成したバケットを一覧から選択します。「Origin path」は空欄のままにします。
-
画面を下にスクロールし、「Settings」内の「Allow private S3 bucket access to CloudFront」のチェックはオンのままにします。これが OAC（Origin Access Control）に相当する設定で、オンにしておくだけで、このディストリビューションからのアクセスのみを許可するように CloudFront が S3 バケットポリシーを自動的に更新してくれます。
-
「Settings」内の「Origin settings」は「Use recommended origin settings」、「Cache settings」は「Use recommended cache settings tailored to serving S3 content」が、それぞれ選択されたデフォルトのまま［Next］をクリックします。
- 「Enable security」画面では、「Web Application Firewall (WAF)」による保護が、無料プランでも追加料金なしで含まれています。「Use monitor mode」のチェックはオフのままにします（オンにすると、実際にはブロックせずブロック対象になるリクエスト数だけを記録するお試しモードになります）。「Protection against Layer 7 DDoS attacks」はビジネスプラン以上でのみ利用できる機能のため、無料プランでは選択できません。そのまま［Next］をクリックします。
- 「Review and create」画面で、これまでの設定内容（Billing: Free ($0/month)、S3 origin、Grant CloudFront access to origin: Yes など）を確認し、画面右下の［Create distribution］をクリックします。
- ディストリビューションの詳細画面で、ステータスが「Deploying」から「Enabled」に変わるまで数分待ちます。「Domain name」（
xxxxx.cloudfront.netの形式）をメモ帳などに控えておきます。 - ディストリビューションの詳細画面で「General」タブを開き、［Edit］をクリックします。「Default root object」の欄に
index.htmlを入力し、変更を保存します。 - Default root object の設定変更後、ディストリビューションが再びデプロイ状態になります。変更の反映が完了するまで待ってから、次のキャッシュ確認に進みます。
③ キャッシュ効果を計測する
- CloudFront のディストリビューション詳細画面で「Domain name」（
xxxxx.cloudfront.netの形式）を確認します。ブラウザでこの URL を開く前に、開発者ツール（Chrome の場合は F12 キー、または画面上で右クリックして「検証」）を開き、「Network」（ネットワーク）タブを選択します。 - 「Network」タブ上部にある「キャッシュを無効化」にチェックを入れます。これにより、ブラウザ自身のキャッシュを無効化し、CloudFront 側のキャッシュ動作だけを観察できるようにします。あわせて、隣にある「Preserve log（ログを保持）」にもチェックを入れておきます。これをオンにしないと、次のアクセスでページを再読み込みするたびに一覧がクリアされてしまい、1 回目と 2 回目のリクエストを見比べられなくなります。
- 開発者ツールを開いたまま、CloudFront の URL（
https://xxxxx.cloudfront.net/）に初めてアクセスします。「Network」タブの「名前」列に複数のリクエストが表示されるので、その中からステータス「200」・タイプ「document」の行を選んでクリックします。
クリックすると画面右側に詳細ペインが開くので、「ヘッダー」（Headers）タブを選び、下にスクロールして「応答ヘッダー」（Response Headers）の中にある X-Cache の値を確認します。
作成直後で、まだ同じオブジェクトがCloudFrontにキャッシュされていない場合は、通常 Miss from cloudfront になります。
- 同じ URL に再度アクセスし、同様に「200」・「document」の行を選んで、
X-Cacheの値を確認します。同じキャッシュキーで処理され、CloudFront のキャッシュに有効なオブジェクトが残っていれば、通常はHit from cloudfrontに変わります（連続してMissになる場合は、レスポンスヘッダーのx-amz-cf-popも確認してください。異なる POP で処理されている場合、それぞれのキャッシュ状態が異なることがあります）。
あわせて、応答時間を比較し、キャッシュヒット時に短くなる傾向があるかを観察します。下の画像の黄色の枠で囲んだ方が 1 回目のアクセス（キャッシュなし）にかかった時間、赤色の枠で囲んだのがキャッシュありの時のアクセス時間で、キャッシュありの方が時間が短縮されていることがわかります。
ただし応答時間はネットワーク状態などにも左右されるため、キャッシュのヒット・ミスの判断は X-Cache の値を主な材料にします。複数回アクセスし、同じ POP で処理され、キャッシュが有効な間は Hit になることも確認します。
④ キャッシュ無効化（Invalidation）を試す
-
HTML ファイルを更新する直前に CloudFront 経由でアクセスし、
X-Cache: Hit from cloudfrontになっていることを確認します。 -
手元の
index.htmlの表示内容（例:<h1>タグの文言）を書き換えて保存し、S3 コンソールで対象バケットの「オブジェクト」タブを開きます。既存のindex.htmlにチェックを入れて［アップロード］→［ファイルを追加］から書き換え後のファイルを選び、同じキー名（index.html）のまま上書きアップロードします。アップロード後、すぐに同じ URL へ再度アクセスします。通常はX-Cache: Hit from cloudfrontのまま古い内容が表示され、CloudFront に保存されているキャッシュから応答していることを確認できます（CloudFront ではアクセス頻度の低いオブジェクトが TTL 内でもキャッシュから追い出される場合があり、その場合は更新後のアクセスがすぐにMissになることもあります）。
-
CloudFront コンソールの「無効化（Invalidations）」タブから、パス
/index.htmlを指定して無効化を実行します。今回更新したのは HTML ファイル 1 つだけなので、そのファイルだけを無効化の対象にします。/*を指定すると、ディストリビューション配下のすべてのオブジェクトが無効化の対象になります。更新対象を個別に絞れないときや、まとめて反映したいときに使う指定方法です。
-
無効化のステータスが「Completed」になったことを確認してから、開発者ツールを開いたまま再度アクセスします。無効化完了後、まだほかのリクエストによってオブジェクトが再取得されていなければ、通常は
X-Cache: Miss from cloudfrontとともに更新後の内容が表示されます。
-
続けてもう一度アクセスします。同じキャッシュキーで処理され、再取得されたオブジェクトがキャッシュに残っていれば、通常は
X-Cache: Hit from cloudfrontに変わります。
この一連の流れから、「無効化によって古いキャッシュが破棄され、次のアクセスでオリジンから再取得された内容が、その後は再びキャッシュとして配信される」という Invalidation の一連の動作を体感できます。
使用したサービスと料金の考え方
今回使用したサービスの料金体系と、無料で利用できる範囲の考え方は以下の通りです。
| サービス | 料金体系・無料利用の考え方 | 備考 |
|---|---|---|
| S3 | アカウント作成日やプランにより無料枠の扱いが異なる | 少量の静的ファイルなら収まりやすいですが、コンソール上で無料枠の残量を確認することをおすすめします |
| CloudFront | CloudFront では、月額固定プランと従量課金を選択できます。本記事では月額固定の Free プラン（$0/月、月間 100 万リクエスト・100 GB データ転送まで、AWS WAF・DNS・TLS 証明書などを含む）を使用 | 検証用途のアクセス量であれば、利用枠に達する可能性は極めて低いです |
| CloudFront（キャッシュ無効化） | 固定料金プランと従量課金で料金体系が異なる | 従量課金では、AWSアカウント全体で月1,000無効化パスまで無料 |
クリーンアップ
検証が終わったら、以下の順番でリソースを片付けてください。
- CloudFront ディストリビューションに設定した月額固定の Free プランをキャンセルする
- CloudFront ディストリビューションを無効化する
- 設定の反映完了後、CloudFront ディストリビューションを削除する
- 使用されなくなった Origin Access Control（OAC）を削除する
- S3 バケット内のオブジェクトを削除する
- 空になった S3 バケットを削除する
おわりに
このブログでは、キャッシュのヒット・ミスを実際のレスポンスヘッダーと応答時間で確認しました。
これは、パフォーマンス効率の柱の設計原則である「メカニカルシンパシーを持つ」と関連する内容です。「エッジロケーションでのキャッシュによるレイテンシー削減」という説明だけでは掴みにくかったイメージが、実測値を見比べることではっきり体感できました。
引き続き、次回は「コスト最適化」の柱について、Cost Explorer と Budgets を使ってハンズオンする予定です。
最後までお読みいただきありがとうございました！
参考リンク
- Performance Efficiency Pillar
- Performance efficiency: Design principles
- Performance efficiency
- Restrict access to an Amazon S3 origin
- Configure OAC for CloudFront distributions with Amazon S3 origins
- Restrict access to an Amazon S3 bucket with a CloudFront distribution
- CloudFront flat-rate pricing plans
- Specify a default root object
- Use managed cache policies（CachingOptimized など）
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、 IT・AI をフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。
※2026 年 1 月 アノテーション㈱から社名変更しました。
