fsi-banking-core

Files (154)

• SKILL.md
• SKILL_ja.md
• cdk-nag-test.template.ts · assets/
• db_architecture.png · assets/images/
• db_architecture_dsql.png · assets/images/
• monitering_auto_failover.png · assets/images/
• multilocaton_multiregion_architecture.png · assets/images/
• overview.png · assets/images/
• overview_dsql.png · assets/images/
• SECURITY_NOTICE.md · assets/sample-cdk/
• bleafsi-guest-core-banking-sample.ts · assets/sample-cdk/bin/
• parameter.ts · assets/sample-cdk/bin/
• cdk.json · assets/sample-cdk/
• jest.config.js · assets/sample-cdk/
• bleafsi-core-banking-monitoring-stack.ts · assets/sample-cdk/lib/monitoring/
• backup.ts · assets/sample-cdk/lib/primary/
• bleafsi-core-banking-primary-stack.ts · assets/sample-cdk/lib/primary/
• build-container.ts · assets/sample-cdk/lib/primary/
• aurora-restore-lambda.ts · assets/sample-cdk/lib/primary/cyber-resilience/
• aurora-status-lambda.ts · assets/sample-cdk/lib/primary/cyber-resilience/
• guardduty-eventbridge.ts · assets/sample-cdk/lib/primary/cyber-resilience/automated-isolation/
• isolation-lambda.ts · assets/sample-cdk/lib/primary/cyber-resilience/automated-isolation/
• isolation-stack.ts · assets/sample-cdk/lib/primary/cyber-resilience/automated-isolation/
• isolation-handler.py · assets/sample-cdk/lib/primary/cyber-resilience/automated-isolation/lambda/
• requirements.txt · assets/sample-cdk/lib/primary/cyber-resilience/automated-isolation/lambda/
• sns-notification.ts · assets/sample-cdk/lib/primary/cyber-resilience/automated-isolation/
• types.ts · assets/sample-cdk/lib/primary/cyber-resilience/automated-isolation/
• cyber-resilience-restore.ts · assets/sample-cdk/lib/primary/cyber-resilience/
• data-bunker-account.ts · assets/sample-cdk/lib/primary/cyber-resilience/
• dynamodb-restore-lambda.ts · assets/sample-cdk/lib/primary/cyber-resilience/
• dynamodb-status-lambda.ts · assets/sample-cdk/lib/primary/cyber-resilience/
• iam-backup-service-role.ts · assets/sample-cdk/lib/primary/cyber-resilience/
• restore-step-functions.ts · assets/sample-cdk/lib/primary/cyber-resilience/
• db-aurora-pg-global-primary.ts · assets/sample-cdk/lib/primary/
• db-dynamoDb-global.ts · assets/sample-cdk/lib/primary/
• ecr.ts · assets/sample-cdk/lib/primary/
• nlb-only-for-test.ts · assets/sample-cdk/lib/primary/
• primary-container-app-sample.ts · assets/sample-cdk/lib/primary/
• private-hosted-zone.ts · assets/sample-cdk/lib/primary/
• bleafsi-core-banking-secondary-stack.ts · assets/sample-cdk/lib/secondary/
• db-aurora-pg-global-member.ts · assets/sample-cdk/lib/secondary/
• secondary-container-app-sample.ts · assets/sample-cdk/lib/secondary/
• application-signals-config.ts · assets/sample-cdk/lib/shared/
• application-signals-monitoring.ts · assets/sample-cdk/lib/shared/
• application-signals-parameter.ts · assets/sample-cdk/lib/shared/
• associate-vpc-with-zone.ts · assets/sample-cdk/lib/shared/
• aurora-cluster.ts · assets/sample-cdk/lib/shared/
• constants.ts · assets/sample-cdk/lib/shared/
• container-app-sample-base.ts · assets/sample-cdk/lib/shared/
• cross-region-ssm-param.ts · assets/sample-cdk/lib/shared/
• key-app.ts · assets/sample-cdk/lib/shared/
• monitor-alarm.ts · assets/sample-cdk/lib/shared/
• app-client-vpc.ts · assets/sample-cdk/lib/shared/sample-multi-region-app/
• app-client.ts · assets/sample-cdk/lib/shared/sample-multi-region-app/
• app.ts · assets/sample-cdk/lib/shared/sample-multi-region-app/
• automatic-switch-state-machine.ts · assets/sample-cdk/lib/shared/sample-multi-region-app/
• handler.ts · assets/sample-cdk/lib/shared/sample-multi-region-app/aws-sdk-region-proxy/
• bleafsi-core-banking-arc-stack.ts · assets/sample-cdk/lib/shared/sample-multi-region-app/
• bleafsi-core-banking-statemachine-stack.ts · assets/sample-cdk/lib/shared/sample-multi-region-app/
• canary.ts · assets/sample-cdk/lib/shared/sample-multi-region-app/
• …and 94 more

SKILL.md (first lines)

# FSI Core Banking (勘定系) Reference Architecture

## Workload Overview

A **core banking system (勘定系, "kanjōkei")** handles a bank's fundamental
business operations — deposits, domestic/foreign exchange, and lending. It is
the most mission-critical system a financial institution operates: any outage
directly translates into a business stoppage, and any data inconsistency in a
financial transaction is unacceptable.

This skill captures the AWS reference architecture for such a workload from the
"Financial Reference Architecture Japan Edition" (BLEA for FSI). Its purpose is
to help SAs and architects design, review, and deploy a core banking workload
that satisfies the stringent availability, data-consistency, and disaster-recovery
requirements of Japanese financial institutions.

