[SEO Subhead]
This Guidance demonstrates how to achieve a lower recovery time objective (RTO) for mainframe workloads. Mainframes run mission critical enterprise workloads with stringent RTOs. The AWS Well-Architected Framework (WAF) provides prescriptive guidance on building highly resilient applications, helping you choose the right disaster recovery strategy based on RTO requirements.
Aligned to WAF, this Guidance integrates with AWS Mainframe Modernization and other AWS services to create a warm standby environment. This environment will be ready to fail over your business processes to a separate AWS Region, reducing RTO for high-priority workloads.
Please note: [Disclaimer]
Architecture Diagram
[Architecture diagram description]
Step 1
Create a global Amazon Aurora Postgres database with a primary Region and secondary Region cluster.
Step 2
Create Amazon Relational Database Service (Amazon RDS) proxies for the database to help with pooling and database connections.
Step 3
Create an Amazon Elastic File System (Amazon EFS) file system. Turn on regional replication to create a replica in the secondary Region.
Step 4
Create a multi-Availability Zone (AZ) AWS Mainframe Modernization with AWS Blu Age environment in the primary Region.
Step 5
Configure AWS Direct Connect to establish a dedicated network connection between your on-premises infrastructure and AWS.
Step 6
Create and deploy the AWS Blu Age application from AWS Mainframe Modernization using the Amazon RDS proxy and Amazon EFS mount target. AWS Mainframe Modernization automatically provisions a Network Load Balancer (NLB) to distribute traffic to the modernized application.
Step 7
Repeat Steps 2-5 in the secondary Region. While creating an environment in secondary Region, choose the scaled-down version of configuration to ensure the application is up and on standby.
During the disaster recovery invocation process, you can use the APIs provided by AWS Mainframe Modernization to scale up resources in the secondary Region.
Step 8
Additional Recommendations: Steps 1-7 help you set up a warm standby architecture for your application in place. When creating a disaster recovery playbook, you can follow the additional best practices to automate the process:
- Use Amazon Route 53-hosted zones and Route 53 Application Recovery Controller (ARC) to route the traffic between primary and secondary Regions.
- After subscribing to Amazon RDS events that are generated from global database failover, you can use AWS Lambda functions to scale the resources in the secondary Region.
Get Started
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational Excellence
Amazon CloudWatch and Aurora provide real-time monitoring, customizable alerts, and anomaly detection. CloudWatch defines custom metrics and sets alarms for prompt response to performance issues. Aurora continuously monitors database health, generates events for failures or maintenance, and enables automated failover for disaster recovery, supporting operational excellence through proactive monitoring and automated actions.
-
Security
Aurora PostgreSQL supports encryption at rest using AWS Key Management Service (AWS KMS) and encryption in transit through SSL/TLS connections, protecting sensitive data. Instances are deployed within virtual private clouds (VPCs) with network security groups for access control. Aurora automatically applies security patches and updates, reducing exposure to known vulnerabilities.
-
Reliability
Multi-AZ deployment provides redundancy, high availability, and disaster recovery capabilities, mitigating risks of single points of failure. Route 53 ARC continuously monitors application health, detects failures, and automates recovery actions like traffic rerouting or failover initiation. This reduces recovery time and enhances operational resilience.
-
Performance Efficiency
Multi-AZ deployment enables horizontal scaling by adding instances or resources across AZs as demand increases. Aurora PostgreSQL uses a distributed, shared storage architecture that automatically scales compute and storage based on workload demands. This scalable architecture, combined with the ability to handle high throughput and large transaction volumes, allows you to optimize performance and meet varying workload requirements efficiently.
-
Cost Optimization
AWS Mainframe Modernization and Aurora offer pay-as-you-go pricing, meaning you only pay for the resources you consume, which eliminates upfront costs. Aurora's storage auto-scaling from 10 GB to 64 TB per instance optimizes utilization. This flexible pricing model allows you to scale resources up or down based on workload demands, minimizing unnecessary expenses from overprovisioning or underutilization.
-
Sustainability
Built on AWS's energy-efficient infrastructure with advanced cooling, efficient power distribution, and renewable energy sources, Aurora and AWS Mainframe Modernization minimize energy consumption. Aurora automatically scales compute and storage based on workload demands for efficient resource utilization and reduced wasted resources. This optimized resource allocation minimizes the environmental impact associated with excessive energy consumption and hardware provisioning.
Related Content
[Title]
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.