AWS 学習記録①：S3・SQS・DynamoDBを組み合わせたイベント駆動型設計とInfrastructure ComposerによるIaC化
1. 構築したシステムの全体像
S3へのファイルアップロードを起点に、後続の処理を非同期で実行するサーバーレスアーキテクチャを構築しました。
- S3 (Source Bucket): ファイルアップロードを検知し、Lambdaへイベントを通知します。
- Lambda 1 (Producer): S3イベントを受け取り、メタデータをSQSキューに送信します。
- SQS: Lambda間の疎結合を実現するためのメッセージキューとして利用します。
- Lambda 2 (Consumer): SQSからメッセージを取得。SNSでのメール通知と、DynamoDBへの処理ログ書き込みを並列で実行します。
- SNS: 処理完了の通知をメールで送信します。
- DynamoDB: 実行ID、処理内容、実行者（Owner: kamata）、タイムスタンプを保存します。
2. 実装中に直面した技術的課題と解消法
IAM権限の適切な設定
Lambda 2からSNSおよびDynamoDBへのアクセス時に、権限不足（403 Forbidden）によるエラーが発生しました。
-
対応: 実行ロールに対して、
sns:Publishおよびdynamodb:PutItemの許可を含むアイデンティティベースポリシーをアタッチして解消しました。
分散システムのデバッグ（AWS X-Rayの活用）
複数のサービスを経由するため、処理がどこで止まっているかの特定に苦労しました。
-
対応: 各LambdaでX-Rayを有効化。トレースマップを確認することで、Lambda 2内部での
ValidationExceptionを特定しました。
DynamoDBのスキーマ整合性
DynamoDBへの書き込み時、テーブル定義のパーティションキー（ExecutionId）とプログラム内のキー名が一致せず、エラーとなっていました。
- 対応: X-Rayの例外メッセージから不足しているキーを特定し、コード側の辞書キーを修正して書き込みに成功しました。
3. Infrastructure ComposerによるIaCへの移行
コンソールでの手動構築後、保守性と再利用性を高めるために AWS Infrastructure Composer を使用してテンプレート化を行いました。
-
利点: キャンバス上でリソースを接続するだけで、サービス間の依存関係やIAMポリシーの雛形が組み込まれた
template.yaml（AWS SAM）が自動生成されます。 - 成果: 手動設定では漏れやすい「リソース間の権限設定」が可視化され、コードベースでの管理が容易になりました。
4. 今後の展望
今後は、この構成の入り口として API Gateway を追加し、Webインターフェースからの実行を可能にすること。また、Amazon Cognito による認証を追加し、セキュリティ面を強化する予定です。