Amplifyで初めてデプロイしてみた記録

デプロイ経験ゼロのフロントエンドエンジニアの初デプロイ記録

こんにちは、クラウドエンジニアのパクジュンハンです。
クラウドエンジニアという肩書きですが、実際の業務はフロントエンド開発が中心で、デプロイ経験もほぼない新卒エンジニアです。
この記事は、そんな自分が初めてデプロイに挑戦した記録です。

1. なぜAmplifyをとりあえずやってみたのか

何かやらないと、勉強しないと、と思いながら時間だけが過ぎている気がしていた。
なので今回は、「何も分からないけどとりあえずやってみよう」という気持ちで、まずはデプロイから始めることにした。

今回、個人プロジェクトを進める中で初めてフロントエンドのデプロイに挑戦することになり、そのツールとしてAWS Amplifyを選んだ。

2. AWS Amplifyとは？

まず単語の意味から見ると、Amplifyは「拡大する・増幅する」という意味を持っている。

AWS Amplifyは、

認証（Auth）
API
ストレージ
フロントエンドホスティング
CI/CD
環境分離

といった機能をまとめて提供していて、

→ インフラを一から構築しなくても
→ すぐにサービスとしてデプロイできるようにしてくれる

サービスだ。

まとめると、フロントエンドエンジニア向けのAWSベースのオールインワンなデプロイ・バックエンドサービスという理解でいいと思う。

3. どんな開発者向けのサービスか

個人的には、インフラの知識があまりないフロントエンドエンジニアにかなり向いていると感じた。

特に良かった点は：

個人プロジェクトならほぼコストを気にせず使える
トラフィックが増えてもAWS側でスケールしてくれる

コストについて実際に確認してみた。
Amplifyの無料枠基準で、毎月ビルド1,000分、データストレージ5GB、データ送信15GBが無料だ。
今回の翻訳アプリは自分だけが使う個人用アプリなのでビルド回数も少なく、トラフィックもほぼない。
確認時点では Amplify Hosting について発生した料金は $0 だった — 無料枠の範囲内で収まった。

ただし、このアプリではAmazon Bedrockも利用しているため、Bedrock経由のClaude推論料金は別途発生する。Amplify Hostingの料金とBedrockの料金は別項目

トラフィックのスケーリングについては、まだ個人用途なので大規模なトラフィックは経験していないが、
小規模チームや限られたユーザーを対象にしたアプリなら、Amplifyの自動スケーリングで十分カバーできそうだ。
逆にトラフィックが大きく増えそうな場合は、DAUのような単純な基準よりも、翻訳リクエスト数、SSRのリクエスト数・実行時間、データ転送量、Bedrockのinput/outputトークン数などを基準に、事前にコスト計算をしておくのが良いと感じた。

→ 「とりあえずデプロイしてみたい」という段階ではかなり選びやすいサービスだと思う。

4. メリット・デメリット（初心者目線）

メリット

デプロイがとにかく簡単
GitHub連携で自動デプロイできる
AWSの深い知識がなくても使える
個人開発との相性がいい

デメリット

インフラを細かくカスタマイズする自由度は低い
静的サイトやサーバーレス構成向き
複雑なバックエンドには向かない

ただ今回の目的は「デプロイ経験を得ること」で、フロント中心の個人プロジェクトなので、これらのデメリットはあまり問題にならなかった。

5. 他の選択肢（ざっくり）

サービス	特徴	デメリット
Vercel	Next.jsとの相性が最高、設定ほぼ不要	AWSとの連携が弱い
Netlify	静的サイトに強い	AWSとは別のエコシステム
S3 + CloudFront	自由度が高く本番構成に近い	設定が難しい

6. Amplifyを選んだ理由

AWS環境でのデプロイを経験してみたかった
インフラ設定に時間をかけたくなかった
フロントエンド中心の個人プロジェクトだった

完璧な選択というより、今の自分にちょうどいい選択という感じ。

7. 実際にAmplifyでデプロイしてみる

今回作ったのは日韓／韓日翻訳アプリ。
Next.js + Amazon Bedrock（Claude Haiku 4.5）を使って翻訳するWebアプリだ。

アプリ構成とAmplifyを選んだ理由

デプロイ方法を選ぶ前に、このアプリがどんな構成なのかを整理した。

【アプリ構成】
ブラウザ（入力）
    ↓
Next.js UI（画面レンダリング）
    ↓
