Skip to Content
AWS（Amazon Web Services）初級a-01 ECサイトを構築する（VPC・EC2・Aurora・ALB・S3）ステップ5：静的ファイルのCloudFront,S3によるホスティング

ステップ５：静的ファイル、ページのCloudFront,S3によるホスティング

今回のステップの概要とECサイトとの関連について

このステップでは、ECサイトのパフォーマンスを向上させるために、静的コンテンツ（ランディングページ）と動的コンテンツ（商品情報・注文情報）を分離します。

まず、静的コンテンツと動的コンテンツの違いについて説明します：

静的コンテンツとは、ユーザーがアクセスするたびに内容が変わらないコンテンツのことです。例えば、ランディングページのHTML、CSS、JavaScriptファイル、商品画像などが該当します。これらのコンテンツは事前に作成され、変更頻度が低いため、世界中に配置されたCDN（Content Delivery Network）で高速配信することができます。

動的コンテンツとは、ユーザーや状況によって内容が変わるコンテンツのことです。例えば、ユーザーごとに異なる商品レコメンデーション、在庫状況、注文履歴などが該当します。これらのコンテンツはデータベースからリアルタイムで取得する必要があるため、サーバーサイドで処理する必要があります。

ECサイトにとって、この構成は「お店の看板（静的コンテンツ）と、在庫状況や注文処理（動的コンテンツ）を別々に管理する」ようなものです。ランディングページなどの変わらない情報（静的コンテンツ）は世界中に配置された専用のサーバーで高速に配信し、商品情報や在庫状況などの変わりやすい情報（動的コンテンツ）はデータベースと連携したサーバーで管理します。

このステップで学ぶこと

  • S3バケットの作成と設定方法
  • CloudFrontディストリビューションの作成と設定方法
  • 画像ファイルのS3へのアップロード方法
  • NextjsアプリケーションとCloudFrontの連携方法

リソースの関わりと構成説明

ステップ5で作成するリソースは、ECサイトの応答性を高めるものです。それぞれのリソースがECサイトにどのように関わるのかを説明します。

S3バケットとECサイトの関わり

S3バケット「ec-site-lp-xxx」は、ECサイトの「商品写真の保管庫」のような役割を果たします。商品画像などの静的コンテンツを一元管理することで、EC2インスタンスの負荷を軽減し、ストレージコストを最適化します。また、S3は高い耐久性と可用性を持つため、データの損失リスクも低減します。

CloudFrontとECサイトの関わり

CloudFrontディストリビューションは、ECサイトの「世界中に配置された配送センター」のような役割を果たします。ユーザーに最も近いエッジロケーションから画像を配信することで、表示速度を大幅に向上させます。また、キャッシュ機能により、同じ画像を何度もオリジンサーバー（S3）から取得する必要がなくなり、コスト削減にも貢献します。

静的コンテンツと動的コンテンツの分離

動的コンテンツ（商品情報、在庫状況など）はEC2インスタンスとAurora PostgreSQLで管理し、静的コンテンツ（商品画像やランディングページなど）はS3とCloudFrontで管理することで、それぞれに最適な方法でコンテンツを提供できます。これは、「お店の商品カタログ（頻繁に更新される情報）」と「商品写真集（めったに変わらない情報）」を別々に管理するようなものです。

実際の手順

実際の手順では、たくさんの設定値を入力することになります。 本文中に設定値が指定されていない場合は、デフォルト値のまま作業を進めてください。

1. S3バケットの作成

S3は、AWSのオブジェクトストレージサービスで、画像などの静的ファイルを保存するのに最適です。

Tip

【解説】S3を使うタイミングと静的・動的コンテンツの分離効果

実際のビジネスでは、S3は主に静的コンテンツ（商品画像、CSS、JavaScriptファイル、商品カタログPDF等）の配信に使用されます。静的コンテンツは内容が変わることが少なく、すべてのユーザーに同じ内容を提供するため、S3のような高耐久性のストレージに保存してCDN経由で配信することで、世界中のユーザーに高速にコンテンツを提供できます。一方、動的コンテンツ（在庫状況、ユーザーの注文履歴、個人向けレコメンデーション等）は、ユーザーごとやリアルタイムで内容が変わるため、データベースとアプリケーションサーバーで処理する必要があります。S3を使わない場合、すべてのファイルをアプリケーションサーバーから配信することになり、サーバーの負荷が増加し、特に画像などの大きなファイルを多数配信する際にレスポンス時間が遅くなります。また、サーバーの障害時にはすべてのコンテンツが利用できなくなるリスクもあります。S3を使用することで、アプリケーションサーバーは動的コンテンツの処理に集中でき、システム全体のパフォーマンスと可用性が向上します。

