この記事はヤプリ&フラー 合同アドベントカレンダー Advent Calendar 2025の 18 日目の記事です。
このブログサイトのインフラを EC2 + WordPress から GitHub + Amplify Hosting に再設計した経験について共有します。(いまこの記事を表示しているこのブログが、この記事紹介する構成で動いています。)
この記事では、なぜインフラを見直したのか、なぜこの構成を選んだのか、実際のアーキテクチャと運用体験について解説します。
なぜインフラを見直したのか
以前、別のテックブログを運用していたのですが、その際は EC2 上で WordPress を用いて運用していたのですが、以下のような課題がありました。 その結果、ブログの更新頻度が低くなってしまい、結果として運用をやめてしまいました。
- メンテナンス作業の負担: WordPress やプラグインの定期的なアップデート、セキュリティパッチの適用が必要で、手動作業である以上つい後回しになってしまう
- 記事執筆の手間: 管理画面へのログインが面倒で、結局 Zenn など他のプラットフォームで記事を書くようになっていた
- コスト: 個人ブログのアクセス量に対して、EC2 の継続的なコストが割高だった
一番は管理画面からログインしてから記事を書く必要があるのが面倒で、記事を書くハードルが高くなってしまっていたことです。 Zenn では markdown で記事を書けるので、同じように記事を書けるような仕組みを構築すれば、ハードルが下がるのではないかと考えました。(あと単純に markdown で記事を管理できるようにするには、どうしたらいいのかという技術的な興味もありました。)
GitHub × Hugo × Amplify の選定理由
インフラを見直すにあたり、実現したいことは以下でした。
- markdown で記事を書きたい
- github で記事を管理したい
- できれば自動でデプロイしたい
いくつかの選択を検討したのですが、最終的に GitHub × Hugo × Amplify の組み合わせを選定することになりました。
Hugo とは
Hugo は、Go 言語で書かれた静的サイトジェネレータ(SSG: Static Site Generator)です。マークダウンファイルから HTML ファイルを生成し、静的なウェブサイトを構築するツールです。
Hugo の特徴
- 高速なビルド: Go 言語で実装されており、大量のページでも数秒でビルドが完了する
- マークダウンベース: 記事を markdown 形式で執筆でき、開発者にとって馴染みのある形式
- 豊富なテーマ: コミュニティが提供する多様なテーマから選択でき、デザインのカスタマイズも容易
hugo sererコマンドでローカルで簡単にプレビューできるため、記事の執筆と確認が非常にスムーズです。
Amplify Hosting とは
Amplify Hosting は、AWS が提供する静的サイト向けのマネージドホスティングサービスです。「マネージド」とは、複雑なインフラ設定を AWS が自動的に管理してくれることを意味します。
内部で動いている AWS サービス
Amplify Hosting は、内部では下記のような複数の AWS サービスを組み合わせて動作しています:
- S3: 生成された HTML、CSS、JavaScript などの静的ファイルを保存
- CloudFront: 世界中のエッジロケーションから高速にコンテンツを配信するグローバル CDN
- CodeBuild: GitHub からソースコードを取得し、ビルドを実行する環境
- Certificate Manager: HTTPS 通信のための SSL/TLS 証明書を自動的に発行・更新
これらのサービスを個別に設定しようとすると、それぞれの設定や連携が必要になりますが、Amplify はこれらを統合して管理してるため、ドメイン設定やビルド設定など、必要最低限の情報を入力するだけでブログを公開できます。 そのため、開発者はインフラの詳細を気にせず、ブログの運用に集中できます。 具体的なデプロイの流れについては、後述のアーキテクチャセクションで詳しく解説します。
メリット
サーバー管理が不要
Amplify Hosting はマネージドサービスであるため、サーバーのメンテナンスやセキュリティパッチの適用を気にする必要がありません。WordPress のアップデート管理のような手間から完全に解放されました。
自動デプロイによる効率化
GitHub の main ブランチに変更をプッシュすると、Amplify が自動的にデプロイを検知し、ビルド・デプロイを実行してくれます。記事をマークダウンで書いてコミットするだけで、自動的にブログが更新される仕組みができました。これにより、Zenn のような手軽さを実現しながら、自分のブログで記事を管理できるようになりました。
マークダウンベースの記事管理
Hugo などの SSG(静的サイトジェネレータ)と組み合わせることで、記事をマークダウンファイルで管理できます。VScode などのエディタで直接編集でき、Git で版管理もできる、開発者にとって快適なワークフローが実現されました。
コスト削減
個人ブログのアクセス量では、Amplify Hosting は無料枠で運用できる可能性が高いと考えました。EC2 の継続的なコスト負担から解放され、費用対効果が大きく改善するのではないかと考えています。(まだ構築して時間が経っていないので、実際のコスト感はこのブログ公開時点では不明)
アーキテクチャ
今回構築したブログサービスの全体構成を、システム構成図とともに解説します。
システム構成図
graph TB
subgraph "開発環境"
DEV["💻 ローカル開発環境<br/>VSCode + Hugo"]
end
subgraph "GitHub"
REPO["📝 GitHub Repository<br/>content/posts/*.md<br/>Hugo設定ファイル"]
end
subgraph "AWS Amplify Hosting"
AMPLIFY["🔧 Amplify Console<br/>ビルド・デプロイ管理"]
BUILD["⚙️ CodeBuild<br/>Hugo ビルド実行"]
S3["📦 S3 Bucket<br/>静的ファイル保存"]
end
subgraph "AWS CDN & DNS"
CF["🌍 CloudFront<br/>グローバルCDN配信"]
R53["🔗 Route 53<br/>DNSルーティング"]
ACM["🔒 Certificate Manager<br/>SSL/TLS証明書"]
end
subgraph "ユーザー"
USER["👤 ブラウザ"]
end
DEV -->|git push| REPO
REPO -->|Webhook通知| AMPLIFY
AMPLIFY -->|ビルドトリガー| BUILD
BUILD -->|静的ファイル生成| S3
S3 -->|オリジン| CF
ACM -.->|証明書適用| CF
R53 -->|DNS解決| CF
CF -->|HTTPS配信| USER
USER -->|記事閲覧| CF
style DEV fill:#e3f2fd
style REPO fill:#e8f5e9
style AMPLIFY fill:#f3e5f5
style BUILD fill:#fff3e0
style S3 fill:#fce4ec
style CF fill:#e1f5fe
style R53 fill:#f1f8e9
style ACM fill:#fff9c4
style USER fill:#ffebee
各コンポーネントの役割
開発環境(VSCode + Hugo)
記事の執筆とプレビューを行う環境です。VSCode で マークダウンファイルを編集し、hugo server コマンドでローカル環境でブログをプレビューできます。記事の確認が完了したら、Git で変更をコミットし、GitHub にプッシュします。
GitHub Repository
ブログのソースコード、記事(マークダウンファイル)、Hugo の設定ファイルなどを管理します。Git によるバージョン管理により、記事の変更履歴を追跡でき、ブランチを使った下書き管理も可能です。main ブランチへのプッシュが Amplify へのデプロイトリガーとなります。
Amplify Console
GitHub と AWS サービスをつなぐハブとして機能します。GitHub からの Webhook を受け取り、ビルドプロセスをトリガーします。また、ビルドの進行状況の監視、ブランチ別環境の管理、CloudFront のキャッシュ無効化などを自動的に実行します。
CodeBuild
Amplify がプロビジョニングするビルド環境です。amplify.yml に記載された設定に基づいて、Hugo をインストールし、マークダウンファイルから静的な HTML、CSS、JavaScript を生成します。ビルドが完了すると、生成されたファイルを S3 にアップロードします。
S3 Bucket
ビルドで生成された静的ファイルを保存するストレージです。CloudFront のオリジン(配信元)として機能します。Amplify が自動的に作成・管理するため、手動での設定は不要です。
CloudFront
世界中のエッジロケーションからコンテンツを高速に配信するグローバル CDN です。S3 から取得したコンテンツをキャッシュし、ユーザーに最も近いエッジロケーションから配信することで、レスポンス時間を短縮します。新しいデプロイ時には、Amplify が自動的にキャッシュを無効化します。
Certificate Manager
HTTPS 通信に必要な SSL/TLS 証明書を自動的に発行・管理します。証明書の更新も自動で行われるため、手動での管理は不要です。
Route 53
カスタムドメイン(例: blog.example.com)を CloudFront ディストリビューションに解決する DNS サービスです。ユーザーがドメイン名でアクセスすると、Route 53 が CloudFront の URL に変換します。
デプロイフロー
記事を公開するまでの流れは、以下のようになります:
- 記事執筆: VSCode でマークダウンファイルを作成・編集
- ローカルプレビュー:
hugo serverでローカル環境で確認 - Git コミット: 変更を Git にコミット
- GitHub プッシュ: ブランチを GitHub にプッシュ
- プレビュー環境確認: Amplify が自動生成するブランチ別環境で確認
- main ブランチマージ: プルリクエストを作成し、main ブランチにマージ
- 自動ビルド: Amplify が変更を検知し、CodeBuild でビルドを実行
- S3 アップロード: 生成された静的ファイルを S3 にアップロード
- キャッシュ無効化: CloudFront のキャッシュを自動的に無効化
- 公開完了: 数分後に最新の記事が公開される
この一連の流れが自動化されているため、開発者は記事の執筆に集中できるようになりました。
良かった点
実際運用してみて、想定していた以上に快適なブログ運用が実現できました。ここでは、特に効果を実感した点をいくつか紹介します。
記事執筆のハードルが大幅に下がった
WordPress 運用時代は、記事を書こうと思っても「まずブラウザを開いて管理画面にログインして…」という手順が必要でした。この小さな手間が、記事執筆の心理的なハードルになっていました。
現在は VSCode で直接マークダウンファイルを編集するだけで記事が書けます。ログイン作業は不要で、普段コードを書いているのと同じ感覚で記事が執筆できるようになりました。この「コードを書く感覚で記事が書ける」というのが、開発者にとっては非常に自然で快適です。
AI との協業が可能に
VSCode で記事を書くことで、Claude Code などの AI ツールと協業しながら記事を執筆できるようになりました。これは WordPress の管理画面では実現できなかったワークフローです。記事の構成を相談したり、文章の推敲を依頼したりと、AI をアシスタントとして活用できる環境が整いました。
プレビュー環境の充実
Hugo を導入したことで、ローカル環境で記事のプレビューが簡単にできるようになりました。さらに、Amplify が提供するブランチ別の環境により、マージ前に実際の本番環境に近い状態で記事を確認できます。WordPress 時代には、下書きモードで確認するしかありませんでしたが、今は公開前の確認が格段にやりやすくなりました。
デプロイの完全自動化
記事を書き終えたら、GitHub にプッシュしてプルリクエストを作成し、マージするだけです。その後は Amplify が自動的にビルドとデプロイを実行してくれるため、デプロイ作業を意識する必要がありません。main ブランチにマージすれば、数分後には記事が公開されている状態になります。
メンテナンス作業からの解放
WordPress 運用時代に最も煩わしかったのが、定期的なプラグインやコアのバージョン管理でした。セキュリティアップデートを適用し忘れるリスクも常につきまとっていました。静的サイト生成に移行したことで、こうしたバージョン管理の手間が完全になくなりました。サーバーのメンテナンスやデータベースの管理も不要です。
Git による柔軟な記事管理
記事を Git で管理できることで、下書きの管理が非常にやりやすくなりました。ブランチを切って記事を書き、プルリクエストで確認してからマージという、普段の開発と同じフローで記事が管理できます。また、記事がデータベースではなくファイルとして存在するため、バックアップやバージョン管理が自然に行えます。普段使っている GitHub のアカウントで全てが完結するのも、シンプルで気に入っています。
最後に
個人ブログのインフラを EC2 + WordPress から GitHub + Amplify に移行したことで、記事執筆の体験が大きく改善されました。WordPress のバージョン管理やログイン作業といった煩わしさから解放され、普段コードを書いているのと同じ感覚で記事が書けるようになりました。
個人的には wordpress にログインして記事を描き始めるのが面倒だったので、インフラを変えるだけで「記事を書こう」という心理的なハードルが大幅に下がったと感じています。
もし EC2 + WordPress で個人ブログを運用していて、メンテナンスの手間に悩んでいる方がいれば、静的サイトジェネレータ + マネージドホスティングへの移行を検討してみる価値はあると思います。特に、普段から Git を使っている開発者にとっては、非常に相性の良い構成だと感じています。
この記事が役にたてば幸いです。