Next.js API Route（サーバー処理）
    ↓
Amazon Bedrock（Claude Haiku 4.5）（翻訳実行）

この構成のポイントは、DBも、VPCも、独自サーバーもないという点だ。
Next.jsのAPI Routeがサーバー役を兼ね、外部API（Bedrock）を呼び出すだけで完結する。

→ この構成ならAmplify Hosting上でそのまま動作する。

ローカル vs Amplify 環境比較

【ローカル開発】
ブラウザ → Next.js UI → Next.js API Route → Amazon Bedrock（Claude Haiku 4.5）
                              ↑
                         .env.local
                   (BEDROCK_REGION, BEDROCK_MODEL_ARN などアプリ設定)
                              +
                    AWS CLI / SSO 認証情報
                    (Bedrock呼び出し用のAWS認証)

【Amplify デプロイ】
ブラウザ → Next.js UI → Next.js API Route → Amazon Bedrock（Claude Haiku 4.5）
                              ↑
                    Amplify Console 環境変数
              (BEDROCK_REGION, BEDROCK_MODEL_ARN などアプリ設定)
                              +
                    SSR Compute role
                    (一時的なAWS認証情報を提供)

アプリケーションコードは共通だが、AWS認証情報の取得方法が環境によって異なる。
ローカルではAWS CLIやSSO等の認証情報を利用し、Amplify上ではSSR Compute roleから提供される一時認証情報を利用する。

ローカルとAmplifyで違うのは「AWS認証情報の取得方法」であって、.env.localがIAM Roleの代わりになるわけではない。

プロジェクト準備

フレームワーク：Next.js 15（App Router）
パッケージマネージャ：pnpm
GitHubにpush済み
ローカルでは正常動作

特に追加の設定はせず、そのまま進めた。

Amplifyでアプリ作成

AWSコンソール → Amplify
「新しいアプリをホスト」
GitHub連携
リポジトリ選択

思ったよりかなり簡単で、UIも分かりやすかった。

補足： リポジトリが表示されなかったため、GitHub側でAmplifyのアクセス権を追加した。

ビルド設定 & 最初のエラー

Amplifyが自動でビルド設定を作ってくれるが、ここでエラー発生。

pnpm: command not found

最初はなぜpnpmが見つからないのか分からなくて調べてみたら、
Amplifyのデフォルトのビルドイメージにはnpmは事前インストールされているが、pnpmは含まれていないことが分かった。
そのため、ビルド前のフェーズで直接pnpmをインストールすれば良いと分かり、
以下のようにamplify.ymlに追加してテストしてみたらすぐエラーが解決できた：

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm install -g pnpm
        - pnpm install
    build:
      commands:
        - pnpm run build
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'
  cache:
    paths:
      - .next/cache/**/*
      - node_modules/**/*

APIキー管理 — Bedrock + IAM Role方式

このアプリはClaude APIをAnthropicに直接呼び出す方式ではなく、Amazon Bedrockを経由して使う方式で実装した。

最初はANTHROPIC_API_KEYを直接使う方式で実装しようとしていたが、会社のAWSアカウントにBedrockのApplication Inference Profileが用意されていたので、それを使う方向に変更した。

2つの方式の違い

	直接APIキー方式	Bedrock + IAM Role方式
認証	`ANTHROPIC_API_KEY`（秘密鍵）	IAM Role（長期Access Key不要）
セキュリティ	鍵漏洩リスクあり	アプリ側で長期固定のAccess Keyを管理する必要がない
管理	Secrets管理が必要	Role権限の設定
AWS環境	別途設定が必要	SSR Compute roleの作成・関連付けが必要

Bedrock + IAM Role方式は長期APIキーをアプリ側で管理しなくていい構造なので、Secrets管理より一段階安全な方式だ。AWS環境にデプロイする際はこの方式がベストプラクティスだ。

ただしAmazon Bedrockにアクセスするには、Amplify HostingのSSR Compute roleを作成し、アプリまたはブランチに関連付ける必要がある。「Amplifyが自動でIAM Roleを設定してくれる」だけだと、何も設定しなくてもBedrockへアクセスできるように見えてしまう。Roleを関連付けると、SDKが一時的なAWS認証情報を自動的に使用する。

実際のコード

import AnthropicBedrock from "@anthropic-ai/bedrock-sdk";

