サーバーレス実装
API Gateway + Lambda + DynamoDBで問い合わせAPIを作る流れ
問い合わせフォームをサーバーレスAPIで保存する流れを、フロントエンドからDynamoDB保存まで整理します。
公開日：2026-06-07/更新日：2026-06-07/著者：AWS Cert Roadmap Lab
#API Gateway#Lambda#DynamoDB#Contact Form#Serverless
静的サイトでも、問い合わせフォームのようなユーザー入力は保存先が必要です。このサイトでは、API Gateway + Lambda + DynamoDBで問い合わせAPIを構成します。
結論
フロントエンドがPOST /contactを呼び、API GatewayがLambdaを起動し、Lambdaが入力値を検証してDynamoDBに保存します。
全体フロー
- ユーザーが問い合わせフォームに入力する
- フロントエンドで必須チェックとメール形式チェックを行う
- API GatewayのPOST /contactへJSONを送信する
- LambdaがリクエストBodyをパースする
- honeypotを確認する
- Lambda側でもバリデーションする
- DynamoDBへPutItemする
- 成功レスポンスを返す
- フロントエンドで完了メッセージを表示する
なぜフロントだけで検証しないのか
フロントエンドのチェックはユーザー体験をよくするためのものです。セキュリティ上は信用できません。
APIに直接リクエストされる可能性があるため、Lambda側でも必須項目、文字数、メール形式、honeypotを確認します。
DynamoDBに保存するデータ
保存する項目は、contactId、createdAt、name、email、subject、message、sourcePage、status、userAgentなどです。
ただし、CloudWatch Logsにはメールアドレス全文や本文全文を出しません。ログにはrequestId、contactId、エラー種別など、調査に必要な最小情報だけを出します。
CORSの扱い
本番では許可Originを本番ドメインに限定します。開発環境のlocalhostは開発時だけ許可します。
CORSを * にして本番運用するのは避けます。
この構成のメリット
- EC2を使わない
- サーバー管理が不要
- 低頻度アクセスなら低コストにしやすい
- AWS資格で学ぶ主要サービスを実装で使える
- ポートフォリオで設計意図を説明しやすい
関連用語
次に読む記事
次に学ぶ内容
ブログ記事だけでなく、AWS用語集・サービス比較・模擬問題・構成図を組み合わせると、資格知識と実装イメージをつなげて理解できます。