AWS App Runner から Amplify Gen 2 へ！個人開発ブログをフルサーバーレス構成へ改修しました

こんにちは。「Shida Notes」の管理環境を、初期の AWS App Runner（コンテナ）構成から、AWS Amplify Gen 2 を用いたフルサーバーレス構成へと大きく移行（リプレイス）しました。

今回は、なぜ立ち上げたばかりの構成を捨ててまで移行したのか、そして Amplify Gen 2 に乗り換えたことでどのような恩恵があったのかをまとめたいと思います。

移行の背景と課題

最初の記事でも書いた通り、当初は「インフラ周りの学習」を目的として、コンテナベースの AWS App Runner + CDK という構成を採用しました。しかし実際に稼働させ、さらに「Markdown記事への画像アップロード機能」などを実装しようとしたところ、いくつかの壁にぶつかりました。

インフラとコードの管理コスト Docker、ECR、CDK（CloudFormation）など、Next.jsを動かすためだけの周辺技術のメンテナンスが個人開発には少々重く感じ始めました。
画像アップロード回りの複雑な権限管理 Next.js のサーバーサイド（Route Handler）を経由して S3 に画像を安全に保存しようとした際、コンテナのIAM権限やセッション管理（NextAuth）の連携が非常に複雑になり、本番環境特有の 500 エラーに悩まされました。
アイドル時のインフラコスト App Runner はオートスケーリングとはいえ、常時最低限のメモリをプロビジョニングするため、個人ブログとしては維持費が気になっていました。

これらの課題を「モダンかつエレガント」に解決する手段として目をつけたのが、最新の AWS Amplify Gen 2 でした。

新しい技術スタック

フロントエンドの Next.js はそのまま活かし、バックエンド（インフラ）環境を Amplify Gen 2 インフラストラクチャに丸ごと置き換えました。

Frontend: Next.js 15 (App Router)
Hosting: AWS Amplify Hosting (Serverless / SSR)
Auth: Amplify Auth (Amazon Cognito + Google OAuth)
Database: Amplify Data (AWS AppSync + DynamoDB)
Storage: Amplify Storage (Amazon S3)

アーキテクチャの変更点とメリット

移行してみて、驚くほど開発体験（DX）が向上しました！そのポイントをいくつか紹介します。

1. Infrastructure as TypeScript による脱コンテナ

Amplify Gen 2 の最大の特徴である「TypeScriptファイルベースのインフラ定義」を採用したことで、リポジトリから Dockerfile や docker-compose.yml が完全に消え去りました。コードを書くのと同じ感覚で、amplify/data/resource.ts などにスキーマを定義するだけで、裏で勝手にAWSリソースが生成されるため、アプリ開発だけに集中できるようになりました。

2. クライアントからの安全な直接アップロード

これまでバックエンドで頑張って処理していた画像のアップロードですが、Amplify Storage SDK を使うことで「ブラウザからS3への直接アップロード」へと劇的に簡略化されました。Cognito 認証と連動してユーザー権限が厳密に守られるため、サーバー側に負荷を一切かけず、かつセキュアに画像を保存・表示できるようになりました。

3. お財布に優しいフルサーバーレス

App Runner のような常駐コンテナではなくなり、AWS の巨大なエッジネットワーク（CloudFront）と Lambda を組み合わせたゼロコールドスタートなフルサーバーレス環境になりました。これによりパフォーマンスが向上しただけでなく、アクセスがない時の費用も限りなく抑えられています。

今後の展望

「インフラを学ぶ」という最初のコンテナ構築の目標は十分に達成できました。そして今回の Amplify Gen 2 移行を通して、「インフラを抽象化し、ビジネスロジックづくりにフルコミットする」という、現代のフロントエンド開発の圧倒的なスピード感を体感することができました。

環境構築の泥沼からは（ついに！）完全に抜け出せたと思うので、これからは純粋な技術アウトプットの記事をドンドン書いていきたいと思います！