AWS Amplifyは、認証やデータベースといったバックエンドと、フロントエンドのホスティングを、ひとつのエコシステムでまとめて構築・公開できるAWSのフルスタック開発プラットフォームです。この記事では、現行のGen 2でバックエンドをTypeScriptのコードとして定義する仕組み、npm create amplifyからnpx ampx sandboxまでの実作業、Auth・Data・Storage・FunctionsがそれぞれCognitoやAppSyncなどどのAWSサービスに対応するのか、そしてAmplify Hostingの無料枠と超過単価までを一次情報で整理します。Gen 1との設計思想の違いと、採用すべき条件・見送るべき場面の判断基準まで、実装者が構成を決めるときに迷う論点を具体的な数値で示します。
まとめ:AWS Amplifyの全体像・料金・採用判断の要点
AWS Amplifyは、バックエンドの構築とフロントエンドのホスティングを1つのツール群で完結させるフルスタックプラットフォームです。現行のGen 2では、認証やデータモデルをamplify配下のTypeScriptコードとして宣言し、その定義がAWS CDKに変換されてクラウドへ反映されます。バックエンドの実体はCognito・AppSync・DynamoDB・S3・Lambdaといった標準的なAWSサービスで、Amplifyはそれらを束ねて型安全に扱う薄い層だと捉えると位置づけが整理できます。
料金は大きく2系統に分かれます。Amplify Hostingにはビルド時間・CDNストレージ・データ転送・SSRリクエスト・SSR実行時間の無料枠(12か月)があり、超過分だけが従量課金されます。一方でバックエンドを構成するCognitoやDynamoDBなどは各サービスの料金が別途かかるため、総額はアプリの構成次第です。フロントとバックを速く立ち上げたいスタートアップ的な開発には向き、細かなインフラ制御を最初から握りたい大規模要件では素のCDKやTerraformが向きます。判断に迷う実装者は、本記事後半の採用条件と見送り条件の整理で自分のプロジェクトを当てはめてください。
AWS Amplifyの全体像とGen 2のコードファーストなバックエンド定義
Amplifyを設計に取り込むには、まず「フロントエンドの器」ではなく「フルスタックの土台」だと捉え直すところから始めます。ここを曖昧にしたまま使うと、Hostingだけの静的サイト配信ツールと誤解し、認証やデータ同期といった中核機能を取りこぼします。
フルスタック開発プラットフォームとしてのAmplifyの立ち位置
Amplifyが担うのは、フロントエンドのコードとバックエンドのリソースを同じリポジトリで管理し、ひとつのワークフローでデプロイまで運ぶ役割です。バックエンドをマネージドなAWSサービスの組み合わせとして提供する点で、サーバー台数を意識しないサーバーレスの考え方と地続きにあります。概念全体の判断軸はサーバーレスとは何か、コンテナとの使い分けを解説した記事で確認でき、AmplifyはそのサーバーレスをWeb・モバイルアプリ開発の文脈でパッケージ化したものと位置づけられます。
TypeScriptコードでバックエンドを宣言するGen 2の構成
現行のGen 2は、バックエンドをコードとして書く方式を採ります。amplifyディレクトリのbackend.tsやauth・dataのリソースファイルに、必要な認証方式やデータモデルをTypeScriptで宣言し、その定義がAWS CDKへ変換されてクラウドに反映される流れです。設定がすべてリポジトリ内のコードに収まるため、型による補完が効き、インフラの変更もプルリクエストのレビュー対象にできます。この「バックエンド構成もアプリコードと同じ土俵で扱える」点が、Gen 2の設計上の中心にあります。
実装で参照する版番号も押さえておきます。Gen 2の中核パッケージ@aws-amplify/backendは1.24系(2026年7月29日公開、2026年9月時点のnpm latest)、クライアント側のaws-amplifyは6.20系です。開発の実体はGitHubのamplify-backendリポジトリで公開されており、リリースノートから変更点を追えます。
開発者ごとのクラウドサンドボックスで安全に並行開発する仕組み
Gen 2では、開発者が自分専用のクラウド環境(サンドボックス)を立てて作業できます。ローカルの疑似環境ではなく実際のAWSリソースを個人単位で持つため、本番に近い挙動を確かめながら、他メンバーの環境と干渉せずに並行開発を進められます。コードを保存するとサンドボックスへ差分がデプロイされ、動作確認までの往復が短くなるのが利点です。公式のサンドボックス設定ドキュメントは、開発者1人につき1つのサンドボックスを配ることを推奨し、本番ワークロードを想定した環境ではないと明記しています。共有の開発環境を1つだけ使う構成にありがちな、変更のぶつかり合いを避けやすくなります。
npm create amplifyで始めるGen 2バックエンド構築の実作業
ここからは手を動かす手順です。Gen 2は雛形の生成から個人環境への反映まで3つのコマンドで足りるため、概念を読むより先に動かしたほうが理解が速く進みます。以下のコードはAmplify公式ドキュメントの記述に沿ったものです。
npm create amplifyで生成されるamplifyディレクトリの構成
雛形の作成はcreate-amplifyパッケージ(2026年9月時点で1.3系)が担います。既存のフロントエンドプロジェクトの直下で次を実行すると、amplifyディレクトリと最小構成のリソース定義が置かれます。
$ npm create amplify@latest
amplify
├── auth
│ └── resource.ts
├── data
│ └── resource.ts
├── backend.ts
└── tsconfig.json
生成物は4ファイルだけです。authとdataが個別リソースの宣言、backend.tsがそれらを束ねる入口、tsconfig.jsonがバックエンド定義用の型設定を持ちます。CloudFormationのテンプレートもCLIの対話履歴もリポジトリに現れないため、構成の全体像はこの4ファイルを読むだけで追えます。
defineAuthとdefineDataでAuthとDataを宣言するコード例
リソースの宣言はdefineAuth・defineDataといった関数で書きます。メールアドレスでのログインと、所有者だけが読み書きできるTodoモデルを定義する最小形は次のとおりです。
// amplify/auth/resource.ts
import { defineAuth } from "@aws-amplify/backend";
export const auth = defineAuth({
loginWith: { email: true },
});
// amplify/data/resource.ts
import { a, defineData, type ClientSchema } from "@aws-amplify/backend";
const schema = a.schema({
Todo: a.model({ content: a.string() })
.authorization((allow) => [allow.owner()]),
});
export type Schema = ClientSchema<typeof schema>;
export const data = defineData({
schema,
authorizationModes: { defaultAuthorizationMode: "userPool" },
});
この十数行が、Cognitoユーザープールと、AppSyncのGraphQL API、DynamoDBのテーブル一式に展開される仕組みです。allow.owner()と書けば行レベルの所有者判定がリゾルバに落ち、defaultAuthorizationModeにuserPoolを指定すればAPIの既定認可がCognito経由になります。書式の網羅はAuthのセットアップ手順とDataのセットアップ手順にまとまっています。defineAuthが作るCognitoリソースの既定値と、既存ユーザープールをreferenceAuthで取り込む手順は「Amplify×Cognito認証の実装手順:defineAuthと既存プールの参照」で解説しています。
npx ampx sandboxで個人環境へ差分デプロイする手順と後始末
宣言したバックエンドを自分のAWSアカウントへ反映するのがampx sandboxです。起動したままファイルを保存すると差分だけが再デプロイされ、接続情報はamplify_outputs.jsonに書き出されてフロントエンドから読み込まれます。
$ npx ampx sandbox
$ npx ampx sandbox --stream-function-logs
$ npx ampx generate outputs --app-id <APP_ID> --branch main
$ npx ampx sandbox delete --yes
検証が済んだらsandbox deleteで環境ごと畳んでください。ここを忘れるとCognitoユーザープールやDynamoDBテーブルが各開発者のアカウントに残り、翌月の請求で気づく原因です。利用できるオプションはCLIコマンドのリファレンスに一覧があり、Lambdaのログを手元へ流す--stream-function-logsや、CIで一度だけ流す--onceも同じ系統で指定します。
Amplifyが提供する主要カテゴリと内部で動くAWSサービス
Amplifyの機能は、いくつかのカテゴリに整理されています。それぞれが裏側でどのAWSサービスを呼んでいるかを押さえると、料金の見積もりや、Amplifyの枠を超えたい場面での拡張方針が立てやすくなります。
Auth・Data・Storage・Functionsという4つのカテゴリ
Gen 2がビルトインで持つ中核カテゴリは、認証のAuth、データのData、ファイル保存のStorage、サーバー処理のFunctionsです。Authはサインアップやログイン、多要素認証を宣言的に設定でき、DataはGraphQLのスキーマからリアルタイム同期するAPIを生成します。Storageはファイルのアップロードとアクセス制御、Functionsはイベントに応じて動く関数の実行を担います。Gen 1が持っていたAnalyticsやGeoなど幅広いカテゴリと比べ、Gen 2は主要な4カテゴリに絞って足場を固めた構成です。
Cognito・AppSync・DynamoDB・S3・Lambdaとの対応関係
各カテゴリの実体は、いずれもAWSの標準サービスです。Authは背後でAmazon Cognitoのユーザープールを作ります。料金体系や画面まわりの制約はAmazon Cognitoのできることと料金を整理した記事で確認でき、Amplifyから使う場合もMAU課金の考え方は同じです。DataはAppSync(GraphQL)とDynamoDBの組み合わせで動き、AppSync自体の仕組み・接続できるデータソース・料金と採用判断はAWS AppSyncとは何かを実装者目線で解説した記事にまとめています。StorageはAmazonのオブジェクトストレージであるS3を使い、FunctionsはLambda関数として実行されます。つまりAmplifyは新しい独自基盤ではなく、これらを型安全にまとめる層です。ファイル保存の詳細はAmazon S3の仕組みと料金を解説した記事、関数実行の制約はAWS Lambdaの料金体系と採用判断を解説した記事が、Amplifyの裏側を理解する助けになります。
CDKで任意のAWSサービスを組み込める拡張性と設計上の勘所
ビルトインの4カテゴリで足りない要件は、AWS CDKを通じて任意のサービスを足して補えます。たとえば通知にSNS、キューにSQS、HTTPの前段にAPI Gatewayを組み込むといった拡張も、同じバックエンド定義の延長で書けるのが利点です。backend.tsが返すオブジェクトからCDKのスタックを取り出して直接リソースを足す作法はカスタムリソースの公式ガイドに示されており、CDK側の考え方はAWS CDKの仕組みとCloudFormation・Terraformとの違いを解説した記事が下地になります。API層の設計方針はAPIゲートウェイの役割と導入判断を解説した記事が参考になります。ここで意識したいのは、Amplifyの型付きAPIで完結する範囲と、CDKへ降りて生のリソースを触る範囲の境界を、プロジェクト初期に決めておくことです。境界が曖昧なまま拡張を重ねると、Amplifyの手軽さとCDKの自由度が中途半端に混ざり、保守が読みにくくなります。
Amplify Hostingのデプロイ手順と無料枠・超過単価の実額
Amplifyのもう一方の柱が、フロントエンドを公開するAmplify Hostingです。バックエンドと同じコミットでまとめてデプロイでき、料金は無料枠と従量課金で構成されます。深い比較は専用記事に譲り、ここでは全体像と数値の勘所を押さえます。
Gitコミットごとにフロントとバックをまとめて公開する一連の流れ
Amplify HostingはGitリポジトリと連携し、指定ブランチへのコミットを契機にビルドとデプロイを自動で走らせます。プルリクエストごとのプレビュー環境、独自ドメインの割り当て、WAFによる保護までを画面から設定でき、フロントエンドとバックエンドを1回のコミットで揃えて反映できるのが特徴です。SSR(サーバーサイドレンダリング)に対応するため、Next.jsやNuxtのような動的フレームワークも配信できます。Hosting単体の料金や、S3+CloudFrontを自前で組む構成との違いはAWS Amplify Hostingの料金と他構成との違いを解説した記事で詳しく比較しています。
無料枠と従量課金で決まるAmplify Hostingの料金構造
Amplify Hostingの料金は、ビルド時間・CDNストレージ・データ転送・SSRリクエスト・SSR実行時間の5項目で決まります。新規AWSアカウント向けに12か月の無料枠があり、超過した分だけが従量で課金される仕組みです。per-seatのような人数課金はなく、月額の最低料金も設けられていません。次の数値はAWS Amplifyの公式料金ページに基づく2026年9月時点の目安です。
| 項目 | 内容(2026年9月時点) |
|---|---|
| ビルド時間(無料枠) | 月1,000分まで |
| CDNストレージ(無料枠) | 月5GBまで |
| データ転送(無料枠) | 月15GBまで |
| SSRリクエスト(無料枠) | 月50万件まで |
| SSR実行時間(無料枠) | 月100GB時間まで |
| ビルド超過(Standard) | 1分あたり0.01USD |
| ビルド超過(Large) | 1分あたり0.025USD |
| ビルド超過(XLarge) | 1分あたり0.10USD |
| CDNストレージ超過 | 1GB月あたり0.023USD |
| データ転送超過 | 1GBあたり0.15USD |
| SSRリクエスト超過 | 100万件あたり0.30USD |
| SSR実行時間超過 | 1GB時間あたり0.20USD |
| WAF(アプリ単位) | 月15USD+WAF利用料 |
見積もりの勘所は、Hostingの料金は比較的読みやすい一方、総額を左右するのはバックエンド側だという点です。CognitoのアクティブユーザーやDynamoDBの読み書き、Lambdaの実行回数は各サービスの従量で積み上がるため、Hostingの無料枠内に収まっても全体では課金が発生します。まず小さく作って各サービスの実使用量を実測し、そこから総額を試算する進め方が向いています。
月間100万SSRリクエスト規模で試算する超過分の月額イメージ
数字を具体に落とします。無料枠が切れた13か月目のNext.jsアプリで、月間100万SSRリクエスト・SSR実行時間300GB時間・データ転送200GB・CDNストレージ10GB・ビルド600分(Standard)を消費したとします。単価表を当てはめると、SSRリクエストが0.30USD、SSR実行時間が60.00USD、データ転送が30.00USD、CDNストレージが0.23USD、ビルドが6.00USDで、Hosting分の合計はおよそ96.53USDです。
内訳を見ると、支配的なのはSSR実行時間とデータ転送の2項目で、リクエスト件数そのものは1USDにも届きません。削るならレンダリング方式の見直し(静的化・キャッシュ)が先で、リクエスト数を気にしても効果は薄い、という順序が数字から明確です。ここにCognitoのMAU課金やDynamoDBの読み書き、Lambdaの実行料が乗るため、Hosting分だけを見て予算を組むと足りなくなります。Firebaseの無料枠と超過単価を実額でまとめた記事と並べると、同じフルスタック基盤でも課金軸の置き方が違うことが分かり、比較検討の材料になります。
Gen 1とGen 2の違いと移行を判断するときの実務ポイント
Amplifyには、CLI主導だったGen 1と、コードファーストのGen 2という2つの世代があります。新規開発ではGen 2が基本線ですが、既存のGen 1プロジェクトを抱える場合は、移行の要否を状況で見極める必要があります。
CLI駆動のGen 1とコードファーストなGen 2の設計思想の違い
Gen 1は、CLIの対話やAmplify Studioの画面からリソースを作っていく方式でした。手早く始められる反面、構成の実体がツール側に隠れ、変更の履歴やレビューがコードに残りにくいという弱点がありました。Gen 2はこれをTypeScriptのコードへ寄せ、バックエンド定義をリポジトリ内で型付きに管理する方向へ舵を切っています。裏側はCDKに統一され、複雑な要件でもコードで表現しやすくなりました。コマンド体系もamplifyからampxへ替わり、開発体験の中心が「対話で組む」から「コードで宣言する」へ移った、と捉えると差分が見えます。
既存Gen 1プロジェクトからGen 2へ移行するかの判断軸
移行の判断は、玉虫色にせず現状で切り分けます。安定稼働中のGen 1アプリを、Gen 2の型安全やレビュー性のためだけに急いで載せ替える必要は薄いでしょう。一方、これから機能を大きく増やす、あるいはインフラ構成をコードで厳密に管理したい局面なら、Gen 2への移行が投資に見合います。両世代は並行して使えるため、既存はGen 1のまま維持し、新規モジュールからGen 2で書き始める段階的なアプローチも取れます。移行そのものが目的化しないよう、得られる保守性の向上と移行コストを天秤にかけて決めてください。
AWS Amplifyを採用すべき条件と見送るべき場面の判断基準
ここでは判断を言い切ります。Amplifyは万能ではなく、プロジェクトの性質が合わなければ素のCDKやTerraform、あるいは別のホスティング基盤のほうが素直に運べます。自社のどの案件に差し込むかを、条件付きで見極めてください。
AWS Amplifyの採用が効くプロジェクトの条件と設計の勘所
採用が効くのは、次の条件が重なるときです。認証・データ・ストレージという定番の構成要素を素早く立ち上げたく、フロントエンドとバックエンドを少人数で並走させ、標準的なAWSサービスの組み合わせで要件が満たせる開発が当てはまります。SaaSの試作、社内ツール、スタートアップの初期プロダクトのように、速度と型安全を両立させたい局面でこそ強みが出るでしょう。バックエンドがマネージドに寄るぶん、運用チームがサーバー管理から解放される効果も実利になります。AWS上でこうしたフルスタック構成を自社に取り入れるなら、AWSを含むクラウドインフラ構築の相談窓口で構成の妥当性を検討できます。
AWS Amplifyを見送るべき場面とはまりやすい失敗パターン
見送りを検討すべきなのは、インフラを最初から細部まで自前で握りたい大規模要件や、Amplifyの型付きAPIから外れる複雑なネットワーク・権限設計が中心になるケースです。こうした要件では、Amplifyの抽象化がかえって足かせになり、CDKへ降りる範囲が増えて手軽さの利点が薄れます。はまりやすいのは、Amplifyの便利機能に寄せた設計と、CDKで直接組んだ部分が混在し、どちらの流儀で保守するのか曖昧になるパターンです。もう1つの落とし穴が、開発者ごとのサンドボックスを消し忘れて課金が積み上がる運用で、これはampx sandbox deleteをチームの手順に組み込むだけで防げます。判断に迷う境界領域では、まず小さなアプリで認証とデータ同期まで作り、開発速度と料金の実データを見てから本格採用を決めるのが安全です。
よくある質問
AWS Amplifyの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。
AWS Amplifyは無料で使えますか?
Amplify Hostingには新規AWSアカウント向けに12か月の無料枠があり、ビルド月1,000分・CDNストレージ5GB・データ転送15GB・SSRリクエスト50万件・SSR実行時間100GB時間までは料金がかかりません。ただしバックエンドを構成するCognitoやDynamoDBなどは各サービスの料金が別途発生します。小規模な検証なら無料枠内で試し、実使用量を見てから本番規模を試算する進め方が向いています。
Amplify Gen 2とGen 1はどちらを選ぶべきですか?
新規開発なら、TypeScriptでバックエンドを型付きに定義できるGen 2が基本の選択です。既存のGen 1アプリが安定して動いているなら、無理に載せ替えず維持し、新しいモジュールからGen 2で書き始める段階的な進め方も取れます。両世代は併用できるため、移行コストと得られる保守性を比べて決めてください。
Amplify Gen 2を試すには何から始めればよいですか?
フロントエンドのプロジェクト直下でnpm create amplify@latestを実行すると、amplifyディレクトリとbackend.tsを含む4ファイルの雛形が置かれます。続けてnpx ampx sandboxを起動すれば自分専用のAWS環境へ反映され、接続情報がamplify_outputs.jsonに書き出されます。検証が終わったらnpx ampx sandbox deleteでリソースを片付けてください。
バックエンドではどのAWSサービスが動きますか?
認証はAmazon Cognito、データはAppSync(GraphQL)とDynamoDB、ファイル保存はS3、サーバー処理はLambdaが動きます。Amplifyはこれらを型安全にまとめる層で、独自の隠れた基盤を持つわけではありません。足りないサービスはAWS CDKを通じてSNSやSQSなどを追加でき、標準構成の延長として拡張できます。
どのフロントエンドフレームワークに対応していますか?
React、Vue、Angularといった主要なフレームワークに対応し、Amplify HostingはNext.jsやNuxtのSSR・SSGも配信できます。バックエンド連携用のライブラリaws-amplify(2026年9月時点で6.20系)はJavaScript系を中心に、iOSやAndroidのモバイル開発にも対応します。採用するフレームワークがSSRを使う場合は、SSRリクエストとSSR実行時間の料金を見積もりに含めてください。
関連記事
- AWS Amplify Hostingとは?料金・特徴とS3+CloudFrontとの違い:Amplifyのホスティング機能に絞って料金と他構成との違いを深掘りした記事
- サーバーレスとは?仕組み・メリットとコンテナとの使い分けを解説:Amplifyの土台にあるサーバーレスの判断軸を整理した上位概念の記事
- Amazon Cognitoとは?料金・できること・使い方を解説:AmplifyのAuthが作るユーザープールの料金と機能を単体で確認できる記事
- AWS Lambdaとは?仕組み・料金体系と採用判断を解説:AmplifyのFunctionsが動くLambdaの制約と料金を深掘り
- Amazon S3とは?仕組み・ストレージクラスと料金を解説:AmplifyのStorageが使うS3の仕組みと料金体系