homeIcon

【構成編】プロフィールサイトAWS移行メモ 〜インフラ初心者を添えて〜

インフラ
2025.09.07
2025.09.07

はじめに

こんにちは。
今回は、このプロフィールサイトのインフラををVercelからAWSに移行したので、その過程を備忘録として残したいと思います。
移行理由としてはスキルアップのためにAWSを使いたかったからというのが一番大きいですが、インフラをVercelに任せるのではなく、しっかりと自分で理解しておきたかったからという思いもあります。
AWSに関しては入門したてではありますが、この記事を通して少しでも同じような方の助けになれば幸いです。

前提

まず前提として、このプロフィールサイトの技術スタックを以下にまとめます。
記事のコンテンツ管理はmicroCMSを使用し、Jamstackな構成になっています。
各ページは静的生成を前提としており、パフォーマンスにも考慮した設計になっています。

フロントエンド

  • Next.js（React/TypeScript）

CMS

  • microCMS

構成

今回AWSで構築したかったものとして、大きく「静的サイト構築」「メール配信(問い合わせ)」の2つがあったので、使用したサービスとしては以下のようになっています。
「問い合わせ」では以前はメール配信にnodemailerを使用していましたが、今回の移行に伴い「Amazon SES」を用いた構成に変更しました。
また、今回のAWS移行ではCDKを使用し、手動のコンソール操作を可能な限り減らしています。
ついでに、GitHub ActionsでCI/CDも構築してみました。

  • 静的サイト構築：CloudFront, S3
  • メール配信；API Gateway, Lambda, SES
  • その他；CDK, IAM, ACM, Route53
  • CI/CD；GitHub Actions（mainへのプッシュ、microCMSでの記事更新）

▼アーキテクチャ図

画像1

なぜこの構成なのか

上記の構成にした理由としては以下があります。
バックエンドを必要としない構成であれば「CloudFront + S3」の構成はベターですが、細かい部分はAIとの壁打ちで決めていきました。

構成理由

  • パフォーマンス
    • CloudFront による全世界エッジ配信で、海外からのアクセスも高速
    • 画像や静的ファイルのキャッシュTTLを細かく制御可能
  • コスト最適化
    • 静的サイトは S3 に置くことで固定費ほぼゼロ、CloudFront の従量課金も安価
    • 問い合わせAPIも Lambda + API Gateway なので使用分だけ課金
  • セキュリティと制御性
    • S3 を完全非公開にして CloudFront 経由のみで配信（OAC）
    • API Gateway と Lambda の IAM 権限や WAF によるレート制限・ボット対策
    • SES による SPF/DKIM/DMARC 設定で迷惑メール入りを防ぐ
  • 運用拡張性
    • SSR/ISR が必要になったら CloudFront の一部オリジンを ALB+ECS などに差し替え可能
    • 検索やログ収集などを別途追加しても、既存構成を壊さず統合可能
  • インフラの見える化
    • CDK で全構成をコード化 → 履歴管理可能
    • 環境（dev/stg/prod）を簡単に複製
  • 運用の見通し
    • GitHub Actions と相性がよく、microCMS の Webhook から再ビルド・再配信を自動化

この組み合わせの強み

要素理由
S3（静的サイトホスティング）高耐久（99.999999999%）、スケーラブル、低コスト。HTML/CSS/JS/画像の配信に最適。
CloudFront（CDN）世界中のエッジロケーションから高速配信。S3を私有化したままOAC経由で安全に公開可能。
API GatewayHTTPSエンドポイントを簡単に作成。CORSや認証も管理しやすい。
Lambdaサーバーレスでメンテ不要。利用分だけ課金。Node.js/TypeScriptで実装可能。
SES高到達率・安定したメール送信。Gmail API不要で運用できる。
ACM（証明書）無料のTLS証明書を自動更新。CloudFront用はus-east-1必須。
Route53グローバルAnycastで高速・安定解決。ACMのDNS検証と相性良く自動更新が楽。
CDKAWSリソース構成をコードで管理。環境の再現性と変更履歴管理が容易。

コスト

試算（月額）

では、この構成でのコスト(月額)を試算してみます。
前提や各サービスの内訳は後述しますが、結果は以下になりました。（意外とお安い...！）

合計：約 $0.754/月（約 110円）

前提

今回の試算に使用した値は以下の通りです。
正直、かなり高望みしてる感がありますが、ご了承ください...

  • PV：10,000 / 月
  • S3(Standard)：1GB 保管
  • API Gateway (HTTP API)：1,000 回/月
  • リージョン：閲覧者の大半が日本想定
  • 料金は USD・税抜

参考（“Always Free”）

  • CloudFront は 毎月 1TB のデータ転送・1,000万リクエストが無料枠。
  • CloudFront Functions は 200万回 が無料枠。
  • Lambda は 100万リクエスト + 40万GB-s/月が無料枠。

必要なカウント

  • CloudFront リクエスト数 ≒ PV × 1ページあたりの静的ファイル数
    　→ 最小構成で ~6 リクエスト/ページ（HTML+CSS+JS+画像2〜3）= 約 60,000 リクエスト/月（目安）
  • データ転送量 = PV × ページ重量
    　→ 0.5MB → 5GB、1.0MB → 10GB
  • 1回の問い合わせで、サイト運営者(私)と入力者への2つのメール配信を行うため、SESのカウントが API Gateway × 2 になってます。