1-1. S3ダッシュボードにアクセス

  1. AWSマネジメントコンソールにログインします。
  2. 画面上部の検索バーに「S3」と入力し、表示される「S3」をクリックします。
  3. S3ダッシュボードが表示されます。

1-2. バケットの作成

  1. 「バケットを作成」ボタンをクリックします。
  2. 「バケット名」に「ec-site-lp-xxx」（xxxは任意の文字列）と入力します。
  3. 設定を以下のように選択します：
  • AWSリージョン：EC2やRDSと同じリージョン（例：us-east-1　バージニア北部）を選択します。

（注：S3バケット名はグローバルに一意である必要があります。例：ec-site-images-abc123）

  1. 「オブジェクトの所有権」：「ACL無効」を選択します。
  • バケットのバージョニング：
    • 「無効にする」を選択します。
  • デフォルトの暗号化：
  • 「Amazon S3マネージドキー（SSE-S3）」を選択します。
  1. 「バケットを作成」ボタンをクリックします。
Tip

【解説】オブジェクトストレージとファイルストレージの違いと選択理由

オブジェクトストレージは、データを「オブジェクト」として格納し、各オブジェクトには一意のキー（ファイル名）とメタデータが付与されるストレージ形式です。一方、ファイルストレージは従来のファイルシステムのようにディレクトリ階層でファイルを管理します。オブジェクトストレージの主な利用用途は、静的ファイルの配信、バックアップ、アーカイブ、大容量データの保存で、特にWeb配信に適しています。メリットとして、無制限のスケーラビリティ、高い耐久性（99.999999999%）、HTTPアクセスによる簡単な統合、低コスト、世界中からのアクセス性があります。デメリットとして、リアルタイム編集ができない、ファイルの一部更新ができない、従来のファイルシステムとは異なるアクセス方法となります。ファイルストレージの利用用途は、アプリケーションの動作ファイル、データベースファイル、共有ファイルサーバーで、メリットとして従来のファイルシステムとの互換性、リアルタイム編集、部分更新が可能です。デメリットとして、スケーラビリティの制限、高コスト、管理の複雑さがあります。今回ECサイトの画像配信にオブジェクトストレージが適切な理由は、商品画像は一度アップロードすれば変更頻度が低く、世界中のユーザーに同じ画像を高速配信する必要があり、CDNとの連携が容易で、大量の画像ファイルを低コストで保存できるためです。

Tip

【解説】S3バケット名のグローバル一意性の理由と命名ベストプラクティス

S3バケット名がグローバルで一意である必要がある理由は、AWSのS3サービスが世界全体で単一の名前空間を持っているためです。すべてのS3バケットは「https://バケット名.s3.region.amazonaws.com」という形式でアクセスされるため、世界中のすべてのAWSアカウントで同じバケット名を使用することはできません。これは、インターネット上のドメイン名と同じ仕組みで、重複を避けることでアクセスの競合を防いでいます。また、S3はDNS（Domain  Name System）の仕組みを利用してバケットにアクセスするため、DNS上でも一意である必要があります。バケット名にAWSアカウントIDとリージョン名を含めることを推奨する理由は、偶発的な名前の衝突を避けるためです。例えば「ec-site-images-123456789012-us-east-1」のような命名にすることで、他のユーザーが同じ名前を使用する可能性を大幅に減らすことができます。さらに、バケット名から所有者とリージョンが識別できるため、管理上も有効です。このような命名規則により、グローバルな環境での一意性を保ちながら、管理しやすいバケット名を作成できます。

Tip

【解説】SSE-S3の選択理由と暗号化オプションの比較

