前回の記事では、AstroでMarkdown記事を書いて、npm run build で dist/ を作るところまでをまとめました。 まだそこまで進んでいない場合は、先にAstroでブログを作ってみる！記事を書くまでの流れを初心者向けに解説から読むと流れがつかみやすいです。

今回はその続きです。 Astroが作ってくれた dist/ を、どうやってインターネットから見られるブログにするのかを見ていきます。

細かい独自ドメイン、Route 53、ACM、GitHub Actionsの自動デプロイは、今回はいったん横に置いておきますね。 まずは「S3とCloudFrontを使うと、静的サイトがどう公開されるのか」をゆっくり整理する回っす！

今回作る構成

今回の全体像は、かなりざっくり言うとこんな感じです。

Astro
  ↓ npm run build
dist/
  ↓
Amazon S3
  ↓
Amazon CloudFront
  ↓
ブラウザ

Astroで作ったブログは、ビルドするとHTML、CSS、JavaScript、画像などの静的ファイルになります。 その静的ファイル一式が dist/ です。

この dist/ の中身をAmazon S3へ置いて、読者からのアクセスはCloudFrontで受ける、という形にします。 「あれこれびより」でも、この考え方で配信しています。

S3とCloudFrontって何？

ここは、先にAWSのサービスとしてのS3とCloudFrontを整理してから、このブログでどう使うかに落としていきます。 いきなり「S3はAstroのファイル置き場です」と言ってしまうと、S3がブログ専用のサービスみたいに見えますからねw 実際はもっと広く使えるAWSの基本サービスです。

S3はAWSのオブジェクトストレージ

まずS3です。 AWS公式ドキュメントでは、Amazon S3は次のように説明されています。

Amazon Simple Storage Service (Amazon S3) is an object storage service.

引用元はWhat is Amazon S3?です。

S3は、ファイルのようなデータを「オブジェクト」として保存するためのAWSサービスです。 Astro専用でも、Webサイト専用でもありません。 画像、動画、ログ、バックアップ、アプリのアップロードファイル、分析用データ、静的サイトのHTMLなど、いろいろなデータを置けます。

S3では、データを「バケット」という入れ物に保存します。 バケットの中に置く1つ1つのデータが「オブジェクト」です。 そして、そのオブジェクトを識別する名前が「キー」です。

たとえば、こんなイメージです。

バケット
  ├─ images/logo.png
  ├─ logs/2026-09-13.log
  └─ posts/example/index.html

images/logo.png や posts/example/index.html がキーです。 フォルダっぽく見えますが、S3としてはキー名でオブジェクトを管理している、という感じっすね。

S3の主な機能としては、次のようなものがあります。

  • オブジェクトの保存
  • バケット単位のアクセス制御
  • バージョニング
  • 暗号化
  • ライフサイクル管理
  • 静的Webサイトホスティング
  • 他のAWSサービスとの連携

メリットは、サーバーを自分で用意しなくても大量のデータを保存しやすいことです。 容量を先に決めてディスクを増設する、みたいなことを考えなくてよいのはかなり助かります。 アクセス権限や暗号化、古いファイルを別の保存クラスへ移すライフサイクル管理なども用意されています。

一方で、注意点もあります。 S3は便利な保存場所ですが、何でも雑に公開してよい場所ではありません。 バケットポリシーや公開設定を間違えると、本来見せたくないファイルまで見えてしまう可能性があります。 また、保存容量、リクエスト数、データ転送などに応じて料金がかかるので、「置いたら完全無料」というわけでもないです。

このブログでは、そんなS3の使い道の中でも「Astroが生成したHTML、CSS、JavaScript、画像などの静的ファイルを置いておく場所」として使っています。 つまりS3全体の機能のうち、今回は静的サイト配信用のファイル置き場として使っている、という位置づけですね。

CloudFrontはAWSのCDNサービス

次にCloudFrontです。 AWS公式ドキュメントでは、CloudFrontは次のように説明されています。

Amazon CloudFront is a web service that speeds up distribution of your static and dynamic web content.

引用元はWhat is Amazon CloudFront?です。

CloudFrontは、Webサイト、画像、CSS、JavaScript、動画、APIレスポンスなどをユーザーへ届けるためのAWSのCDNサービスです。 CDNはContent Delivery Networkの略です。 ざっくり言うと、見る人に近い場所からコンテンツを返しやすくして、表示を速くしたり、配信を安定させたりする仕組みですね。

CloudFrontでは、配信元を「Origin」と呼びます。 Originには、S3、HTTPサーバー、ALB、APIなどを指定できます。 読者のブラウザはCloudFrontにアクセスし、CloudFrontはキャッシュを確認します。 キャッシュにあればCloudFrontから返し、なければOriginへ取りに行って返します。

読者のブラウザ
  ↓
CloudFront
  ↓ キャッシュになければ取りに行く
Origin（S3など）

CloudFrontの主な機能としては、次のようなものがあります。

  • コンテンツ配信
  • キャッシュ
  • HTTPS配信
  • 独自ドメインとの連携
  • Originへのアクセス制御
  • セキュリティヘッダーなどのレスポンス制御
  • アクセスログ

