• TOP
  • 記事一覧
  • Next.jsでAWS Amplifyを使ってPDFアップロード機能を実装、Fast APIにPOST（こちらはApp runner）

Next.jsでAWS Amplifyを使ってPDFアップロード機能を実装、Fast APIにPOST（こちらはApp runner）

更新日：2025/03/16

Next.jsプロジェクトをAmplifyにデプロイ

今いるディレクトリにNext.jsをセットアップ

npx create-next-app@latest ./

githubリポジトリ作成、httpsのURLを下記コードに張り付けてプッシュ

git remote add origin https://github.com/xxxx

shadcn/ui セットアップ

# shadcn/uiの初期化
npx shadcn@latest init

# 必要なコンポーネントをインストール
npx shadcn@latest add card
npx shadcn@latest add button
npx shadcn@latest add progress
https://github.com/idw-coder/amplify-form

AWSのAmplifyからGitHubを選択してデプロイ

AWS 1. ソースコードプロバイダーを選択 2. リポジトリとブランチを追加 3. アプリケーションの設定 4. 確認 Amplify を使用して構築を開始 アプリケーションをデプロイ GitHub BitBucket CodeCommit GitLab Amazon S3 または Zip ファイルからアプリケーションを手動でデプロイ Git なしでデプロイ ▶ テンプレートを使用して開始 Gen 1 ツール (Amplify Studio/Amplify CLI) でのアプリ構築をお考えですか？ 作る キャンセル
SSR・CSR・SSG レンダリング方式 SSR (Server-Side Rendering) クライアント ブラウザ Webサーバー Node.js等 データベース DB ①リクエスト ②データ取得 ③HTML生成 ④完成HTML サーバーでHTMLを完全に生成 SEO最適・初期表示高速 CSR (Client-Side Rendering) クライアント React/Vue等 静的サーバー JS/CSS配信 APIサーバー データ提供 ①JS取得 ②API 呼び出し ③DOM 更新 ブラウザでJSが実行されHTML生成 インタラクティブ・リアルタイム SSG (Static Site Generation) ビルド時 データ取得 HTML生成 静的ファイル化 CDN 静的配信 クライアント 即座に表示 デプロイ 高速配信 ビルド時に全ページを事前生成 最高速・SEO最適・低コスト 選択の ポイント 要件に応じて SSR適用: ECサイト、ニュース、SNS 初期表示速度重視 CSR適用: 管理画面、SPA、ダッシュボード インタラクション重視 SSG適用: ブログ、企業サイト、ドキュメント パフォーマンス最優先
問題点内容対処法
fs.writeFile が使えないLambda（Amplify）では /tmp 以外は書き込めない一時保存なら /tmp を使う
public/uploads/ に保存してもアクセスできないビルド時に固定化されるため、書き込み内容は見えないS3へアップロードする

temporary（テンポラリ）

S3にPDFをアップロード

[
{
"AllowedOrigins": ["http://localhost:3000", "https://your-domain.com"],
"AllowedMethods": ["GET", "PUT", "POST", "DELETE", "HEAD", "OPTIONS"],
"AllowedHeaders": ["*"],
"ExposeHeaders": ["ETag"],
"MaxAgeSeconds": 3600
}
]

Amplify に Next.js アプリをデプロイについて整理

そもそも通常のNode.jsサーバーにデプロイする場合（例：VPSやEC2）の場合

npm run build
npm run start

Node.js のサーバーを起動

⬇️

そのサーバーが SSR ページをリクエストごとに生成

→ つまり「SSR処理は常に自前のサーバーで処理してる」、アプリ全体が 1つのNodeプロセスで動いてる

Amplify に Next.js アプリをデプロイする場合（サーバーレス）

AmplifyはSSR/APIの必要な部分を切り出し、SSRページの処理を Lambda@Edge関数として個別に配置

ページアクセス時にそのLambdaが一時的に起動してSSRする

→ つまり「自前でNodeサーバーは立ち上がってない！必要なときだけLambdaで動く！」

実はVercelもAmplifyと同じ「サーバーレス型」ただし、VercelはNext.jsの「公式ホスティング」で、対応範囲がめちゃ広い
Middleware、Edge Functions、StreamingなどのNext.js最新機能に強い