SSE-S3（Server-Side Encryption with Amazon S3 Managed Keys）を選択する理由は、最もシンプルで管理負荷が少ない暗号化方式だからです。S3は2023年1月5日以降、すべての新しいオブジェクトに対してSSE-S3を自動的に適用するため、これが標準的な選択肢となっています。SSE-S3では、AWSが暗号化キーを自動的に管理し、ユーザーは暗号化に関する設定や管理を行う必要がありません。他の選択肢として、SSE-KMS（AWS Key Management Service）があり、これは独自の暗号化キーを管理したい場合や、キーの使用履歴を詳細に監査したい場合に使用します。SSE-KMSの利用用途は、コンプライアンス要件が厳しい金融機関や医療機関でのデータ保護、キーのローテーション管理が必要な場合、特定のユーザーのみにデータアクセスを制限したい場合などです。SSE-C（Customer-Provided Keys）は、顧客が独自に暗号化キーを提供し管理する方式で、最も高いセキュリティレベルを求める場合に使用しますが、キー管理の負担が大きくなります。今回のECサイトの商品画像配信では、一般的なWebサイトの静的コンテンツであり、特別な暗号化要件がないため、管理が簡単で追加コストが発生しないSSE-S3が最適です。

Tip

【解説】S3パブリックアクセスブロックとCloudFront活用の重要性

S3バケットのパブリックアクセスを直接許可しないほうが良い理由は、セキュリティとコスト効率の観点から重要です。まず料金面では、S3から直接配信する場合、データ転送料金が高額になります。特に画像などの大容量ファイルを世界中のユーザーに配信すると、リージョン間やインターネットへのデータ転送料金が大幅に増加します。CloudFrontを併設することで、エッジロケーションでのキャッシュ効果により、S3からの実際のデータ転送量を大幅に削減できます。セキュリティ面では、S3バケットを直接パブリックアクセスにすると、誰でもバケット内のすべてのファイルにアクセス可能になり、意図しないファイルの流出リスクが生じます。CloudFrontのOrigin Access Control（OAC）を使用することで、CloudFront経由でのみS3にアクセスを許可し、直接アクセスを防ぐことができます。ただし、パブリックアクセスを許可する必要があるパターンとして、静的ウェブサイトホスティング、一時的なファイル共有、オープンデータの公開、開発・テスト環境での簡単なファイル共有などがあります。これらの場合でも、必要最小限の権限のみを付与し、定期的にアクセスログを確認することが重要です。本格的なWebサイトやアプリケーションでは、CloudFrontを組み合わせることで、パフォーマンス向上とコスト削減を両立できます。

2. LPページ用ファイルのS3へのアップロード

Tip

【解説】EC2からのデプロイとGitHub Actionsを使った自動デプロイの比較

本来は、EC2インスタンスから手動でS3にファイルをアップロードするのではなく、GitHub ActionsやAWS CodePipelineなどのCI/CDツールを使用して自動化されたデプロイを行うべきです。CI/CDツールを使用することで、ソースコードの変更が自動的にテストされ、問題がなければ自動的にS3にデプロイされます。GitHub Actionsを使用した場合、開発者がコードをGitHubにプッシュすると、自動的にビルドプロセスが実行され、静的ファイルが生成されてS3にアップロードされます。これにより、デプロイプロセスが標準化され、人的エラーを防ぐことができます。GitHub Actionsなどを利用しない場合のデメリットとして、まず人的エラーのリスクが高くなります。手動でファイルをアップロードする際に、古いファイルを削除し忘れたり、間違ったファイルをアップロードしてしまう可能性があります。また、複数の開発者がいる場合、誰がいつ何をデプロイしたかの履歴が不明確になり、問題が発生した際の原因特定が困難になります。さらに、デプロイ作業が属人化しやすく、特定の人がいないとデプロイできない状況が生じる可能性があります。本チュートリアルでは学習目的で手動デプロイを行いますが、実際の本番環境では必ずCI/CDパイプラインを構築することを強く推奨します。

2-1. EC2インスタンスのIAMロールにS3へのアクセス許可を追加

  1. IAMコンソール画面を開き、EC2にアタッチしている「ec-site-web-SSMRole」ロールを選択します。
  2. 「ポリシーをアタッチ」ボタンをクリックし、「AmazonS3FullAccess」ポリシーをアタッチします。

2-2. EC2インスタンスへの接続

  1. EC2インスタンスにSystems Managerセッションマネージャーで接続します。
  • EC2ダッシュボードで、ステップ3で作成したインスタンスを選択・起動します。（２〜４分ぐらいかかります）
  • 「接続」ボタンをクリックします。
  • 「Session Manager」タブを選択し、「接続」ボタンをクリックします。
  1. rootユーザーになり、ホームディレクトリに移動します：
sudo su
cd ~
  1. サンプル画像をダウンロードします：