メリットは、サイト表示を速くしやすいこと、HTTPSや独自ドメインを扱いやすいこと、S3を直接公開しない構成にしやすいことです。 公開サイトの入口をCloudFrontに寄せると、あとからキャッシュやセキュリティ周りを整理しやすくなります。

一方で、CloudFrontにも注意点があります。 キャッシュが効くぶん、記事を更新したのに古い内容が表示されることがあります。 その場合はキャッシュの期限を調整したり、キャッシュ無効化を行ったりします。 また、S3だけの場合より設定項目は増えるので、最初は少しとっつきにくいです。

このブログでは、CloudFrontを「S3に置いた静的ファイルを読者へ配信する入口」として使っています。 S3に直接アクセスさせるのではなく、読者はCloudFrontへアクセスします。 CloudFrontが必要に応じてS3からファイルを取得して、ブラウザへ返す流れです。

読者のブラウザ
  ↓
CloudFront
  ↓
S3

最初は「S3にファイルを置いたなら、そのまま見ればいいのでは？」と思うかもです。 私も最初はちょっとそう思いましたw

でも、実際に公開サイトとして運用するなら、S3はファイルの保存場所、CloudFrontは公開用の入口、と役割を分けたほうが扱いやすいです。

なぜS3だけではなくCloudFrontも使うの？

S3だけでも静的Webサイトホスティングという機能はあります。 ただ、このブログではS3の静的Webサイトホスティングを直接公開する構成にはしていません。

理由は、CloudFrontを使うと公開サイト向けの入口を作りやすいからです。 たとえば、こんなことを任せられます。

  • HTTPSで配信しやすい
  • キャッシュで表示を軽くしやすい
  • S3を直接公開しない構成にできる
  • 将来、独自ドメインを載せやすい
  • セキュリティヘッダーなどを付けやすい

特に大事なのは、S3を公開バケットにしなくてよいところです。 「あれこれびより」では、S3は誰でも直接見られる場所にはせず、CloudFront経由で読者へ配信する考え方にしています。

Astroをbuildする

公開する前に、まずAstroをビルドします。

npm run build

このブログでは、npm run build で astro check と astro build が実行されます。 ビルドが成功すると、dist/ が生成されます。

dist/
  index.html
  posts/
    astro-blog-getting-started/
      index.html
  categories/
  rss.xml
  robots.txt
  sitemap-index.xml

この dist/ の中身が、S3へ置く対象です。 src/ や package.json をS3へ置くわけではありません。 公開するのは、ビルド後にできた静的ファイルだけっすね。

S3にdistのファイルを置く

S3には、dist/ の中身をアップロードします。 たとえば、考え方としてはこうです。

dist/index.html
  ↓
S3の index.html

dist/posts/example/index.html
  ↓
S3の posts/example/index.html

S3はフォルダのように見えますが、実際にはオブジェクトをキーで管理するストレージです。 初心者のうちは、そこまで細かく意識しなくても大丈夫です。

まずは「dist/ の中にある公開用ファイルを、同じ構造でS3へ置く」と考えると分かりやすいです。

「あれこれびより」では、ビルド成果物だけをS3へ同期する方針にしています。 ソースコードはGitHubで管理して、S3には配信用のファイルだけ置く、という分け方です。

S3は公開しない

ここはけっこう大事なんです！

S3にファイルを置くからといって、S3バケットを全世界へ公開する必要はありません。 むしろ、今から作るならS3を直接公開するより、CloudFront経由で見せる構成を考えたほうがよいです。

OK:  読者 → CloudFront → S3
避けたい: 読者 → S3を直接見る

S3を公開しないことで、アクセス経路をCloudFrontに寄せられます。 公開サイトとしての入口をCloudFrontにそろえておくと、あとからHTTPS、独自ドメイン、キャッシュ、セキュリティ周りを整理しやすいんですよね。

CloudFrontからS3を配信する

CloudFrontでは、配信元としてS3を指定します。 この配信元のことをOriginと呼びます。

つまり、CloudFrontから見るとS3は「ファイルを取りに行く先」です。 読者はCloudFrontへアクセスし、CloudFrontがS3からHTMLや画像を取得して返します。

ブラウザが /posts/example/ をリクエスト
  ↓
CloudFrontが受け取る
  ↓
必要に応じてS3からファイルを取得
  ↓
ブラウザへ返す

一度取得したファイルは、CloudFront側でキャッシュされることがあります。 キャッシュされると、毎回S3まで取りに行かずに返せるので、表示が軽くなりやすいです。

もちろん、更新したのに古いページが見えることもあるので、ブログを更新したときはキャッシュ更新も意識する必要があります。 このあたりは後半で軽く触れます。

OACって何？

OACは、Origin Access Controlの略です。

ざっくり言うと、S3を誰でも直接見られる状態にせず、CloudFront経由でアクセスさせるための仕組みです。

