はじめに

いかにもAIが考えたであろうタイトルはさておき、
既存のReactシステムに「業務メモ的なチャット機能」を埋め込みたいという要望がありました。

すでに稼働しているシステムへの追加実装であるため、以下の要件が求められました。

既存のAWSリソースには変更を加えず、別アカウントで構築する
既存のバックエンド・フロントエンドへの影響を最小限にする（フロントはコピペレベルで完結させたい）
汎用性の高い構成にして、今後別のシステムでも使えるようにする

てなわけで、完全に0からのAWS設計が必要となりました。
私にとってAWSの設計は初めての経験でしたが、今回はサーバーレス構成を採用したことで、AWS初心者として非常に多くの学びを得ることができました。（AWS設計入門の題材として最適すぎた）
本記事では、その設計過程と学んだことをまとめます。

最終的に作成した画面（component）

チャットはlambda経由でdynamodbに保存されます。

最初に検討した構成

最初はこんな構成を考えていました。

特徴

AppSync + GraphQL でリアルタイム通信（Subscription）
Apollo Client をフロントエンドで使用
WebSocket によるリアルタイム更新

なぜこの構成を検討したか

リアルタイムでメッセージが届く体験を提供したい（チャットなので）
AppSync の Subscription は WebSocket 接続を自動管理してくれる

構成を変更した理由

要件を改めて整理したところ、この構成はオーバースペックと判断しました。

要件の再整理

要件	優先度	備考
メッセージの送受信	必須	基本機能
リアルタイム通知	低	手動更新で十分（業務メモレベルなので）
導入の容易さ	高	コピペで導入できたらいいな
外部依存の最小化	高	使うシステムの package.json を汚したくない

AppSync 構成の課題

Apollo Client への依存
- ホストシステムに Apollo Client を追加する必要がある
- 「コピペで導入」はできなそう
- 導入を予定しているシステムではremixを使っていたので相性が悪そう
WebSocket 接続の管理
- 常時接続のコスト

最終的な判断

シンプルな REST API + 手動更新 で十分だと判断しました。

AppSync + GraphQL + Subscription
↓
API Gateway + Lambda + REST API

採用した構成

最終的に採用した構成がこちらです。

変更点

AppSync → API Gateway (REST)
Apollo Client → ネイティブ fetch
Subscription → 手動更新ボタン

採用した技術スタック

レイヤー	技術	選定理由
API	API Gateway (REST)	WAF対応、スロットリング内蔵、シンプル
認証	Lambda Authorizer	JWT検証を分離できる
Compute	Lambda	サーバーレスで運用負荷ゼロ
Database	DynamoDB (On-Demand)	スケーラビリティとコスト効率
Security	AWS WAF	アプリ層でのDDoS対策等
IaC	AWS CDK (TypeScript)	使いたかった

設計思想① Lambda Authorizer による認証分離

最初は、一つのLambdaで認証とAPIロジックを完結させようとしていました。
が、同期にアドバイスをもらい、認証とAPIロジックを分離するために Lambda Authorizer を採用しました。（APIGatewayに統合できるの知らなかった）

アーキテクチャ

メリット

認証で弾くべきリクエストがAPIロジックLambdaに到達しない
関心の分離（認証ロジック vs APIロジック）
認証結果をキャッシュできる（最大1時間？、同一トークンの再検証を省略）

設計思想② DynamoDB の Single Table Design

DynamoDB では Single Table Design を採用しました。

設計パターン

AdminChatTable（1つのテーブルに全エンティティ）
├── PK: MSG#{prefix}#{roomId}
└── SK: TS#{timestamp}#{uuid}

この設計のポイント

観点	設計意図
パーティションキー	データを論理的に分離。アクセスパターンに基づいて設計
ソートキー	タイムスタンプ順でソート可能に。末尾のUUIDで衝突を防止
TTL	古いデータを自動削除してコスト削減

なぜ Single Table Design か

