金融 / 決済マルチAZECS/Fargate

クレジットカード決済処理プラットフォーム

API Gateway / MSK / ECS / Payment Cryptography によるリアルタイム決済処理

可用性 (SLA目標)

99.9% 以上（Multi-AZ + マネージドサービス冗長）

RTO（目標復旧時間）

数分（ECS再配置 + MSK/ECS冗長 + 手順化された切替）

RPO（目標復旧時点）

数秒〜数分（トピック保持・DynamoDB/Aurora設計に依存）

概算コスト

月 500,000 円〜（MSK・ECS・セキュリティ・監視を含む）

構成概要

可用性レベル: マルチAZ
コンピューティング: ECS/Fargate
想定システム規模: 大規模（毎秒数千件の決済トランザクション）
コスト感: ¥¥¥高コスト

使用AWSサービス

Amazon API Gateway
AWS WAF
Amazon Cognito
Amazon MSK
Amazon ECS / AWS Fargate
AWS Payment Cryptography
AWS Step Functions
Amazon DynamoDB
Amazon ElastiCache
Amazon Aurora
AWS KMS
AWS Secrets Manager
Amazon CloudWatch
AWS CloudTrail

概要

カード提示・非対面決済など複数チャネルからのオーソリゼーション要求を API Gateway で受け、Amazon MSK を中心に疎結合化したリアルタイム決済処理プラットフォームです。ECS/Fargate の処理コンテナが BIN チェック、リスクチェック、トークナイゼーション、業務ルール判定を実行し、AWS Payment Cryptography や KMS、DynamoDB、ElastiCache を組み合わせて PCI DSS を意識した低遅延・高スループットな処理を構成します。

★ 設計のポイント

▸API Gateway + WAF + Cognito でチャネル入口を保護し、許可された決済要求のみ受け付ける
▸Amazon MSK によるイベントストリーミングで、オーソリゼーション処理と外部ネットワーク連携を疎結合化
▸AWS Payment Cryptography / KMS / Secrets Manager でカード会員データと鍵管理を分離
▸ElastiCache でトークンや参照データを低遅延に取得し、DynamoDB/Aurora を用途別に使い分ける

システム構成図

周辺・運用機能（クロスカッティング / 全体に適用）

監視・運用

CloudWatch

CloudTrail

Systems Manager

セキュリティ・統制

WAF

Shield

KMS

Secrets Manager

Security Hub

決済処理

API Gateway

ECS

Step Functions

DynamoDB

バックアップ・監査

AWS Backup

AWS Config

リージョンVPCプライベートパブリック概念図 / アイコン: AWS Architecture Icons

コピーしてすぐ使える IaC

AWS ブログの決済処理リファレンスを、カタログ用に簡略化した構成です。実装時は PCI DSS スコープ、鍵管理、カードネットワーク接続方式、監査証跡を個別に設計してください。

AWS ブログ「AWSでのクレジットカード決済処理プラットフォームの構築」を設計元にした整理です。

この形式のテンプレートはインライン表示を省略しています。

この構成を選ぶ理由

決済要求を同期APIだけで処理せず、MSKで処理段を分離することで、ピーク負荷、再処理、外部ネットワーク遅延に強い構成にします。

代替案との比較

候補	コスト	運用保守負荷	スケーラビリティ	選定すべきケース
同期API + RDB中心	中	単純だがピーク時の詰まりが表面化しやすい	中	低TPSの社内決済・PoC
API + MSK + ECS採用	高	ストリーム運用が必要	高い	高TPS・リアルタイム・再処理性を重視するカード決済
フルサーバーレス	中	低い	高いが低遅延制御に制約	周辺決済APIや非同期イベント処理

採用時のトレードオフ

PCI DSS スコープ設計が最重要

カード会員データが通過するコンポーネントを減らし、トークン化と鍵分離で監査対象範囲を絞り込む必要があります。

MSK は運用設計が必要

パーティション設計、保持期間、遅延監視、再処理、メッセージ順序性を事前に決めないと、障害時の復旧が複雑になります。

🛡 セキュリティ・コンプライアンスのポイント

•PCI DSS を前提に、転送中/保存時暗号化、鍵分離、カード番号のトークン化を設計する

•WAF、Shield、API 認可、Secrets Manager、IAM 最小権限で入口と実行権限を多層防御する

•MSK は TLS、認証、トピック単位の権限、監査ログを有効化する

•CloudTrail / Config / Security Hub / GuardDuty で証跡、設定準拠、脅威検知を継続監視する

🏛 エンタープライズ設計観点・統制

業務領域

決済

プラットフォーム

AWS Native

重要度

ミッションクリティカル（カード決済オーソリゼーション）

DR方式

Multi-AZ 冗長（グローバル展開時はマルチリージョン拡張）

接続方式

インターネット公開 + PrivateLink / 閉域接続

データ分類

機密（カード会員データ / PCI DSS 対象）

✔ データ活用・統制の設計目標

•カード会員データをトークン化し、平文カード情報をアプリケーション層に残さない
•決済処理、鍵管理、監査、運用の権限を分離し、職務分掌を明確化する
•MSK トピック、DynamoDB、Aurora、S3 のデータ保持期間と削除証跡を定義する
•オーソリゼーション処理のレイテンシー、エラー率、拒否理由、再送を一元監視する

⚠ 前提条件・留意事項

•実際の PCI DSS 準拠範囲、鍵管理方式、カードネットワーク接続方式は事業者要件に応じて精査する
•レイテンシー目標はトークナイゼーション、外部ネットワーク応答、業務ルール数に依存する
•マルチリージョン化する場合は、二重処理防止、順序性、重複排除、整合性回復手順を別途設計する

✓ メリット

•MSK でピーク負荷を吸収し、処理段を疎結合化できる
•AWS Payment Cryptography と KMS で鍵管理と暗号処理をアプリから分離できる
•ECS/Fargate により処理機能ごとの独立スケールがしやすい
•API Gateway / WAF / Cognito でチャネル入口の保護を標準化できる

✗ デメリット

•PCI DSS、鍵管理、カードネットワーク接続の設計難易度が高い
•MSK、ECS、暗号処理、DB の横断監視が必要
•厳しいレイテンシー要件では外部ネットワークや暗号処理の遅延も含めた性能試験が必須

→ 主なユースケース

•加盟店・PSP・決済代行のオーソリゼーション基盤
•カード決済処理のクラウドモダナイゼーション
•高TPSの決済イベント処理・トークナイゼーション基盤

金融決済クレジットカードPCI DSSMSKECSPayment CryptographyDynamoDB

← 他の構成パターンを見る