サービス別の目安コスト

サービス想定使用月額の目安
CloudFront5〜20GB の転送（約6万リクエスト）$0
CloudFront Functions~6万回$0
S3（Standard・保管）1GB を保管約 $0.02〜$0.03
S3（リクエスト）オリジン到達を10%と仮定 → GET ~6,000 回≪ $0.01
API Gateway（HTTP）1,000 回$0.001
Lambda128MB・~200ms × 1,000 回$0
SES2000 通（サイズ 100KB）~$0.223
Route 53パブリックホストゾーン 1つ$0.50
ACM（証明書）CloudFront 用パブリック証明書$0
CloudWatch LogsLambda のログ少量(数MB)≈$0

というわけで、CloudFront や Lambda が無料枠に収まる限り、固定費は 実質 Route 53 + SES + S3 保管が中心になります。

Route53でドメイン取得する場合は

今回、「.com」ドメインを Route53 で登録して CloudFront に ALIAS しました。
そのため、上記に加えて Route53 のドメイン登録料（年額）「$15/年」が発生しています。
他の TDL の金額などは以下を参照ください。
Amazon Route 53 Pricing for Domain Registration

Amplify との比較

静的サイト構築の選択肢として上記の構成の他に、Amplifyを用いた構築方法もあるかと思います。
Amplifyとは、AWS上にモバイルアプリやWebアプリの開発を迅速化するためのフルスタックの開発フレームワークであり、素早く簡単にデプロイを行うことができるサービスです。
Amplifyを用いた構成ではインフラ管理の負担が軽減される一方で、自動で行われる部分が多くVercelの二の舞になりそうな気がしたので、今回は「CloudFront + S3」の構成をとりました。
以下に比較をまとめてみましたので、参考にしていただければと思います。

観点S3+CloudFront(+APIGW/Lambda/SES)AWS Amplify（Hosting/Gen2）
セットアップ速度低〜中：CDKで雛形があれば中。手作業だとやや重い高：リポジトリ接続→自動ビルド→即デプロイ。PRプレビューも標準
運用負荷中：証明書(us-east-1)、OAC、キャッシュ無効化、無停止更新など自分で管理低：ビルド/配信/証明書/ドメイン設定が一元化。自動無効化やプレビューあり
配信チューニング自由度最高：CloudFrontのビヘイビア、ヘッダポリシー、Edge関数、キャッシュキー等を細かく制御中：多くは“いい感じ”に隠蔽。低レベルのツマミは露出が限定的
セキュリティ制御柔軟：WAFの細粒度ルール、CAPTCHA、レート制限、S3私有化+OAC、厳格CSPなど自由中：標準的には十分。ただしWAF/ヘッダ等の高度設定は露出範囲が限られることがある
問い合わせ（メール）実装SES 直結が最短：API GW→Lambda→SES。監査用DynamoDBやDLQも容易依然として Lambda/SES を自前で定義（Amplify Functionsからでも可）
コスト最適化詰めやすい：各サービスを用途最小に切る。静的配信は最安クラス良好：小規模では大差ないことも。ただし“隠蔽”分の自由度は下がる
ベンダーロック-インどちらもAWSだが、生のAWSプリミティブに近い分、将来の移行自由度が高い構成がAmplifyに抽象化される分、移行時の再配線が必要
IaC/再現性強い：CDK/Terraformで完全再現・分離デプロイAmplify の設定/ビルドは簡単だが、低レイヤは抽象化（一部IaC表現が難しい箇所あり）
観測/監視CloudWatch/WAF/S3/CF Logs を任意に組み立て基本は十分。細粒度のログ/メトリクス連携は制約が出ることあり
Next.js/SSR 等CloudFront+Lambda@Edge/Functions で高度構成可能（やや難度高）対応が簡単：Amplify Hosting がSSR/ISRのビルド～配信を隠蔽してくれる
企業要件（セキュリティ審査）通しやすい：要件に合わせて設計・証跡化早いが、細かい要件に合わせづらい場面あり

こんなとき S3+CloudFront 直構成を選ぶ

  • WAF を使った厳しめのボット対策・企業セキュリティ要件に合わせた細部調整が必要
  • レスポンスヘッダ・キャッシュ・オリジン構成を細かく性能チューニングしたい
  • 将来、画像のオンザフライ最適化、多オリジン分割、リージョン分散など拡張の余地を残したい
  • すべてをIaC（CDK/Terraform）で厳密再現し、環境分離やアカウント分離を徹底したい

こんなとき Amplify を選ぶ

  • まずは最速で信頼できる公開・PRプレビュー・自動デプロイが欲しい
  • Next.js/SSR/ISR 等も黒箱で任せたい
  • チームに専任のインフラ担当がいない／運用は最小限にしたい

AWS Amplify（アプリケーションの構築とデプロイ）| AWS

AWS Amplify を使用して、フルスタックのウェブアプリケーションおよびモバイルアプリケーションの開発を加速します。開始も簡単、スケールも簡単。クラウドの専門知識は不要。

aws.amazon.com

OGP Image

まとめ

この記事では、構築するインフラの具体的な構成やサービス、コストなどについて紹介しました。
次の記事から、実際にどのように構築したのかを記載していきますので、気になる方はぜひご覧ください！

参考

Share