Node.jsを使わずLambda（Amplify）だけでSSRする場合の制限事項

Lambda関数は書き込みできるのは /tmp のみのため、アップロードしたファイルをpublic/uploads保存に保存することはできません

/tmpについて

サーバー側のローカルディスク上の一時領域であって、

クライアント（ブラウザ）からアクセスできない！

/tmpに保存する場合

「保存したら外部に送りたい」って用途だったら、このまま /tmp に一時保存→送信→削除の流れにすればOK！

または保存せず、直接 POST でストリーム転送する方法もあるよ〜。

https://rv-response-blob.d3ux8uvxcvc13i.amplifyapp.com/

一般的＆シンプルにFastAPIをデプロイする方法（AWS編）

方法特徴メリットデメリット推奨ケース
Fargate (ECS)サーバレスコンテナ自由度高、常時稼働OK、運用楽初期設定やや多め標準的なAPI運用に◎
Lambda + API Gateway関数型APIスケーラブル、完全サーバレス起動遅い、制限多め軽量API・Webhook向け
EC2 + nginx仮想サーバ完全自由、チューニング可運用コスト・セキュリティ対応必要学習やがっつり運用
Amplifyフロント向けMBaaSCI/CD込み、簡単デプロイFastAPI非対応、裏でLambdaReact等との併用時のみ
App RunnerフルマネージドWebアプリ実行環境最速で公開、HTTPSも簡単実行コストやや高短期PoCやお試しに◎
Elastic BeanstalkPaaS型アプリ実行環境デプロイ簡単、監視付き古め、挙動が重いこともレガシー互換・お手軽運用
Fargate コンテナサーバレス FastAPIに最適 標準的、手堅く運用 Lambda λ サーバレス コールドスタートあり 短時間処理、Webhook App Runner + ECR コンテナ自動スケール Docker push で管理 Web API、軽量な本番 Amplify ! GUIで簡単 FastAPIは合わない フロント中心（SPA） EC2 普通の仮想マシン 自由だけど重い 本番でガッツリ制御 おすすめ FastAPI なら: 1. Fargate (王道) 2. App Runner (簡単) フロントなら: • Amplify 短時間処理: • Lambda 
# fastapi-apprunnerという名前の新しいディレクトリを作成します
mkdir fastapi-apprunner

# 作成したfastapi-apprunnerディレクトリに移動します
cd fastapi-apprunner

# venvという名前のPython仮想環境を作成します
python -m venv venv

# 作成したvenv仮想環境を有効化（アクティベート）します（LinuxやmacOSのシェルで使用）
source venv/bin/activate
# WindowsのPowerShellで仮想環境をアクティブ化するには、以下のコマンド
.\venv\Scripts\Activate
(venv) PS C:\ida_test\work\fastapi-apprunner> 

# FastAPIとUvicorn（ASGIサーバー）をインストールします
pip install fastapi uvicorn

# 現在の仮想環境にインストールされているパッケージとそのバージョンをrequirements.txtファイルに書き出します
pip freeze > requirements.txt

「venvでローカル実行もして、結局Dockerでも動かす」って、ちょっと二重構成っぽく見えますが、一般的な開発フローです

  • venvは開発のためのパワーツール（ローカルチェック）
  • Dockerはデプロイ用の本番対応パッケージ
venvで速く試す → 問題なさそう → Dockerでまとめてデプロイ

仮想環境（venv）がアクティブなまま docker buildします

docker build -t fastapi-apprunner .
docker run -p 8000:8000 fastapi-apprunner
https://github.com/idw-coder/fastapi-apprunner

App Runner デプロイ手順（GitHub 経由）

① GitHub と App Runner を接続する
AWS マネジメントコンソールへログイン

検索バーで「App Runner」と入力してサービスに移動

「Create service（サービスを作成）」をクリック

② ソースを指定する

