金融決済プラットフォーム(ISO 20022 / マルチリージョン Active-Active)
イベント駆動・耐障害性重視の決済メッセージング基盤
可用性 (SLA目標)
99.999%(マルチリージョン Active-Active)
RTO(目標復旧時間)
ほぼ 0(両リージョンが同時に処理を継続)
RPO(目標復旧時点)
1秒未満(DynamoDB グローバルテーブル)
概算コスト
月 500,000 円〜数百万円(規模・取引量に依存)
構成概要
- 可用性レベル
- マルチリージョン
- コンピューティング
- Lambda
- 想定システム規模
- 超大規模(金融機関・決済事業者の基幹)
- コスト感
- ¥¥¥高コスト
使用AWSサービス
- Amazon Route 53
- AWS WAF / AWS Shield
- Amazon Cognito
- Amazon API Gateway
- AWS Lambda
- Amazon SQS
- Amazon EventBridge
- Amazon S3
- Amazon DynamoDB (Global Tables)
- AWS KMS
概要
AWSの金融サービス向けリファレンスアーキテクチャをベースにした、ISO 20022 決済メッセージを処理するマルチリージョン・アクティブ-アクティブ構成です。2つのリージョンが同時に稼働し、API Gateway + Lambda のサーバーレス・マイクロサービスで決済ワークフロー(受信・処理・リリース)を実行。DynamoDB グローバルテーブルにステータスを不変の台帳(ledger)として記録し、リージョン間で複製します。UPDATE/DELETE を避けたイミュータブル設計により、リージョン間の競合を回避しつつ取引の整合性を維持します。
★ 設計のポイント
- ▸2リージョン Active-Active。片方のリージョン障害でも無停止で継続
- ▸DynamoDB を不変台帳として扱い、UPDATE/DELETEを避けて競合を排除
- ▸API Gateway + Lambda + SQS/EventBridge による完全イベント駆動
- ▸Route 53 ヘルスチェックで、DNSコントロールプレーンに依存せず切替
- ▸Cognito(OAuth 2.0)/ WAF / Shield / KMS で多層防御
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
配信・保護
バックアップ・DR
コピーしてすぐ使える IaC
金融決済プラットフォーム(ISO 20022 / マルチリージョン Active-Active)を再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as apigw from "aws-cdk-lib/aws-apigateway";
import * as sqs from "aws-cdk-lib/aws-sqs";
import * as events from "aws-cdk-lib/aws-events";
import * as cognito from "aws-cdk-lib/aws-cognito";
import * as wafv2 from "aws-cdk-lib/aws-wafv2";
// 東京/大阪の Active-Active。DynamoDB Global Table で取引台帳を双方向複製します。
export class Iso20022PaymentsStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const ledger = new dynamodb.TableV2(this, "Ledger", {
partitionKey: { name: "txnId", type: dynamodb.AttributeType.STRING },
billing: dynamodb.Billing.onDemand(),
replicas: [{ region: "ap-northeast-3" }], // 大阪レプリカ
});
const queue = new sqs.Queue(this, "PaymentEvents");
new events.EventBus(this, "PaymentBus");
const fn = new lambda.Function(this, "PaymentSvc", {
runtime: lambda.Runtime.NODEJS_20_X,
handler: "index.handler",
code: lambda.Code.fromInline("exports.handler = async () => ({ statusCode: 200, body: 'ok' });"),
environment: { LEDGER: ledger.tableName, QUEUE_URL: queue.queueUrl },
});
ledger.grantReadWriteData(fn);
queue.grantSendMessages(fn);
const userPool = new cognito.UserPool(this, "ApiUsers");
const api = new apigw.RestApi(this, "PaymentApi");
const auth = new apigw.CognitoUserPoolsAuthorizer(this, "Auth", { cognitoUserPools: [userPool] });
api.root.addProxy({
defaultIntegration: new apigw.LambdaIntegration(fn),
defaultMethodOptions: { authorizer: auth, authorizationType: apigw.AuthorizationType.COGNITO },
});
new wafv2.CfnWebACL(this, "Waf", {
scope: "REGIONAL",
defaultAction: { allow: {} },
visibilityConfig: { cloudWatchMetricsEnabled: true, metricName: "paymentWaf", sampledRequestsEnabled: true },
rules: [{
name: "AWSCommon", priority: 1, overrideAction: { none: {} },
statement: { managedRuleGroupStatement: { vendorName: "AWS", name: "AWSManagedRulesCommonRuleSet" } },
visibilityConfig: { cloudWatchMetricsEnabled: true, metricName: "common", sampledRequestsEnabled: true },
}],
});
}
}この構成を選ぶ理由
金融決済プラットフォーム(ISO 20022 / マルチリージョン Active-Active)は、超大規模(金融機関・決済事業者の基幹)を想定し、リージョン障害時の継続性を重視する場合に選びやすい構成です。
選定フロー
業務要件を確認する
決済で求められる可用性、RTO/RPO、データ分類を確認する。
運用体制を確認する
チームが AWS Native の運用、監視、権限管理を継続できるかを確認する。
コストと拡張性を比較する
月 500,000 円〜数百万円(規模・取引量に依存)を許容し、将来のスケールやDR要件に対応できるかを判断する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
最小構成 | 低い | 単純だが手動復旧が多い | 限定的 | PoC、検証、小規模な開始段階 |
金融決済プラットフォーム(ISO 20022 / マルチリージョン Active-Active)採用 | 高い | AWS標準運用で管理可能 | リージョン単位で拡張可能 | リアルタイム決済・送金システム(RTGS / 即時送金) |
上位冗長化構成 | 高い | 設計・監視・訓練が増える | 高い | 厳格なSLA、DR、監査要件がある場合 |
採用時のトレードオフ
設計前提の確認が必要
コストと運用負荷のバランス
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
決済
重要度
ミッションクリティカル(即時決済・無停止が要件)
DR方式
マルチリージョン Active-Active(両リージョン常時処理)
接続方式
インターネット公開(API Gateway + WAF/Shield)+ 金融機関接続
データ分類
機密(決済・取引情報 / 個人情報を含みうる)
✔ データ活用・統制の設計目標
- •保存時・転送時の暗号化(KMSによる鍵の一元管理)を設計目標とする
- •イミュータブルな台帳設計により改ざん耐性のある監査証跡を確保する
- •OAuth 2.0 認証・WAF/Shield による多層防御と最小権限のアクセス制御
- •冪等性・再送・リコンサイル設計で取引の整合性を担保する
- •定期的なDR訓練・フェイルオーバー検証を運用前提とする
⚠ 前提条件・留意事項
- •記載のSLA/RTO/RPOは設計目標であり、実値は取引量・アプリ設計・テスト結果に依存する
- •Active-Activeは結果整合性を前提としたアプリ設計(競合回避)が成立していること
- •決済ネットワーク・関連法令への準拠は別途の評価・認可を要する
✓ メリット
- •両リージョンが同時稼働するため、リージョン障害でも実質無停止(RTOほぼ0)
- •イミュータブルな台帳設計でデータ競合と整合性問題を回避
- •サーバーレスで決済トランザクション量に応じて自動スケール
- •ISO 20022 標準準拠で、国際的な決済相互運用性に対応
- •WAF / Shield / Cognito / KMS による金融グレードのセキュリティ
✗ デメリット
- •アーキテクチャ・運用ともに非常に高度で、設計/テストの難易度が高い
- •両リージョン常時稼働のためコストが大きい
- •イベント駆動・結果整合性を前提としたアプリ設計が必要
- •決済特有の冪等性・再送・調整(リコンサイル)の作り込みが必須
→ 主なユースケース
- •リアルタイム決済・送金システム(RTGS / 即時送金)
- •ISO 20022 メッセージングを扱う決済ハブ・清算機関
- •無停止が求められる金融機関の勘定系周辺・決済基盤