公式サイトもAWSで動かしている話、AstroとCI/CDで実現するローメンテ運用
CueCodes

公式サイトもAWSで動かしている話、AstroとCI/CDで実現するローメンテ運用

はい、どうもこんにちは佐藤です！

先日、手持ちの WEB アプリを VPS から AWS に移管している話を書きました。

あの記事を読んで「じゃあ公式サイトはどうしているの？」と思った方、するどい。

実はこの公式サイトも、AWS で動いています。

しかも、 WordPress は使っていません。 Astro という静的サイトジェネレーターで構築して、 Route53・CloudFront・S3・WAF・CodeCommit・CodeBuild・CodePipeline を組み合わせた構成です。サーバーなし、データベースなし。完全サーバーレスですよ。

「なぜ WordPress じゃないの？」という声が聞こえてきそうですね。

その理由と構成図を書いていきますね！

WordPressという選択肢を最初から外した

コンテンツサイトを作るとき、 WordPress はまっさきに名前が上がりますよね。世界中で使われているシェアの高さ、プラグインで何でもできる拡張性。候補に入ってくるのは当然です。

でも今回、 WordPress は最初から候補外にしました。理由は 3 つあります。

まず、攻撃にさらされ続けるメンテナンスコスト。

WordPress は世界中で使われているぶん、攻撃対象としても圧倒的に目立ちます。本体の脆弱性、プラグインの脆弱性、テーマの脆弱性。「緊急アップデートが必要です」という通知が、ある日突然届くのです。

前回の記事で nginx の徹夜対応の話を書きましたが、 WordPress はあれが何度も来るイメージですよ。プラグインを 10 本入れていたら、全部を追いかけ続けることになりますよね。

次に、 AWS に置くとデータベースのコストが嵩むこと。

WordPress はデータベースが必須です。 AWS で本番運用するなら RDS を立てることになります。最小構成でも月額 3,000〜5,000 円、マルチ AZ にすると倍になります。コンテンツサイトのためだけにその固定費を払い続けるのは、割に合いません。

そして、サーバーレスにしようとすると ALB が必要になること。

「WordPressに必要なApacheのメンテが嫌なら、サーバーレスで動かせばいいのでは？」と思いますよね。でも WordPress を ECS Fargate で動かそうとすると、 ALB が必要になります。 ALB は月額約 2,000 円からです。 RDS と合わせると、毎月 5,000〜10,000 円超。これがコンテンツサイトの固定費として重くのしかかるのです。

WordPress を AWS でまともに動かすとこういう構成になります。

graph TD
    Internet -->|HTTPS| R53[Route53]
    R53 --> WAF1[WAF]
    WAF1 --> ALB["ALB（月額 ~2,000円〜）"]
    ALB --> WP["EC2 / ECS（WordPress）"]
    WP --> RDS["RDS MySQL（月額 ~3,000〜5,000円）"]
    WP --> EFS["EFS（メディアファイル）"]

サービスが多く、毎月のコストが重い。それが WordPress on AWS の実態です。

Astro + AWS構成でコストはWordPressの1/5以下

今回の構成を見てみましょう。

graph LR
    subgraph 開発
        E["Cursor / Claude Code"]
        C[CodeCommit]
        E -->|git push| C
    end
    subgraph CICD["CI/CD"]
        P[CodePipeline]
        B[CodeBuild]
        P --> B
    end
    subgraph 配信
        CF[CloudFront]
        W[WAF]
        S[S3]
        CF --> W
        W --> S
    end
    Internet --> R53[Route53]
    R53 --> CF
    C --> P
    B -->|ビルド| S

サーバーがありません。データベースも不要です。

Astro がビルド時にすべてのページを HTML・CSS・JS に変換して、静的ファイルを S3 に置きます。 CloudFront がそのコンテンツをキャッシュして世界中に高速配信。 WAF を前段に置いているのは、不審なリクエストを入口でブロックするためです。

コスト感はこうです。

サービス月額目安
S3ほぼ無料（GB 単位の課金）
CloudFront無料枠
WAF無料枠
CodeBuildビルド時間課金（ほぼ無料）
合計数百円〜

