勘定系(コアバンキング)リファレンスアーキテクチャ
ECS × Aurora Global Database による Warm Standby マルチリージョン勘定系
可用性 (SLA目標)
ミッションクリティカル(リージョン障害に耐える Warm Standby)
RTO(目標復旧時間)
約5分以内(ARC + Step Functions による自動切替)
RPO(目標復旧時点)
数秒(Aurora Global Database / 通常1秒以内のレプリケーション)
概算コスト
規模依存(基幹システムとして数百万円〜/月)
構成概要
- 可用性レベル
- マルチリージョン
- コンピューティング
- ECS/Fargate
- 想定システム規模
- 超大規模(銀行の基幹・勘定系システム)
- コスト感
- ¥¥¥高コスト
使用AWSサービス
- Amazon ECS
- Amazon Aurora Global Database
- Amazon DynamoDB (Global Tables)
- AWS Transit Gateway
- AWS Direct Connect
- Elastic Load Balancing
- Amazon Route 53 Application Recovery Controller
- AWS Step Functions
- Amazon CloudWatch (Synthetics / Application Signals)
- AWS Backup
- Amazon EventBridge
概要
AWSが公開する金融機関向けベースライン環境(baseline-environment-on-aws-for-financial-services-institute)の勘定系リファレンスアーキテクチャをベースにした構成です。預金・為替・融資といった勘定系業務を、東京リージョン(Primary)と大阪リージョン(Secondary / Warm Standby)のマルチリージョンで構成。全銀・統合ATM・ANSER・CAFIS等の外接システムや営業店・銀行端末を Direct Connect / Transit Gateway 経由で接続し、Amazon ECS 上のマイクロサービス(残高照会・取引・取引カウント管理)が処理を担います。データは Aurora Global Database(リージョン間を通常1秒以内で複製)と DynamoDB グローバルテーブルで保持し、リージョン障害時は Application Recovery Controller と Step Functions により約5分以内に大阪へ自動フェイルオーバーします。
★ 設計のポイント
- ▸東京=Primary / 大阪=Secondary の Warm Standby 構成。オレゴンを監視に利用
- ▸Aurora Global Database でリージョン間を通常1秒以内に複製、目標RTO約5分
- ▸DynamoDB グローバルテーブルで状態管理を多リージョン同期(切替不要)
- ▸ECS マイクロサービス + CloudWatch サイドカーでコード変更なしの分散トレーシング
- ▸運用系 / CI/CD / 情報系 をマルチアカウントで分離した統制設計
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
CI/CD・統制
DR・自動化
コピーしてすぐ使える IaC
勘定系(コアバンキング)リファレンスアーキテクチャを再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as ec2 from "aws-cdk-lib/aws-ec2";
import * as ecs from "aws-cdk-lib/aws-ecs";
import * as elbv2 from "aws-cdk-lib/aws-elasticloadbalancingv2";
import * as rds from "aws-cdk-lib/aws-rds";
// 東京=Primary / 大阪=Warm Standby。外接系・営業店は Direct Connect + Transit Gateway で閉域接続。
export class CoreBankingStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const vpc = new ec2.Vpc(this, "Vpc", { maxAzs: 2, natGateways: 1 });
// 閉域接続:Transit Gateway(Direct Connect Gateway 経由でオンプレ/外接系と接続)
const tgw = new ec2.CfnTransitGateway(this, "Tgw", { description: "core-banking-reference-tgw" });
new ec2.CfnTransitGatewayAttachment(this, "TgwAttach", {
transitGatewayId: tgw.ref,
vpcId: vpc.vpcId,
subnetIds: vpc.selectSubnets({ subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS }).subnetIds,
});
// 内部 ALB(インターネット非公開)配下に ECS Fargate の勘定系マイクロサービス
const cluster = new ecs.Cluster(this, "Cluster", { vpc });
const taskDef = new ecs.FargateTaskDefinition(this, "Task", { cpu: 1024, memoryLimitMiB: 2048 });
taskDef.addContainer("app", { image: ecs.ContainerImage.fromRegistry("public.ecr.aws/nginx/nginx:stable"), portMappings: [{ containerPort: 80 }] });
const svc = new ecs.FargateService(this, "Service", { cluster, taskDefinition: taskDef, desiredCount: 3 });
const alb = new elbv2.ApplicationLoadBalancer(this, "InternalAlb", { vpc, internetFacing: false });
alb.addListener("Http", { port: 80 }).addTargets("App", { port: 80, targets: [svc] });
// Aurora Global Database(リージョン間レプリケーション。Warm Standby を大阪に保持)
new rds.DatabaseCluster(this, "Aurora", {
engine: rds.DatabaseClusterEngine.auroraPostgres({ version: rds.AuroraPostgresEngineVersion.VER_16_1 }),
writer: rds.ClusterInstance.provisioned("writer"),
vpc,
storageEncrypted: true,
});
// NOTE: rds.CfnGlobalCluster と DynamoDB Global Table、Route 53 ARC / Step Functions による自動切替を追加します。
}
}この構成を選ぶ理由
勘定系(コアバンキング)リファレンスアーキテクチャは、超大規模(銀行の基幹・勘定系システム)を想定し、リージョン障害時の継続性を重視する場合に選びやすい構成です。
選定フロー
業務要件を確認する
勘定系で求められる可用性、RTO/RPO、データ分類を確認する。
運用体制を確認する
チームが AWS Native の運用、監視、権限管理を継続できるかを確認する。
コストと拡張性を比較する
規模依存(基幹システムとして数百万円〜/月)を許容し、将来のスケールやDR要件に対応できるかを判断する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
最小構成 | 低い | 単純だが手動復旧が多い | 限定的 | PoC、検証、小規模な開始段階 |
勘定系(コアバンキング)リファレンスアーキテクチャ採用 | 高い | AWS標準運用で管理可能 | リージョン単位で拡張可能 | 銀行の勘定系(預金・為替・融資)のクラウド移行・モダナイゼーション |
上位冗長化構成 | 高い | 設計・監視・訓練が増える | 高い | 厳格なSLA、DR、監査要件がある場合 |
採用時のトレードオフ
設計前提の確認が必要
コストと運用負荷のバランス
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
勘定系
重要度
ミッションクリティカル(銀行の基幹業務)
DR方式
マルチリージョン Warm Standby(ARC + Step Functions で自動切替)
接続方式
Direct Connect + Transit Gateway による閉域接続(外接系・営業店)
データ分類
機密(勘定・取引・顧客情報)
✔ データ活用・統制の設計目標
- •Direct Connect 閉域接続でインターネットを経由しない通信経路を確保する
- •AWS Backup の Vault Lock による不変バックアップでランサムウェア対策を図る
- •CloudTrail / Config による監査証跡と構成変更の継続的記録
- •運用・CI/CD・情報系のマルチアカウント分離で職務分離と最小権限を実現する
- •ARC + Synthetics Canary による信頼性の高いフェイルオーバー判断とDR訓練
⚠ 前提条件・留意事項
- •目標RTO約5分・RPO数秒は設計目標であり、実値はデータ量・切替手順・訓練結果に依存する
- •勘定系特有の締め処理・整合性・冪等性の作り込みが完了していることを前提とする
- •金融機関のシステム要件・監督指針への適合性は別途の評価を要する
✓ メリット
- •リージョン障害でも約5分以内に大阪へ自動フェイルオーバー(Warm Standby)
- •Aurora Global Database / DynamoDB グローバルテーブルで広域のデータ整合性を確保
- •ECSマイクロサービス化で、勘定系を段階的にモダナイズできる
- •AWS Backup の不変バックアップでランサムウェア対策に対応
- •運用・CI/CD・情報系のマルチアカウント分離で統制とセキュリティを両立
✗ デメリット
- •金融基幹システムとして最高難度。設計・移行・テストの負荷が非常に大きい
- •Warm Standby 分のリソースと専用線が常時必要でコストが大きい
- •勘定系特有の整合性・冪等性・締め処理などの作り込みが必須
- •規制対応・監査・DR訓練など継続的な運用ガバナンスが求められる
→ 主なユースケース
- •銀行の勘定系(預金・為替・融資)のクラウド移行・モダナイゼーション
- •ミッションクリティカルな金融基幹システムのDR/BCP
- •マイクロサービス化を前提とした次世代バンキング基盤