aws s3 cp s3://tenarai-blueprint-sample-code-983911888049-us-east-1/ec-site-tenarai-sample/ecommerce-lp-v0.zip ~/ecommerce-lp-v0.zip
unzip ecommerce-lp-v0.zip

2-3. S3バケットへのアップロード

  1. 以下のコマンドを実行して、ファイルをS3バケットにアップロードします（{ec-site-lp-xxx}は実際のバケット名に置き換えてください）：
aws s3 cp ecommerce-lp-v0 s3://{ec-site-lp-xxx}/ --recursive
  1. アップロードが完了したら、S3コンソールでバケットを開き、ファイルが正常にアップロードされていることを確認します。
Important

EC2インスタンスの停止を忘れないようにしてください

3. CloudFrontディストリビューションの作成

CloudFrontは、AWSのCDN（コンテンツ配信ネットワーク）サービスで、世界中のエッジロケーションを使って静的コンテンツを高速に配信します。

3-1. CloudFrontダッシュボードにアクセス

  1. 画面上部の検索バーに「CloudFront」と入力し、表示される「CloudFront」をクリックします。
  2. CloudFrontダッシュボードが表示されます。

3-2. ディストリビューションの作成

  1. 「ディストリビューションを作成」ボタンをクリックします。

  2. 「Choose a plan」では「Pay as you go」を選択します

  3. 「Get started」では以下のように選択します：

  • Distribution name：「ec-site-lp-cf」
  • Type：Single website or appを選択
  1. 「Specify origin」では以下のように選択します：
  • Origin type: Amazon S3
  • S3 origin: ec-site-lp-xxxx
  • Origin path: 「/ecommerce-lp-v0」を入力
  • Allow private S3 bucket access to CloudFrontにチェック
  • オリジン設定：Use recommended origin settingsを選択
  1. 「Enable security」では以下のように選択します：
  • Web Application Firewall (WAF)：「セキュリティ保護を有効にしないでください」を選択
  1. 「Create distribution」を押します。

注釈: ディストリビューションの作成には10-15分程度かかります。ステータスが「Deploying」から「Enabled」に変わるまで待ちます。

Tip

【解説】Multi-tenant architectureとSingle websiteの違いと利用タイミング

CloudFrontディストリビューションの作成時に選択する「Multi-tenant architecture」と「Single website」の違いは、想定される利用規模と管理方法にあります。Single websiteは、一つのWebサイトやアプリケーションを配信することを想定した設定で、シンプルな構成で個人や小規模企業のWebサイトに適しています。設定が簡単で、基本的な配信要件を満たすための機能が事前に最適化されています。一方、Multi-tenant architectureは、複数のテナント（顧客やプロジェクト）が同じインフラを共有する環境を想定した設定で、SaaS（Software as a Service）プロバイダーやホスティングサービスプロバイダーなど、複数の顧客に対してサービスを提供する事業者に適しています。複数のドメインやサブドメインを管理する機能、テナントごとの設定の分離、より高度なセキュリティ機能などが含まれています。Single websiteの利用タイミングは、企業のコーポレートサイト、ECサイト、ブログ、ポートフォリオサイトなど、単一の目的とオーナーシップを持つWebサイトです。Multi-tenant architectureの利用タイミングは、複数の顧客サイトをホスティングするサービス、SaaSアプリケーション、複数のブランドサイトを管理する企業、代理店が複数のクライアントサイトを管理する場合などです。今回のECサイトは単一のWebサイトであるため、Single websiteを選択するのが適切です。

Tip

【解説】Redirect HTTP to HTTPSとCORS-S3Originの理由

「Redirect HTTP to HTTPS」を選ぶことで、ユーザーがHTTPでアクセスしても自動的に安全なHTTPSへ転送され、通信内容が暗号化されます。これにより盗聴や改ざんのリスクを防ぎ、現代のWebサイトに必須のセキュリティ対策となります。CORS-S3Originを選択するのは、S3バケットをオリジンとした場合に、異なるドメインからの画像リクエスト（クロスオリジン）を正しく許可し、Webブラウザで画像がブロックされないようにするためです。他の選択肢としては「AllViewer」や「None」などがありますが、S3を画像配信のオリジンに使う場合はCORS-S3Originが最も適切です。

Tip

【解説】Origin Access Control（OAC）とOrigin Access Identity（OAI）の違い