「あれこれびより」でも、CloudFront Origin Access Controlを使う前提にしています。 S3バケット側では、CloudFrontからの読み取りを許可し、読者がS3へ直接アクセスする形にはしません。

イメージとしては、こんな感じです。

読者
  ↓
CloudFrontだけ通す
  ↓
OACを使ってS3を読む
  ↓
S3

これにより、「配信用の入口はCloudFront」「ファイルの置き場所はS3」と役割を分けられます。 最初は名前がちょっと難しいですが、考え方はわりとシンプルです。

CloudFrontのURLからブログを開いてみる

CloudFrontを作ると、最初はCloudFront側のURLが発行されます。 独自ドメインを設定していない段階では、そのURLからブログを確認します。

ここでは具体的なURLは書きません。 実際の環境ごとに違いますし、ブログ記事に本番の識別情報を書く必要もないからです。

確認するときは、まずトップページが開けるかを見ます。 次に、記事ページ、カテゴリページ、画像、CSSが正しく表示されるかを見ます。

トップページが開ける
記事ページが開ける
画像が表示される
CSSが当たっている
404ページが表示される

このあたりが見えていれば、dist/ のファイルがS3に置かれ、CloudFront経由で配信されている流れがつかめます。

Astroのページで404になる場合

Astroの静的ビルドでは、URLに対応したHTMLファイルが dist/ に作られます。 たとえば、記事ページはこんな感じです。

/posts/example/
  ↓
dist/posts/example/index.html

S3上でも、だいたい同じ構造でファイルが置かれます。

posts/example/index.html

ここで注意したいのが、CloudFrontに /posts/example/ というURLでアクセスされたときに、S3の posts/example/index.html を返せるようにする必要があることです。

構成によっては、URLを書き換える設定が必要になる場合があります。 たとえば、末尾が / のURLなら index.html を見に行く、という考え方ですね。

「あれこれびより」でもAstroのディレクトリ形式のURLに合わせて配信できるようにしています。 ただ、このあたりはCloudFrontの設定方法によって変わるので、この記事では「URLとS3上のファイルの対応を意識する」ところまでにしておきます。

ブログを更新したらどうする？

記事を直したり、新しい記事を追加したりしたら、公開側も更新する必要があります。 基本の流れはこうです。

Astroの記事やコードを修正
  ↓
npm run build
  ↓
dist/ が更新される
  ↓
S3のファイルを更新する
  ↓
必要に応じてCloudFrontのキャッシュを更新する

S3のファイルだけ更新しても、CloudFront側に古いキャッシュが残っていると、しばらく古いページが表示されることがあります。 その場合は、CloudFrontのキャッシュを無効化する、という作業が必要になります。

「あれこれびより」では、この作業をGitHub Actionsで自動化する構成にしています。 ただ、GitHub ActionsやOIDCの話まで入れると一気に濃くなるので、そこは別の記事でゆっくり扱う予定です。

この時点ではまだ独自ドメインではない

今回の範囲では、CloudFrontのURLからブログを開けるところまでです。

実際にブログとして公開するなら、次は独自ドメインを設定したくなります。 たとえば example.com のようなドメインをCloudFrontへ向ける感じですね。

このときに出てくるのが、Route 53やACMです。 Route 53はDNS、ACMはHTTPS証明書を扱うサービスです。

ただ、ここまで入れると話が長くなるので、今回は名前だけで大丈夫です。 まずはS3とCloudFrontで、dist/ が配信される流れを掴むのが大事っすね！

S3とCloudFrontの料金は？

S3とCloudFrontは、使った分に応じて料金がかかります。 個人ブログの初期段階なら大きな金額になりにくいことも多いですが、無料とは言い切れません。

主に見ておきたいのはこのあたりです。

  • S3に保存しているデータ量
  • S3へのリクエスト数
  • CloudFrontのデータ転送量
  • CloudFrontのリクエスト数
  • キャッシュ無効化の回数

特にAWS初心者のうちは、料金アラートを用意しておくと安心です。 「あれこれびより」でも、運用時に気づけるようにCloudWatchや通知、Budget周りを別で用意しています。

この記事では設定手順までは扱いませんが、公開するなら「動いた！」だけで終わらせず、料金の見張りも置いておくといいですね。

まとめ

今回は、Astroで生成した dist/ をS3とCloudFrontで公開する流れを整理しました。

  • npm run build で dist/ を作る
  • S3には静的ファイルを置く
  • S3は直接公開しない
  • CloudFrontを読者向けの入口にする
  • OACでCloudFrontからS3へアクセスさせる
  • AstroのURLとS3上の index.html の対応を意識する
  • 更新時はS3とCloudFrontキャッシュの両方を見る

S3とCloudFrontは最初ちょっと難しく見えますが、役割を分けると理解しやすいです！ S3はファイル置き場、CloudFrontは配信の入口、OACはS3を直接公開しないための仕組み、という感じですね！

次は、独自ドメインやHTTPS、またはGitHub Actionsでの自動デプロイあたりを分けてまとめていきたいです。 ではでは、おつかれっした～。