1回のクエリで必要なデータを取得できる
アクセスパターンが明確になる（どのKeyでどんなデータを取るか）
運用がシンプル（テーブル1つだけ管理すればいい）

GSIも今回の要件的に必要なかったのでめちゃくちゃシンプルになっています。

ソートキーの衝突回避

TS#{timestamp}#{uuid} とすることで、ミリ秒単位の同時書き込みによるデータ消失（上書き）を防ぐ設計。

設計思想③ 環境分離（dev / prod）

必須ではありませんでしたが、本番運用を見据えて最初から環境分離を設計に組み込みました。

項目	dev	prod
WAF	なし	あり
CloudWatch Alarms	最小限	フル設定（Slack通知）
DynamoDB TTL	30日	2年
Point-in-Time Recovery	なし	あり
ログ保持期間	7日	1年

CDKではstageパラメータで分岐

// prod環境のみ監視設定を追加
if (stage === 'prod') {
  new ChatMonitoring(this, 'Monitoring', {
    ...
  });
}

開発中は余計なコストがかからないので🙆
環境ごとの設定差異がコードで明示されるので🙆

設計思想④ WAF による保護

本番環境では AWS WAF を導入しました。

設定したルール（一部抜粋）

ルール	設定値	目的
Rate Limit	2,000 req / 5分 / IP	DoS攻撃の緩和
Body Size	< 64KB	異常な巨大リクエストのブロック
AWS Managed Rules	Common Rule Set	一般的な攻撃パターンのブロック

学び WAF高い。（関係ない）

設計思想⑤ CloudWatch による監視

本番環境では障害を早期発見するために、CloudWatch Alarms を設定しました。

// Lambda エラーアラーム
new Alarm(this, 'LambdaErrorAlarm', {
  metric: handler.metricErrors({
    period: Duration.minutes(5),
    statistic: 'Sum',
  }),
  threshold: 5,
  evaluationPeriods: 1,
  comparisonOperator: ComparisonOperator.GREATER_THAN_THRESHOLD,
});

Amazon Q Developer in chat applications (旧称: AWS Chatbot) と連携して、Slackに通知が飛ぶようにしました。

コスト試算

100ユーザー規模での月額費用をGeminiに試算してもらいました。

サービス	月額費用 (USD)
API Gateway	$0.42
Lambda	$0.02
DynamoDB	$0.38
WAF	$5.07
CloudWatch	$0.05
合計	約 $6 / 月

WAFがほとんどを占めている。。他のサービスに関しては、ほんとか？ってぐらい安い。Geminiが嘘をついていたら私は誰も信用できなくなる。

苦労したこと

1. AppSync から REST API への方針転換

最初は「チャット出しリアルタイムがいいよな」と思って AppSync + Subscription で設計を進めていましたが、要件を整理し直したときに「別にリアルタイムじゃなくていいな」となりました。

結果的にはシンプルで導入しやすい構成になりました。

2. Lambda のコールドスタート

Lambda2台体制（認証、API）なので、初回リクエストの動作がどうしても遅い。。

対策

メモリを1024MBに設定（メモリ↑ = CPU↑）

メモリを増やすと単価は上がって高くなるのでは？と最初は疑問に思いましたが、処理時間が短縮されるため、結果的に総コストが安くなるケースもあるらしい（AWS Lambda Power Tuningの考え方）。今回は処理速度を優先して上げました。

まとめ

設計で意識したこと

オーバースペックを避ける - 要件に対して適切な技術選定
関心の分離 - Lambda Authorizer で認証とAPIロジックを分離
シンプルなデータ設計 - Single Table Design でアクセスパターンを明確に
環境分離 - dev/prod を最初から設計に組み込む
監視体制 - WAF/CloudWatch で本番運用を保護

振り返り

最初に検討した AppSync 構成も悪くはなかったですが、「本当にリアルタイム通信が必要か？」を改めて考えたことで、よりシンプルな構成にたどり着けました。

「技術的に高性能でイケてる」より「要件に対して適切か」を意識することの大切さを学びました。