AWS

Amplify基本知識 Amplifyとは サーバーレスなアプリケーションの効率的な開発が可能なフレームワーク サーバーレスということで、基盤となるサーバー、ミドルウェアをAWSが行う、「バックエンドをAPI化」するイメージ Gen1とGen2 Gen1 Amplify CLIで対話的に実行 現在はGen2で新規作成が推奨ですが、作成自体はまだ可能です Gen2（Gen2は2024年5月～） 対話形式からCDK方式になりました TypeScriptでAmazon DynamoDBやAWS AppSyncなど記述が可能に 例 // amplify/auth/resource.ts import { defineAuth } from '@aws-amplify/backend'; export const auth = defineAuth({ loginWith: { email: true, }, }); https://docs.amplify.aws/react/ チュートリアル https://github.com/aws-samples/amplify-vite-react-template ブートストラップが原因でビルド失敗 ビルド失敗Bootstrap stack version parameter failed to load. 原因Amplify Gen2がCDKを使用CDKの事前準備（ブートストラップ）が未実行または不完全 対応方法bashcdk bootstrap aws://アカウントID/リージョン CloudShellエラーが発生エラー内容 「環境を作成できません」 VPCまたはパブリック環境を作成するための権限が不十分 環境が既に存在しない可能性 対処法 ポリシー名必要な理由AdministratorAccess-AmplifyAmplifyアプリの作成・管理・デプロイに必要AmazonBedrockFullAccessAI機能（文章生成・要約等）でBedrockを使用AmazonS3FullAccess音声ファイルのアップロード・保存に必要AmazonTextractFullAccess文書のOCR・テキスト抽出機能で使用AmazonTranscribeFullAccess音声の文字起こし機能で使用CloudWatchLogsReadOnlyAccessCloudWatch → ログ → ロググループ にアクセスできるようになりますIAMFullAccessCDK Bootstrapでロール・ポリシー作成に必要CDKがLambda実行ロール作成時に、S3・Transcribe・Bedrock等へのアクセス権限を付与するため※Next.jsのAPIルート（/api/transcribe/upload）はLambda関数として実行CloudFormationFullAccessCDKCDK Bootstrap時CDKスタック作成npx ampx pipeline-deployがAmplifyサービス経由で実行（ユーザーは直接CloudFormation等を呼ばない）AmazonEC2ContainerRegistryFullAccessCDK Bootstrap時ECRリポジトリ作成npx ampx pipeline-deployがAmplifyサービス経由で実行（ユーザーは直接CloudFormation等を呼ばない）AmazonSSMFullAccessCDKBootstrap時SSMパラメータ作成npx ampx pipeline-deployがAmplifyサービス経由で実行（ユーザーは直接CloudFormation等を呼ばない） https://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/build-settings.html https://www.youtube.com/watch?v=870qwL5hbjI&amp;t=169s https://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/troubleshooting-general.html アップロードサイズ制限 AWS Lambdaは6MB制限 はNext.js: デフォルト1MB 大きなサイズのファイルアップロードは通常のAPI経由では処理不可能です。 対処法 A) Presigned URL（PUT） AWS S3に直接アップロードする最も一般的な方法です。 S3 は通常 IAM ユーザーのみ利用可能ですが、サーバー側で一時的に有効な署名付きURLを発行し、認証情報（AWSのアクセスキーやシークレットキー）を直接公開せずに、クライアントがそのURLにファイルを送信します。 APIやLambdaのサイズ制限を回避でき、セキュアかつ大容量ファイルに対応可能です。Next.jsや他フレームワークでも広く採用される標準的な構成です。 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html ブラウザ → API (Presigned URL取得) → 直接S3アップロード → Transcribe YouTube: 直接Google Cloud Storage Zoom: 直接S3アップロード Spotify: 直接S3アップロード npm install @aws-sdk/s3-request-presigner B) Amplify Storage（uploadData） Amplifyを利用する場合に最短で導入できる方法です。uploadData を呼ぶだけでブラウザから直接S3にアップロードでき、進捗イベントや中断・再開などの機能も標準で利用可能です。複雑な署名URL処理やCORS設定を意識せずに済み、Amplify中心の開発環境では実装効率が高いのが特長です。 Presigned URLを内部的にAmplifyが処理してくれる npm i aws-amplify @aws-amplify/storage npx ampx sandbox [対応が必要な場合があります] AWS Amplify は、2025 年 9 月 15 日をもって Node.js 14/16/18 ベースのアプリのサポートを終了します | [Action may be required] AWS Amplify End of Support for Node.js 14/16/18 based apps on September 15, 2025 見出しのメールが来ていて、どうやら 9/15で AWS AmplifyがNode.js 14/16/18のサポートを終了となるようです Node.jsのバージョンアップ方法 Amazon Linux 2023 ビルドイメージを使用している場合 参考記事 Amazon Linux 2023 ビルドイメージを使用している場合、Node.js バージョン 20 はデフォルトでサポートされています。2025 年 9 月 15 日以降、AL2023 イメージは自動的に Node.js 22 をサポートし、デフォルトの Node.js バージョンを 18 から 22 に変更します。 つまりビルドイメージが「Amazon Linux 2023」であれば勝手にNode.jsのバージョンをあげてくれるようです。 ビルドイメージは「ホスティング」→「ビルドの設定」から確認できます。 ビルドの設定のamplify.ymlで変更する場合 version: 1 frontend: phases: preBuild: commands: - nvm install 20 - nvm use 20 - node -v - npm ci --cache .npm --prefer-offline とするとビルドログでnode v20が使用されていることを確認できました。 2025-08-15T00:58:50.745Z [INFO]: ## Completed Backend Build {&quot;backendDuration&quot;: 0} ## Starting Frontend Build # Starting phase: preBuild # Executing command: nvm install 20 2025-08-15T00:58:51.190Z [INFO]: Downloading and installing node v20.19.4... 私の場合amplify.ymlで変更して対応したのですが、のちほどビルドイメージを確認したら「Amazon Linux 2023」だったので、対応は不要だったようです、、、 ですので、下記は後程削除して問題ないと思うので、ステージングブランチで確認してみようと思います commands: - nvm install 20 ← 削除 - nvm use 20 ← 削除 - nvm use 20 ← 確認用で、残してもいい - nvm use 20 ← このコマンドはビルド高速化のため必須 https://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/troubleshooting-general.html#update-node-version ログの確認 log-checkダウンロード https://rindev.site/blog/wp-content/uploads/2025/08/log-check.pdf 最初の処理が遅れるのはLambdaのコールドスタートが原因？ 環境とコードをセットアップする最初の 2 つのステップは、しばしば「コールドスタート」と呼ばれます。Lambda が関数の準備に要する時間は課金されませんが、全体的な実行時間に対して遅延を及ぼします。 実行が完了すると、実行環境はフリーズされます。リソース管理とパフォーマンスを向上させるために、Lambda サービスは実行環境を不特定期間保持します。この間、同じ関数に対する追加のリクエストが到着すると、サービスは環境を再利用するよう試みます。通常、この 2 番目のリクエストはより迅速に終了します。これは、実行環境がすでに存在し、コードをダウンロードして初期化コードを実行する必要がないためです。これは「ウォームスタート」と呼ばれます。 コールドスタートとレイテンシーを理解するhttps://aws.amazon.com/jp/blogs/news/operating-lambda-performance-optimization-part-1

AWS Transcribeの料金が想定より高額になった件

CloudWatchでエラーログの確認方法

AmplifyでNext.jsをデプロイしたときの備忘録