AWS Amplify

解決する課題

Web・モバイルアプリを公開するには、認証基盤、API、データベース、配信用ホスティング、CI/CD など多くの部品を自分で組み上げる必要があります。個々のサービスを正しく接続・設定する作業はフロントエンド中心の開発者にとって負担が大きく、本来注力したい画面や機能の開発から時間を奪います。

AWS Amplify はこの組み立て作業を肩代わりします。

• 認証やデータといったバックエンド機能を宣言的に定義し、必要な AWS リソースを自動で用意する
• Git リポジトリと連携し、push のたびに自動でビルド・デプロイするホスティングを提供する
• フロントエンドのコードからバックエンドを呼び出すライブラリを用意し、接続コードを書く手間を減らす

結果として、少人数やフロントエンド中心のチームでも、スケーラブルなフルスタックアプリを短期間で立ち上げられます。

主要概念と用語

• Amplify Hosting: Git 連携の継続的デプロイ、CDN 配信、プレビュー環境などを提供する静的・SSR 対応のホスティング機能
• バックエンド定義: 認証やデータなどのバックエンド構成をコードで宣言する仕組み。定義をもとに必要な AWS リソースが生成される
• Amplify ライブラリ: フロントエンド（JavaScript や各モバイル向け）からバックエンドを呼び出すためのクライアント SDK
• Amplify CLI / コンソール: バックエンドの作成・更新やアプリ管理を行うコマンドラインツールおよび管理画面
• 環境（ブランチ）: 開発・検証・本番などをブランチ単位で分け、それぞれ独立したバックエンドとホスティングを持たせる単位
• プルリクエストプレビュー: ブランチやプルリクエストごとに一時的な確認用 URL を自動生成する機能

仕様・制限・クォータ

• Hosting は静的サイト、SPA、SSR に対応し、Next.js 12〜15 の管理対象 SSR に加えて Nuxt、Astro、SvelteKit などをアダプター経由で扱える
• ビルドはマネージド環境で実行され、ビルド設定はリポジトリ内の設定ファイルで管理できる
• SSR の配備束は 50 MB までで、対応 Node.js は 20・22・24。フレームワーク機能にも非対応項目があるため、版を上げる前に対応表を確認する
• アプリ数、ブランチ数、同時ジョブ数、ビルド時間、CloudFront 側の配布数など複数のクォータが効く。実効値は Service Quotas と Hosting の制限表で確認する

内部の仕組み

横にスクロール

Amplify Gen 2 は TypeScript のバックエンド定義を AWS CDK の構成へ変換し、利用者アカウントへ対応する AWS リソースをプロビジョニングします。Hosting は別の経路で Git の変更を取り込み、ビルド結果を CDN と必要なサーバー実行基盤へ配備します。

• 認証は Amazon Cognito、データは AWS AppSync と DynamoDB、関数は AWS Lambda、ファイルは Amazon S3 といった形で、定義した機能が個別サービスへ対応する
• ホスティングでは、ビルドしたフロントエンド資産を配信用ストレージに配置し、Amazon CloudFront などの CDN を通じて世界中に配信する
• リソースの生成・更新は内部的に AWS CloudFormation などのインフラ定義として表現され、構成の再現性と一括管理を担保する

生成されたバックエンドは個別サービスでも確認できます。ただしコンソールで恒久変更すると、次回配備で上書きされたり定義との差分が生じたりします。構成変更は原則として Amplify の TypeScript 定義へ戻します。

設計パターン / ベストプラクティス

• 環境をブランチで分離する: 本番・検証・開発をそれぞれ独立したブランチと環境に対応させ、変更を本番へ安全に昇格させる
• プレビュー環境でレビューする: プルリクエストごとの一時 URL を使い、マージ前に実際の画面で動作確認する
• バックエンド定義をコードで管理する: 構成をリポジトリに含めて履歴を残し、レビューと再現を可能にする
• 複雑な要件はコードで拡張する: 抽象化で足りない資源は CDK 構成として追加し、手作業で生成資源を変更しない

運用・監視

• ビルドとデプロイの履歴・ログは Amplify のコンソールから確認でき、失敗時の原因追跡に使う
• 配信側のアクセス傾向やエラーは、CDN やバックエンド各サービスの Amazon CloudWatch メトリクス・ログで把握する
• デプロイに問題があった場合は、以前の成功したビルドへ素早く戻す（ロールバック）運用を基本とする
• カスタムドメインや HTTPS 証明書の管理もコンソールから行え、独自ドメインでの公開を簡単にする

コスト

課金は主に「ホスティング（ビルド時間・配信データ転送・ストレージ）」と「バックエンドが利用する個別サービスの従量課金」に分かれます。

• ビルドの実行時間や、配信したデータ転送量、保存容量に応じて費用が発生する
• 認証・データ・ストレージなどのバックエンドは、裏で動く Cognito・AppSync・DynamoDB・S3 などのそれぞれの料金が加算される
• 小規模な利用には無料利用枠が用意される場合があるが、内容は変動し得るため最新情報を確認する

セキュリティ

• 認証・認可は Amazon Cognito を基盤とし、ユーザープールやソーシャルログイン、トークン管理を利用できる
• データ API には認可ルールを定義でき、ユーザーやグループ単位でアクセス範囲を制御する
• リソース操作の権限は IAM で管理され、最小権限の原則を適用する
• 保存データの暗号化や転送時の TLS は、束ねている各サービスの仕組みをそのまま活用できる

Well-Architected の観点

• 運用上の優秀性: Git 連携の継続的デプロイ、ブランチ単位の環境分離、プレビュー環境により、変更を小さく安全に届けられる
• 信頼性: ホスティングは CDN を通じた配信で可用性を確保し、失敗時はロールバックで素早く復旧できる
• セキュリティ: Cognito と IAM、データ API の認可ルールで認証・認可を一貫して扱える
• コスト最適化: 従量課金が基本で、束ねる各サービスの利用状況を踏まえて無駄を見直せる

試験で問われるポイント

関連サービス・比較

同じくアプリのデプロイを簡単にする AWS Elastic Beanstalk とよく比較されます。Amplify はフロントエンド・フルスタック志向、Beanstalk はサーバーアプリのデプロイ自動化が中心です。

ハンズオン / CLI例

# 既存のフロントエンドへ Gen 2 の定義を追加
npm create amplify@latest

# 開発者専用のクラウドサンドボックスを配備
npx ampx sandbox

# Hosting の CI でブランチ用バックエンドを配備
npx ampx pipeline-deploy \
  --branch "$AWS_BRANCH" \
  --app-id "$AWS_APP_ID"