WordPress 構成と比べると月に数千円以上の差が出ます。サービス数も少なく、構成もシンプルですよね。

サーバーがないから攻撃されない、だからローメンテ

「静的サイトはメンテナンスが楽」とよく言われますが、なぜ楽なのかを整理しておきます。

理由はシンプルで、攻撃対象がそもそも存在しないからです。

サーバーがなければ、サーバーへの不正アクセスは起きません。データベースがなければ、 SQL インジェクションが通る場所もありません。プラグインがなければ、プラグインの脆弱性対応も不要です。

WordPress の攻撃ベクターを列挙すると、「本体の脆弱性」「プラグインの脆弱性」「テーマの脆弱性」「 XML-RPC への攻撃」「 wp-login.php へのブルートフォース」……これ全部、静的サイトには存在しないのです。

仮に WAF をすり抜けて S3 に到達したとしても、「実行できるサーバーサイドのコード」がありません。攻撃が届いても、やれることがない。

これは前回の記事で言った「守りをクラウドに任せる」の、さらに一歩先にある考え方ですよね。ミドルウェアを AWS に任せるのではなく、ミドルウェア自体をなくしてしまう発想です。

ファイルベースだからAI執筆補完が使える

これが今回の構成で一番気に入っている点かもしれません。

WordPress で記事を書く場合、管理画面にログインして、ブロックエディタで入力していく形になります。それ自体は大した手間ではないのですが、 AI ツールと連携できないのが痛い。

今回の構成では、記事はローカルの Markdown ファイルです。 Cursor を開けばそのまま編集できますし、 Claude Code で「この記事のリード文を書いて」と話しかければ下書きが出てきます。

完成した記事を「 X のポスト用に 140 字に要約して」「メルマガ向けに書き直して」と頼めば、コンテンツの転用も一瞬です。 WordPress の管理画面に縛られず、手元のエディタで書ける自由がここにあります。

さらに、 git で管理しているので変更履歴が残ります。誰が何を書いたか、どう直したか。記事の共同執筆も、普通のコードと同じやり方でできるのです。

HugoよりAstroのほうが今は好き

静的サイトジェネレーターとして、 Hugo も有力な選択肢です。ビルドの速さは圧倒的ですし、実績も豊富ですよね。

ただ、最近は Astro のほうが良いと感じています。

Hugo の難点は、テンプレートエンジンが Go 製の独自構文であること。慣れれば問題ないのですが、 React や Vue を使い慣れているフロントエンドの知識がそのまま活かせません。テーマをカスタマイズしようとすると、 Go テンプレートを覚える必要が出てきます。

一方、 Astro は .astro ファイルの中で JSX ライクな記述ができます。 React コンポーネントも Vue コンポーネントも、そのまま組み込めるのです。既存のフロントエンド資産が活かしやすい。

それに、 Astro の Island Architecture という考え方が気に入っています。ページ全体を JS で動かすのではなく、インタラクティブな部分だけ JS を送る設計です。静的サイトとしてのパフォーマンスを保ちながら、動的な要素も入れられます。

Markdown の中に React コンポーネントを埋め込める MDX にも対応しているので、将来的にインタラクティブなデモを記事に入れることも可能です。拡張性という意味でも、 Astro のほうが余地がありますよね。

まとめ

というわけで、 WordPress を捨てて Astro + AWS に乗り換えたよ！って話でした！

あ。正確には、必要のないものを削ることで、ローメンテ・ローコスト・AI 執筆補完のすべてが手に入るって感じですねっ。

サーバーをなくせば攻撃されません。データベースをなくせばコストが下がります。ファイルベースにすれば、 AI が相棒になる。「何かを追加する」のではなく「不要なものを取り除く」こと、この 3 つが一度に手に入りますよ。 AI 時代のサイト運営は、引き算から始まるんですよね。

ぜひみなさんも、静的サイトへの移行を試してみてください！

この記事をシェアする

Xでシェア LINEでシェア