インフラが分からないので、自分のブログのAWS構成図を書いた

2026-07-27

目次を開く

About ページにも書いてある通り、私はインフラ（クラウド）が大嫌いです。よーわからんから。

でも、作ったサービスをみんなに使ってもらいたい！見てもらいたい！となったら不可欠なものではあるので、アプリ専門家も勉強しておいて損はない（あるいはしとかないと困る）、という。いい立ち位置をしていますね。

このブログは AWS のサービスを利用してホスティングしていますので、その構成図をレベル分けしながら書いて勉強してみようの記事です。

ちょっと待って！なんで Amazon に魂を売っているの？

静的サイトをホスティングするにはたくさんの選択肢があります。単にブログを公開したいだけなのであれば、AWS より安い方法も全然あります。

Vercel, Cloudflare とか・・・？あとは無料でお手軽なのは GitHub Pages とか。最近知ったのですが、GitHub Pages でも独自ドメインを使えるらしいです。

ではその中でなぜ AWS を選んだのか？

おしごとで使っているから。あとは Kindle とかよく読むしお世話になってるから。です。

Level 0: ブログがある

インターネッツの皆様
        ↓
      ブログ

このブログを見ているということは、インターネット経由でこのブログにアクセスできているということです。誰かが作った何らかのすげー技術で。

・・・で？ という感じですが、これはこれで割と凄いことを表しています。世界中どこにいても、インターネットがあればこのブログに到達できるのです。

Level 1: 実際の配信経路

もうすこし詳しく書きましょう。先の構成図では AWS かどうかも分かりません。

インターネッツの皆様
        ↓ HTTPS
    CloudFront
        ↓
       S3

このブログにはバックエンドサーバーが存在していません。 Next.js で生成した静的ファイルを S3 へ配置し、それを CloudFront 経由で配信しています。

読者はまず HTTPS 通信にて CloudFront に到達します。キャッシュがヒットすればそこで返るし、なければ S3 までアクセスしにいく、という経路です。

なるほど、そうなってんのね！と、ここまでなら理解は簡単です。場合によってはこのレベルの構成図でもよい（むしろ簡潔で好まれる）こともあります。

しかし実際には裏に独自ドメイン、証明書、デプロイなどのいざこざも存在しています。次はより詳細に書いてみましょう。

Level 2: 実際の構成

AWS のアイコンを並べてちゃんと書いてみました。

AWS構成図

登場する AWS サービスは以下です。

Route 53
ACM
CloudFront
CloudFront Functions
S3

各サービスが何をしているのか見ていきましょう。

Route 53: 行き先を教えてくれる人

Route 53 は DNS サービスです。

このブログのドメイン名を、実際の接続先である CloudFront に対応づけています。

netakiryosuke.com
        ↓
CloudFront Distribution

このブログでは、A レコードの Alias を使って CloudFront を指定しています。

A レコードは本来、ドメイン名と IPv4 アドレスを対応づけるものです。

が、Route 53 の Alias を使うと、CloudFront や ALB などの AWS リソースを直接指定できます。 これガチで便利。IP アドレスを意識する必要がなくなります。

ACM: この CloudFront は本物ですよの証明書（の管理人）

HTTPS 通信をする場合、リッスンする側に TLS 証明書が必要です。

本構成では TLS 終端が CloudFront となっていますので、ここに 1 つ必要ですね。

そのため、ACM で発行した証明書を CloudFront に関連付けています。

   ACM
    ↓ TLS 証明書 
CloudFront

この証明書により、ブラウザは接続先が netakiryosuke.com の正規の相手であることを確認できます。（厳密には証明書単体で確認しているわけではないですが）

ちなみにこの証明書の発行には DNS 検証が必要です。

発行元がちゃんとドメイン持ってんだろうな！？(ꐦ°᷄д°᷅) というのを証明するために DNS レコードをいじいじして、ほんとにドメイン持ってるよ！ほら、指定されたレコードの追加もできるで^^ という確認をします。