const client = new AnthropicBedrock({
  awsRegion: process.env.BEDROCK_REGION ?? "us-west-2",
});

長期Access Keyをコードに埋め込む必要はない。awsRegionを指定し、関連付けられたSSR Compute roleの権限をSDKが自動的に使用する。

ローカル開発環境

ローカルではAmplifyのSSR Compute roleを使えないため、役割を分けて設定する。

.env.local：Bedrockのリージョン、使用するモデルID / ARN、その他アプリケーション設定
AWS CLI / SSO等：Bedrockを呼び出すためのAWS認証情報

.env.localはAWS認証の代替ではない。

この.gitignoreの設定はcreate-next-appでプロジェクトを作成する際に自動で追加されるデフォルト設定だ。
Next.js側が最初から「envファイルはGitに上げないでください」というベストプラクティスを反映してくれている。

# .gitignore (create-next-appが自動生成)
.env*

# .env.local（ローカル専用、Git追跡除外）
BEDROCK_REGION=us-west-2
BEDROCK_MODEL_ARN=arn:aws:bedrock:...

Amplifyデプロイ環境

Amplifyでは.env.localがないため、コンソールで環境変数を登録する。

注意： Amplify HostingではAWSで始まる名前の環境変数は予約されているため、ConsoleからAWS_REGIONをユーザー定義環境変数として登録することはできない。Bedrockのリージョンはアプリ独自の変数で管理する。

Amplify Console → 環境変数
→ BEDROCK_REGION    : us-west-2
→ BEDROCK_MODEL_ARN : arn:aws:bedrock:...

ARNはAWSリソースの識別子に過ぎず、これだけではAPIを呼び出すことはできない。実際の認証はSSR Compute roleが担当するため、APIキーをSecretsで別途管理する必要がない。

Amplify環境変数とNext.js Runtime

Amplify Consoleに登録した環境変数はビルド処理では利用できるが、Next.jsのサーバー側Runtimeからprocess.envでそのまま参照できるとは限らない。

例えばBEDROCK_REGIONやBEDROCK_MODEL_ARNをAPI Routeから読みたい場合は、ビルド時点で値が注入されるよう設定する必要がある。必要に応じてamplify.ymlのビルドフェーズで.env.productionを生成する、あるいはNext.jsがビルド時にインラインできる形で環境変数を渡す、といった対応が必要になる。

注意： 上記の環境変数とSSR Compute roleを設定しないと、ビルドは成功してもAPIが動かない。

デプロイ完了

ビルドからデプロイ、URL発行まで自動で行われる。

https://xxxx.amplifyapp.com のようなURLが発行され、すぐアクセス可能。

→ 初めて「自分のプロジェクトがインターネット上に公開された」と実感した。

8. やってみて感じたこと

デプロイのハードルはかなり低い
初めてのデプロイ体験にはとても良い
ただし裏側の仕組みは見えにくい

なので、

→ 最初の一歩としては最適
→ インフラ理解には別の方法も必要

という印象だった。

デメリットについても実際に感じたことがある。
今回は素早くデプロイ経験を積むことが目的だったため、カスタマイズの自由度より手軽さを優先した。
今はAmazon Bedrock経由でClaudeを呼び出すシンプルな翻訳機能だけなのでAmplifyで十分だが、
今後、以下のような要件が中心になるとAmplifyだけでは物足りなくなる可能性がある。

VPCやネットワーク構成を細かく制御する必要がある
既存の複雑なバックエンド基盤との統合が中心になる
独自のコンテナ実行環境が必要
常駐ワーカーや重い非同期処理が中心
インフラ構成を細かく設計・管理する必要がある

逆に、DBや認証が必要になったからといってAmplifyが使えなくなるわけではない。
翻訳履歴の保存、ユーザーごとの利用回数制限、Google/GitHubソーシャルログインといった機能は、Amplify DataやAmplify Authを追加する選択肢もある。
ただしインフラを細かくカスタマイズする自由度が低い点は変わらないので、要件が大きくなったらS3 + CloudFrontやコンテナベースの構成への移行も検討できると感じた。

9. まとめ

今回は、デプロイ経験ゼロの新卒エンジニアがAWS Amplifyで初めてデプロイした記録。

経験者からすると簡単な内容かもしれないが、
自分にとっては「とりあえず一度デプロイできた」というだけでも大きな一歩だった。

次は、AmplifyではなくS3 + CloudFront構成にも挑戦してみたい。