Origin Access Control（OAC）は、CloudFrontからS3バケットへの安全なアクセスを制御するAWSの最新機能です。OACを使用することで、CloudFrontのみがS3バケットにアクセスできるように設定し、一般のインターネットユーザーからの直接アクセスを防ぐことができます。これにより、セキュリティを向上させながら、CloudFrontのキャッシュ機能とコスト削減効果を最大化できます。OACの主な利点として、すべてのS3リージョンでの動作保証、AWS Signature Version 4（SigV4）による強力な認証、定期的なキーローテーション、より詳細なアクセス制御があります。一方、Origin Access Identity（OAI）は従来の方法で、現在は非推奨とされています。OAIを使わないほうがいい理由として、まずセキュリティレベルが低く、古い認証方式を使用しているため、将来的にセキュリティ上の問題が発生する可能性があります。また、一部の新しいS3リージョンでは動作しない場合があり、AWSが積極的にサポートしていないため、新機能の対応が遅れる可能性があります。さらに、OACは設定が簡単で、AWSコンソールから自動的に適切な設定を生成してくれるため、管理負荷も軽減されます。今回のECサイトでは、最新のセキュリティベストプラクティスに従い、OACを使用してS3バケットへの安全なアクセスを実現します。

4. デフォルトオブジェクトの設定を追加する

  1. 作成したディストリビューションを選択します。
  2. 「一般」タブで編集を開きます。
  3. 「Default root object - optional」を「index.html」に変更します。
  4. 変更を保存します。

注意: ディストリビューションの設定変更には10-15分程度かかります。ステータスが「Deploying」から「Enabled」に変わるまで待ちます。

Tip

【解説】デフォルトオブジェクト設定の重要性とユーザビリティ向上

デフォルトオブジェクトの設定を追加する理由は、Webサイトの基本的なユーザビリティを確保するためです。デフォルトオブジェクトとは、ユーザーがディレクトリのルートパス（例： https://example.com/  ）にアクセスしたときに、自動的に表示されるファイルのことです。「index.html」を設定することで、ユーザーが「 https://your-cloudfront-domain.com/  」にアクセスしたときに、自動的に「 https://your-cloudfront-domain.com/index.html  」を表示するようになります。この設定をしない場合、ユーザーがルートパスにアクセスしても何も表示されず、エラーページが表示されてしまいます。これは、実際の店舗で例えると、「お店の入り口から入ったのに、どこに商品があるかわからない」ような状況で、ユーザーの離脱率を高めてしまいます。デフォルトオブジェクトを設定することで、ユーザーが期待する通りにWebサイトのホームページが表示され、直感的なナビゲーションが可能になります。また、SEOの観点からも重要で、検索エンジンがWebサイトの内容を正しく認識し、適切にインデックスできるようになります。現代のWebサイトでは、index.htmlがデフォルトオブジェクトとして設定されることが標準的な慣習となっており、ユーザーも自然にこの動作を期待しています。

5. Webサイトアクセスの確認

5-1. キャッシュの確認

  1. CloudFrontのページで「ディストリビューションドメイン名」を確認するとCloudFrontのデフォルトドメイン名を取得できます。
  2. デフォルトドメイン名をアクセスするとLPが表示されます。
    1. ブラウザを開いた状態でF12を押すと以下のようなデベロッパーツールを開くことが出います。
    2. 赤線をみると「Miss from CloudFront」と、CloudFrontでCacheが見つからなかったことがわかります。 step5_lp_check_cf_1
  3. 2回目以降のアクセスでは、CloudFrontのキャッシュにより、画像の読み込みが高速化されていることを確認します。
    1. 赤線をみると「Hit from CloudFront」と、CloudFrontでCacheが見つかったことがわかります。 step5_lp_check_cf_2

このステップで何をしたのか

このステップでは、ECサイトのパフォーマンスを向上させるために、静的コンテンツ（画像）と動的コンテンツ（商品情報など）を分離しました。具体的には、S3バケットを作成して商品画像を保存し、CloudFrontディストリビューションを設定して世界中のエッジロケーションから高速に画像を配信できるようにしました。また、NextjsアプリケーションをCloudFrontと連携させ、画像URLをCloudFrontドメインに変更することで、静的コンテンツと動的コンテンツを最適な方法で提供できるようにしました。すべてのEC2インスタンス管理はSystems Managerセッションマネージャーを使用し、セキュリティを向上させました。

ECサイトでどのような影響があるのか