CloudFront: このブログの玄関

CloudFront は AWS の CDN（Content Delivery Network）です。

S3 に置かれているファイルを、世界各地のエッジロケーションにキャッシュし、読者に近い場所から配信します。

読者からの HTTPS 通信を最初に受けるのが CloudFront です。そしてここで終端します。

要するに、ブラウザとの TLS 接続を CloudFront で終了し、暗号化されたリクエストを一度復号するということです。

ただし、CloudFront で復号した内容をそのまま平文で S3 へ流しているわけでもありません。 CloudFront から S3 へは、ブラウザとの通信とは別に HTTPS 接続を張っています。

Browser
   ↓ HTTPS（別の TLS 接続）
CloudFront
   ↓ HTTPS（別の TLS 接続）
S3

つまり、ブラウザから S3 まで一本の HTTPS 通信が貫通しているのではなく、CloudFront を境に 2 つの TLS 接続へ分かれています。

CloudFront Functions: 拡張子を隠す仕事人

CloudFront には CloudFront Functions を関連付けています。

CloudFront Functions は、CloudFront がリクエストやレスポンスを処理する途中で実行されます。本構成では Viewer Request イベントに関連付けているため、読者からのリクエストを CloudFront が受け取った直後に実行されます。

このブログでは URL の書き換えに使っています。なぜ必要なのか？はこちらの記事

S3: ベッドルーム

S3 は超絶初期にできたオブジェクトストレージサービスです。今年 20 周年らしい（2006 年 3 月サービス開始）

S3 には、Next.js でビルドした静的ファイルを置いています。

このブログにはバックエンドサーバーが存在しないため、S3 に置かれたファイルが全てです。つまり寝室、ベッドルームです。

もちろん S3 バケット自体はパブリック公開していません。寝室はむやみに他人に見せるものではありません。

インターネットから直接 S3 にアクセスしてファイルを読むのではなく、構成図の通り CloudFront を経由させています。

CloudFront から S3 へのアクセスには OAC（Origin Access Control）を利用しています。 CloudFront が S3 へ送るリクエストに署名し、S3 側のバケットポリシーでは、このブログの CloudFront Distribution からのアクセスだけを許可しています。

つまり、S3 を非公開にしたまま CloudFront にだけ寝室の合鍵を渡しているような構成です。なんとロマンチックな関係！

ちなみにコンテンツを CloudFront + S3 で配信するのは、OAC まで含めてすべて AWS の超王道アーキテクチャです。

GitHub Actions: 勝手にデプロイしてくれる人

AWS サービスではないですが一応。本ブログのソースコードや記事は GitHub で管理しています。

記事を執筆するごとに AWS にログインして・・・なんてやっていたら面倒なので、CI/CD ワークフローにより執筆以降の作業を自動化しています。

GitHub Actions
  ├→ S3 へアップロード
  └→ CloudFront のキャッシュ無効化

main ブランチへの push をトリガーに、GitHub Actions が起動します。

GitHub Actions では Next.js のビルドし、その成果物を S3 へアップロードします。

その後、CloudFront のキャッシュ無効化も行います。

CloudFront のキャッシュはありがたいのですが、ブログを更新した直後まで古いファイルを返されると困りますので、更新時には一度どいてもらいます。

おわりに

インフラ構成図、あまり書いたことないので勉強になりました。

この構成だと CloudFront と S3 しかあまり意識することがないですが、実際には裏に DNS、証明書、TLS など・・・色々考えることがたくさんある。

ただの静的サイトでこれなのだから、実務のバックエンドサーバがあるシステムや大規模なシステムはより複雑な構成図になるでしょう。

あ～～～よりインフラが嫌いになりそうです、が、

自分がホストしているサービスくらいは、どうやって届いているのか説明できたほうがよいと思っていたのでやってよかったです。