fsi-foundation-hybrid-cloud

Files (10)

• SKILL.md
• SKILL_ja.md
• data_residency.png · assets/images/
• db_access.png · assets/images/
• mainframe_subsystem.png · assets/images/
• physical_network.png · assets/images/
• stock_exchange.png · assets/images/
• subsystem_analytics.png · assets/images/
• architecture.md · references/
• fisc-mapping.md · references/

SKILL.md (first lines)

# FSI Hybrid (AWS Outposts) Reference Architecture

## Workload Overview

This skill covers the **Hybrid (ハイブリッド)** reference architecture from the
"金融リファレンスアーキテクチャ日本版 / BLEA for FSI" v1.6 program. It targets workloads
that **combine AWS cloud and on-premises**, and specifically documents reference
architectures built on **AWS Outposts**.

A key premise is the **shared responsibility model for Outposts**, which differs from
the AWS Region model: the **physical security, power, network, and capacity management
of the customer data center where the Outpost is installed are the customer's
responsibility**. See the AWS whitepaper "AWS Outposts high availability design and
architecture considerations" for details.

Important Outposts terminology used throughout (all defined in the same whitepaper):

- **AWS Outposts** — a fully managed service that delivers the same AWS infrastructure,
  AWS services, APIs, and tools to virtually any data center, colocation space, or
  on-premises facility, providing a truly consistent hybrid experience.
- **Outpost (logical Outpost)** — an environment that manages the physically connected
  AWS Outposts racks as a single logical entity, deploying a pool of AWS compute,
  storage, and networking at the customer site.
- **Parent Region** — the AWS Region that provides the management, control-plane services,
  and Region-level AWS services required to deploy the Outpost.
- **Anchor Availability Zone (Anchor AZ)** — the Availability Zone in the parent Region
  that hosts the Outpost's anchor point; the Outpost functions as an extension of the
  anchor AZ.
- **Anchor point** — the endpoint in the anchor AZ that receives connections from the
  remotely deployed Outposts.
- **Service link** — the set of encrypted VPN tunnels that connect the Outpost to the
  anchor AZ of the parent Region.
- **Local Gateway (LGW)** — the logical interconnect virtual router that enables
  communication between the Outpost and the on-premises network.

This asset presents four representative use cases: a low-latency **securities trading
system**, a **mainframe peripheral system**, **data residency** enforcement, and
**low-latency access to on-premises databases**. Detailed technical descriptions of each,
plus the physical network layer between Outposts and AWS, are in
[references/architecture.md](references/architecture.md).

## Best Practices and Key Components

### Best Practices

- MUST: Provision the on-premises network to give each Outpost rack redundant network
  connectivity and reliable connectivity to the anchor point in the AWS cloud, because
  a resilient connection to the anchor AZ is essential for the logical Outpost's
  management, monitoring, and service operations to work correctly.
- SHOULD: Use multiple AWS Direct Connect connections across multiple Direct Connect
  locations to make the connection to the AWS Region resilient.
- SHOULD: Provide a backup for the AWS Direct Connect link between Outposts and AWS, such
  as AWS Direct Connect at a separate location or an AWS Site-to-Site VPN connection.
- SHOULD: Run functions with low-latency requirements (multicast, high-speed program
  execution) on EC2 instances, and run functions without low-latency requirements as
  Amazon ECS tasks on containers for resource-efficient operation.
- SHOULD: Place a securities trading system's execution management system (EMS) and order
  management system (OMS) — which require high-speed communication with the exchange — on
  Outposts racks equipped with AWS Outposts bmn-sf2e instances, operated in a data center
  near the securities exchange to enable high-speed trading.
- SHOULD: Take advantage of AWS cloud scalability for front ends and for databases that
  do not require low-latency access.
- SHOULD: Adopt an Outposts multi-AZ configuration for mainframe peripheral systems that
  require high availability.
- SHOULD: Create a dedicated VPC for the Outposts subnet and separate it from the AWS
  Region to clearly govern a VPC that is closed to the Outpost when data residency is
  required.
- SHOULD: Store Amazon EBS local snapshots on Outposts to S3 on Outposts so that snapshot
  data is isolated from the AWS Region and kept closed to the Outpost.
- SHOULD: Store snapshots of single-AZ RDS on Outposts instances to S3 on Outposts so that
  snapshot data is isolated from the AWS Region and kept closed to the Outpost.
- SHOULD: Apply Service Control Policies (SCPs) to deny data transfer/copy to the AWS
  Region and EC2 snapshot creation, in order to enforce data residency by separating the
  Outposts environment from the AWS Region (see architecture.md for the concrete SCP JSON).
- SHOULD: Place the backend instances and the database in the same data center so that the
  database can be accessed with low latency when a database cannot be migrated off premises.
- SHOULD: Take an active/standby configuration across multiple AZs, or configure across
  multiple AZs / Outposts racks, to achieve high availability.
- SHOULD: Set up spares for the customer network devices that communicate with Outposts.
- SHOULD: Install Outposts in multiple data centers for higher availability.
- MUST: Operate a firewall and take appropriate measures on the customer side in the
  on-premises environment.
- MUST: Perform the physical security and control of the customer data center where the
  Outpost is installed on the customer's own responsibility.
- MAY: Perform the relay processing between the on-premises mainframe and the cloud data
  lake / OLAP on Outposts.
- MAY: Consider using AWS Fault Injection Service to reproduce failures during verification.
- WILL: A VPC created within the AWS account that ordered the Outposts is seamlessly
  extended to the Outposts.
- WILL: In the event of an AWS Region failure, the Outposts inside the customer data
  center continue to operate normally.

### Key Components

#### Outposts Rack with bmn-sf2e Instances (Securities Trading)

- **Component Overview**: Runs the mission-critical, low-latency securities trading system
  (EMS and OMS) on an Outposts rack located near the securities exchange. The bmn-sf2e
  (bare metal) instance supports bare-metal networking and Precision Time Protocol (PTP),
  runs on the AWS Nitro architecture, is equipped with an AMD Solarflare X2522 network
  card, and supports Layer 2 multicast. It processes market data delivered by multicast
  from the exchange or from financial-information vendors and distributes it to systems.
- **Assumed AWS Services**: AWS Outposts (bmn-sf2e instance), Amazon EC2, Amazon ECS,
  Amazon Aurora, Amazon ElastiCache.

#### Physical Network Layer between Outposts and AWS

- **Component Overview**: Provides the fault-tolerant physical connectivity that links the
  logical Outpost to its anchor AZ. Each Outpost rack is given redundant network
  connectivity; private connectivity to the AWS Region is provided over AWS Direct Connect,
  made resilient with multiple connections across multiple Direct Connect locations.
- **Assumed AWS Services**: AWS Direct Connect, AWS Site-to-Site VPN (as a backup link),
  Local Gateway (LGW), service link.

#### Mainframe Peripheral / Integration System

- **Component Overview**: A multi-AZ Outposts configuration for high availability. The
  front end takes advantage of AWS cloud scalability and is built in the AWS Region with an
  Application Load Balancer and EC2 instances; the backend is processed on Outposts to also

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

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