この構成により、ECサイトの表示速度が大幅に向上し、ユーザー体験が改善されました。特に画像の読み込みが高速化され、ページの表示がスムーズになりました。また、EC2インスタンスの負荷が軽減されたため、同じサーバーリソースでより多くのユーザーを処理できるようになりました。さらに、CloudFrontのキャッシュ機能により、データ転送コストも削減されました。

実践チェック：画面キャプチャで証明しよう

下記のチェック項目について、実際にAWSマネジメントコンソールで設定ができていることを確認し、各項目ごとに該当画面のスクリーンショットを撮影して提出してください。

  • S3バケット「ec-site-lp-xxx」が正常に作成されている
  • CloudFrontディストリビューションが正常に作成され、ステータスが「Enabled」になっている
  • CloudFrontディストリビューションの設定で、S3バケットがオリジンとして正しく設定されている
  • サンプルLPファイルがS3バケットに正常にアップロードされている
  • NextjsアプリケーションがCloudFront URLを使って画像を表示するように設定されている
  • 商品画像がCloudFrontから正常に配信されている（ブラウザの開発者ツールで確認）

提出方法： 各項目ごとにスクリーンショットを撮影し、まとめて提出してください。 ファイル名やコメントで「どの項目か」が分かるようにしてください。

構成図による理解度チェック

ステップ4の構成図を元に、このステップで追加・変更したリソースを反映させ、より実践的な構成図を完成させましょう。

なぜ構成図を更新するのか？

  • パフォーマンスの理解: CloudFrontやS3を使った静的コンテンツ配信の仕組みを図で整理し、なぜ高速化できるのかを可視化します。
  • セキュリティ構成の進化: インターネットからのアクセスをALBやCloudFrontに集約し、EC2インスタンスやデータベースをプライベートサブネットに隔離することで、どのように安全性が高まるかを整理します。

構成図の書き方

ステップ4までの構成図をベースに、以下の点を追加・修正してみましょう。

  1. CloudFrontの追加: インターネットの外側にCloudFront（CDN）を描き、ユーザーからのリクエストがまずCloudFrontに届く流れを示します。
  2. S3バケットの追加: CloudFrontのオリジンとしてS3バケットを描き、静的コンテンツ（画像やLPファイル）がここから配信されることを明示します。
  3. 通信経路の整理:
    • インターネット→CloudFront→S3
    • CloudFrontからS3への静的ファイル配信経路
    • ALBはインターネットからの動的リクエストを直接受け取り、Auto Scaling Group（EC2）に転送します（CloudFrontは静的コンテンツ配信専用です）

💡 ヒント: この構成図は、現代的なWebアプリケーションの基本形です。どのリソースがどのネットワーク領域にあり、どのように通信やセキュリティが制御されているかを意識して描いてみましょう。CloudFrontやS3、ALB、Auto Scalingの役割やつながりを自分の言葉で説明できるようになることが目標です。

理解度チェック：なぜ？を考えてみよう

AWSの各リソースや設計には、必ず“理由”や“目的”があります。 下記の「なぜ？」という問いに自分なりの言葉で答えてみましょう。 仕組みや設計意図を自分で説明できることが、真の理解につながります。 ぜひ、単なる暗記ではなく「なぜそうなっているのか？」を意識して考えてみてください。

Q. なぜCloudFrontを使うのでしょうか？ （ヒント：ユーザー体験や配信速度、コスト、セキュリティの観点から考えてみましょう）

Q. なぜS3を使って静的コンテンツ（画像やLPファイル）を配信するのでしょうか？ （ヒント：EC2や他のストレージと比べたときのメリットを考えてみましょう）

Q. CloudFrontとALBはどのような役割分担をしているのでしょうか？ （ヒント：どちらが静的コンテンツ、どちらが動的コンテンツを担当しているかを整理しましょう）

Q. CloudFront経由でS3にアクセスさせ、S3自体はパブリックアクセスを許可しない構成にするのはなぜでしょうか？ （ヒント：セキュリティやコスト、アクセス制御の観点から考えてみましょう）

Q. 今回の構成で、どの部分が「パフォーマンス向上」「コスト削減」「セキュリティ強化」に貢献しているか、自分の言葉で説明してみましょう。

今回のステップで利用したAWSサービス名一覧

Last updated on
ステップ4：ALB、ターゲットグループを利用したEC2インスタンスのスケーリング概要