AWSで問い合わせフォーマットを作成（SAAハンズオントレーニング）
AWS SAAを受講予定なので、ハンズオントレーニングを兼ねてブログサイトの問い合わせフォームを作成してみました。
↓実際の問い合わせフォーム
備忘録も兼ねて詰まったポイントのみ記載しておきます。
全体構成
API Gateway、Lambda、DynamoDBを使ったサーバレスアーキテクチャとなります。
コストについても、個人利用の範囲ではほぼ無料で維持できそうです。
1. DynamoDBの設定
ここでは新規テーブルの作成を行うぐらいですが、下記に少し手間どりました。
（詰まったポイント）
- パーティションキーの文字列はLamda関数のコードに合わせます。
// DynamoDBに保存するアイテムを作成
const item = {
id: uuidv4(), // ユニークIDを生成
name: body.name,
email: body.email,
message: body.message,
subject: body.subject || '',
submittedAt: new Date().toISOString(),
};
ここの「id」の部分ですね。
例えばkeyという名前にするなら、パーティションキーにも「key」という名前を設定します。
あと作成されたテーブルデータは「項目を探索」の方から参照できます。
ダッシュボードとかテーブルの方ばかり見て、送信したデータが登録されず、悩んでいる時間がありました。。。
2. Lambda関数の作成
（詰まったポイント）
コードに関してはcommonJS形式で書くのが推奨されるようです。（Claudeの回答）
AWS Lambda環境との親和性:
AWS Lambdaは伝統的にCommonJS形式で設計されており、デフォルトの実装例やドキュメントもすべてCommonJS形式です
Lambda環境は長年CommonJSをサポートしてきたため、安定性と互換性が高いです
AWS SDKとの互換性:
AWS SDKは主にCommonJS形式を想定して開発されています
特に古いバージョンのAWS SDKでは、ES Modulesでの使用時に予期しない問題が発生することがあります
依存ライブラリとの互換性:
LambdaでよくCDKを使った場合に含まれる多くの依存ライブラリ（例：uuid）はCommonJS形式を前提としていることが多いです
ES Modulesで使う場合、インポート方法を調整する必要がある場合があります
シンプルさと保守性:
Node.jsの世界ではまだCommonJSが広く使われており、多くの開発者にとって馴染みがあります
実装方法がシンプルで、トラブルシューティングも容易です
下手にmjs（ESmodules）形式に直したりしていたので、再修正が必要となりました。
3. API Gatewayのセットアップ
（詰まったポイント）
ここではフロントエンド（Next.js）側のリソースパスの設定が抜けており、時間を要しました。
<.env.local>
NEXT_PUBLIC_CONTACT_API_URL="https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/prod/contact"
最後に「/contact」が必要となります。
AWSのAPI Gateway→「ステージ」の画面でURLをコピーすると、「/contact」がついてきません。。。
4. 問い合わせフォームの作成
完成画面はこんな感じです。
今回はどちらかというと1～3の設定の方がより重要だったので、
Claudeで出力してもらったものをそのまま使用しています。
まとめ
API Gateway、Lambda、DynamoDBはSAA試験にも頻出のサービスと思いますので、今回のハンズオントレーニングで中身の理解がだいぶ進んだと思います。
満足できる内容となりました。
Discussion