ソースおよびデプロイ Info App Runner サービスのソースとそのデプロイ方法を選択します。 ステップ 1 ソースおよびデプロイ ステップ 2 構成を設定 ステップ 3 サービスを設定 ステップ 4 確認および作成 ソース リポジトリタイプ コンテナレジストリ コンテナレジストリに保存されているコンテナイメージを使用してサービスをデプロイします。 ソースコードリポジトリ ソースリポジトリに保存されているコードを使用してサービスをデプロイします。 プロバイダー コードリポジトリをホストするプロバイダーを選択します。 GitHub GitHub 接続 Info App Runner は、アカウントに「AWS Connector for GitHub」というアプリをインストールすることで、ソースコードをデプロイします。 このアプリは、メインの GitHub アカウントまたは GitHub 組織にインストールできます。 新規追加 リポジトリ ? ブランチ ?

ランタイムでDockerfileが指定できないので、下記の手順に変更

Dockerfile を元に AWS App Runner へデプロイ（ECR 経由）

App Runner + ECR + Dockerfile の組み合わせは、コンテナ化されたアプリケーションをAWSで簡単にデプロイ・運用するためのサーバーレスコンテナサービスです。

全体の流れ

  1. Dockerfileでアプリをコンテナ化
  2. ECRにDockerイメージをプッシュ
  3. App RunnerがECRからイメージを取得してデプロイ

AWS CLI をインストール

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html
DockerファイルでApp Runnerにデプロイ（ECR経由） Dockerfile アプリ ビルド ECR イメージ保存 取得 App Runner 自動デプロイ 公開 👤 シンプルな3ステップ： 1️⃣ Dockerfileでアプリをコンテナ化 2️⃣ ECR（Elastic Container Registry）にイメージを保存 3️⃣ App Runnerが自動でデプロイ・運用・スケーリング メリット： ⚡ サーバー管理不要 📈 自動スケーリング 💰 従量課金（使った分だけ）

インストールを確認

aws --version

出力例
aws-cli/2.27.26 Python/3.13.3 Windows/11 exe/AMD64

aws configureで

AWS コンソールで IAM ユーザー作成 & アクセスキー取得

許可を設定→「ポリシーを直接アタッチする」

  • AmazonEC2ContainerRegistryFullAccess
  • AWSAppRunnerFullAccess

上記でユーザー作成したら、アクセスキーを取得します

AWS Access Key ID [None]:     IAMで作成したアクセスキー（通常20文字）
AWS Secret Access Key [None]: 対応する秘密キー（40文字の長い文字列）
Default region name [None]:   ap-northeast-1
Default output format [None]: json

ECRリポジトリを作成

aws ecr create-repository --repository-name fastapi-apprunner --region ap-northeast-1

“repositoryUri”: “xxxxxxxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/fastapi-apprunner”,

上記をメモ

Docker を ECR にログイン

aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin xxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com


実行後
Login Succeeded

Docker イメージにタグをつける（ECR用）

docker tag fastapi-apprunner xxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/fastapi-apprunner

Docker イメージを ECR に push！

docker push xxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/fastapi-apprunner

App Runner のデプロイ

ECR アクセスロール

AppRunnerECRAccessRole

項目入力内容備考
サービス名fastapi-apprunner（など任意）英数字・ハイフンOK、スペースはNG
仮想CPU1 vCPUそのままでOK（選べるけど、軽量APIならこれで十分）
仮想メモリ2 GBこれも基本OK
環境変数任意（必要があれば ENV=prod など）無ければスキップでOK
ポート番号8080Dockerfileで CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"] にしてるならこれでOK！

FastAPIコード更新後の再デプロイ手順（App Runner × ECR）

ステップ1：Docker イメージを再ビルド

※ ソースコードのあるディレクトリで実行

docker build --no-cache -t fastapi-apprunner .

ステップ2：ECR用にタグを付ける

docker tag fastapi-apprunner xxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/fastapi-apprunner

ステップ3：ECR に push

※ ログインしてから push すること！

aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin xxxxxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com
docker push xxxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/fastapi-apprunner

ステップ4：App Runner 側で再デプロイ

  • AWS マネジメントコンソールにアクセス
  • App Runner → 対象のサービスを選択
  • 「デプロイ」タブを開く
  • [最新のイメージに再デプロイ] ボタンをクリック

※ オプション：
初回設定時に「ECRイメージの更新で自動デプロイを有効にする」設定にしておけば、pushしただけで自動反映されます。

新規記事

すべてを見る
人気記事ランキング
ピックアップ記事
話題のキーワードから探す