Key business drivers:

- **Extreme availability** — minimize annual downtime, including planned outages;
  survive large-scale regional disasters and continue operating.
- **Strong data consistency** — no tolerance for inconsistent financial data,
  even during failover or recovery.
- **Regulatory alignment** — demonstrable mapping to FISC 安全対策基準 (Security
  Guidelines, 13th edition) practical standards.
- **Cyber resilience** — ransomware-resistant, immutable backups and automated
  isolation/recovery.

Although modeled on core banking, the architecture is a **general-purpose pattern
for any highly available, mission-critical workload**. Scope is the core banking
domain only; channel and information systems are out of scope. See
`references/architecture.md` for full detail.

## Best Practices and Key Components

### Best Practices

- MUST: deploy in a **multi-region warm-standby** configuration, accounting for
  latency and data consistency (primary = Tokyo, secondary = Osaka, monitoring =
  Oregon in the sample).
- MUST: automate the region switchover (application quiescing, Aurora Global
  Database promotion, etc.) with AWS Step Functions to achieve an RTO of about
  5 minutes or less.
- MUST: run the switchover Step Functions state machine in the **unaffected
  secondary region (Osaka)** so failover can execute reliably even when the
  primary region is degraded.
- MUST: use Amazon Application Recovery Controller (ARC) for reliable, controlled
  region switching, and rely on Route 53 name resolution for on-premises traffic
  since switching depends on DNS.
- MUST: take AWS Backup backups as a recovery path against ransomware that
  encrypts or disables data.
- SHOULD: create the backup vault lock in **compliance mode** to make backups
  immutable until the retention period ends (the sample uses governance mode for
  convenience, where sufficiently privileged IAM users can still delete data).
- SHOULD: implement external (synthetic) monitoring by issuing pseudo-transactions
  from CloudWatch Synthetics Canary in Osaka and Oregon toward Tokyo and checking
  the responses.
- SHOULD: use CloudWatch Application Signals with a CloudWatch Agent sidecar to
  gain OpenTelemetry-based distributed tracing without changing application code.
- SHOULD: apply AWS WAF to the Application Load Balancer, use VPC endpoints,
  security-group network controls, and IAM least-privilege access.
- SHOULD: implement a workflow that isolates the workload when a cyber event
  occurs.
- SHOULD: account separately for replication lag during disaster recovery based
  on business requirements and application characteristics (both DBs normally
  replicate within ~1 second).
- PREFER: Aurora PostgreSQL Global Database for its long track record and high
  PostgreSQL compatibility; MAY adopt Aurora DSQL experimentally where synchronous
  replication, strong consistency, and Active-Active multi-region are decisive
  (see `references/architecture-dsql.md`).
- MAY: substitute Amazon EKS or Amazon EC2 for Amazon ECS as the compute layer to
  match requirements.
- MUST NOT: deploy both provided sample applications (the PHP ECS sample and the
  multi-region microservice app) at the same time — deploy only one.
- WILL: run the transaction worker in the Tokyo region only, even though the same
  microservice app is otherwise deployed to both Tokyo and Osaka, to avoid
  contention.
- WILL: enable an (initially disabled) EventBridge Rule at deploy time to allow
  automatic region switchover when both the Osaka and Oregon monitoring Canaries
  report failure.
- MUST: Apply cdk-nag's AwsSolutionsChecks (via Aspects) to every CDK stack built from this skill, and gate CI (jest etc.) on zero unsuppressed AwsSolutions-* findings; suppress exceptions only with an explicit reason via NagSuppressions (see references/cdk-nag.md).

### Key Components

#### Global Traffic Router / DNS
- **Component Overview**: Routes traffic between primary and secondary regions
  and is the pivot of DNS-based region failover; on-premises callers resolve the
  active region through it.
- **Assumed AWS Services**: Amazon Route 53 (incl. Private Hosted Zone), Amazon
  CloudFront, Amazon API Gateway (edge/API entry, not all in the CDK sample).

#### Inter-Region / Hybrid Network Fabric
- **Component Overview**: Connects the three regions to each other and to
  on-premises data centers over private connectivity, enabling multi-region
  operation and closed-network access.
- **Assumed AWS Services**: AWS Transit Gateway (with cross-region peering),
  AWS Direct Connect / DXGW (hybrid, not in the CDK sample), Amazon VPC.

#### Application Compute (Microservices)
- **Component Overview**: Runs the core banking business logic (balance query,
  deposit, withdrawal, transaction control) as containerized microservices using
  the Saga pattern for distributed-transaction consistency.
- **Assumed AWS Services**: Amazon ECS (default), optionally Amazon EKS or Amazon
  EC2; Elastic Load Balancing (ALB).

#### Transaction / Main Datastore
- **Component Overview**: Stores the authoritative account and transaction data
  with cross-region replication for consistency and disaster recovery.
- **Assumed AWS Services**: Amazon Aurora Global Database (PostgreSQL) or, as an
  experimental option, Amazon Aurora DSQL (serverless, distributed, Active-Active).

#### Transaction State Store
- **Component Overview**: Manages distributed-transaction state (Saga
  orchestration) and requires no manual switchover on failover when using global
  tables.
- **Assumed AWS Services**: Amazon DynamoDB (global tables, PITR enabled).

#### Region Failover Orchestrator
- **Component Overview**: Executes the reliable, automated sequence of region
  switchover — application quiescing, Aurora Global Database promotion, DNS

From aws-samples/sample-fsi-reference-architecture-jp, MIT-0.

More from aws-samples/sample-fsi-reference-architecture-jp