AWS
AWS構成事例カタログ
金融 / 決済マルチリージョンLambda

金融決済プラットフォーム(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 で多層防御

システム構成図

プライマリリージョン (東京) — Activeセカンダリリージョン (大阪) — ActiveActiveActive認証イベント発行復旧トリガ認証イベント発行復旧トリガGlobal Tables 双方向レプリケーション (< 1秒)金融機関 / 決済利用者Route 53(Health Check / Failover)WAF + ShieldAPI GatewayCognito(OAuth 2.0)Lambda(決済マイクロサービス)SQS(イベントキュー)EventBridge(タイムアウト/復旧)S3(ISO20022 メッセージ)DynamoDB(取引台帳 / Global Table)WAF + ShieldAPI GatewayCognito(OAuth 2.0)Lambda(決済マイクロサービス)SQS(イベントキュー)EventBridge(タイムアウト/復旧)S3(ISO20022 メッセージ)DynamoDB(取引台帳 / Global Table)

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

監視・運用

CloudWatchCloudWatchCloudTrailCloudTrailAWS ConfigAWS ConfigSystems ManagerSystems Manager

セキュリティ・統制

IAMIAMGuardDutyGuardDutySecurity HubSecurity HubKMSKMS

配信・保護

Route 53Route 53WAFWAFShieldShield

バックアップ・DR

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

コピーしてすぐ使える IaC

金融決済プラットフォーム(ISO 20022 / マルチリージョン Active-Active)を再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。

typescript
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)は、超大規模(金融機関・決済事業者の基幹)を想定し、リージョン障害時の継続性を重視する場合に選びやすい構成です。

選定フロー

1

業務要件を確認する

決済で求められる可用性、RTO/RPO、データ分類を確認する。

要件に合う → 候補として採用不足がある → 上位の冗長化/統制構成を検討
2

運用体制を確認する

チームが AWS Native の運用、監視、権限管理を継続できるかを確認する。

運用可能 → 詳細設計へ負荷が高い → よりマネージドな代替案へ
3

コストと拡張性を比較する

月 500,000 円〜数百万円(規模・取引量に依存)を許容し、将来のスケールやDR要件に対応できるかを判断する。

許容できる → 本構成を採用過剰/不足 → 代替案を比較

代替案との比較

候補コスト運用保守負荷スケーラビリティ選定すべきケース
最小構成
低い単純だが手動復旧が多い限定的PoC、検証、小規模な開始段階
金融決済プラットフォーム(ISO 20022 / マルチリージョン Active-Active)採用
高いAWS標準運用で管理可能リージョン単位で拡張可能リアルタイム決済・送金システム(RTGS / 即時送金)
上位冗長化構成
高い設計・監視・訓練が増える高い厳格なSLA、DR、監査要件がある場合

採用時のトレードオフ

!

設計前提の確認が必要

記載のSLA/RTO/RPOは設計目標であり、実値は取引量・アプリ設計・テスト結果に依存する
!

コストと運用負荷のバランス

アーキテクチャ・運用ともに非常に高度で、設計/テストの難易度が高い

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

Amazon Cognito による OAuth 2.0 認証でAPIエンドポイントを保護
AWS WAF + Shield でDDoS・不正リクエストを防御
KMS による保存時・転送時の暗号化(鍵管理を一元化)
DynamoDBはイミュータブルな台帳設計で監査証跡(audit trail)を担保
ISO 20022 ステータスコードをメタデータとして保持し、取引追跡が可能

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

業務領域

決済

重要度

ミッションクリティカル(即時決済・無停止が要件)

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 メッセージングを扱う決済ハブ・清算機関
  • 無停止が求められる金融機関の勘定系周辺・決済基盤
金融決済ISO 20022マルチリージョンActive-Activeイベント駆動サーバーレス