AWS Landscape 5: High Availability (HA)

High availability (HA) is critical for SAP workloads to ensure minimal downtime and maintain business continuity. AWS achieves HA by distributing resources across multiple Availability Zones (AZs) within a region.
Key benefits of HA deployment:

• Fault tolerance: Isolated AZs prevent single points of failure.
• Scalability: Auto Scaling ensures workloads can adapt to demand.
• Reliability: Load balancers distribute traffic and maintain application availability.
• Consistency: Monitoring and automated failover maintain uptime SLA > 99.9%.

This design assumes that HA decisions may vary by environment, with production always leveraging multi-AZ, while non-production accounts may use single-AZ based on cost and business priorities.

Objective
Design the AWS infrastructure to achieve high availability for SAP workloads by:

1. Distributing workloads across 2 or more AZs per region
2. Ensuring database and application tier fault tolerance
3. Leveraging AWS-native services (ALB/NLB, Auto Scaling, HANA System Replication)
4. Maintaining secure and monitored cross-AZ networking

Design Overview

High Availability Strategy:

• Deploy SAP workloads across 2 or more AZs per region.
• Use AZ-level isolation with independent subnets per AZ.
• Distribute application servers (EC2) and database replicas (HANA) across AZs.
• Implement Elastic Load Balancers to distribute traffic and remove unhealthy instances automatically.
• Enable synchronous replication for database HA within a region.

Technical Steps to Implement HA

Step 1: Identify Availability Zones (AZs) per Region

Primary Region (Production): ap-southeast-1 (Singapore)

Choose 2 AZs for high availability, e.g., ap-southeast-1a and ap-southeast-1b.

Secondary Region (DR): ap-northeast-1 (Tokyo)

Select AZs for disaster recovery, e.g., ap-northeast-1a and ap-northeast-1b.

Best practice: Use at least 2 AZs per region for synchronous replication and failover.

Step 2: Configure VPC and Subnets

Create Subnets per AZ within each VPC. Example Production VPC:

Subnet         AZ CIDR             Purpose

Subnet-1 AZ1 10.0.0.0/24 App EC2 + DB Primary

Subnet-2 AZ2 10.0.1.0/24 App EC2 + DB Secondary

Repeat subnet creation for all environment accounts: Dev, QA, Pre-Prod, Sandbox.

Assign public/private subnets based on workload requirements.

Step 3: Deploy Application & Database Across AZs

Application Tier (SAP AS/NetWeaver):

Launch EC2 instances in both AZs.

Use Auto Scaling Groups (ASG) to automatically scale based on traffic.

Database Tier (SAP HANA):

Implement HANA System Replication (HSR) for synchronous replication.

If using RDS, enable Multi-AZ deployment for high availability.

Ensure replication is synchronous within the region for HA.

Step 4: Load Balancer Configuration

Deploy AWS Elastic Load Balancer (ALB or NLB).

Distribute traffic evenly across both AZs.

Configure health checks to automatically remove unhealthy instances.

Integrate the Load Balancer with Auto Scaling Groups.

Step 5: Cross-AZ Networking

Configure route tables for communication between subnets in different AZs.

Use Security Groups and Network ACLs (NACLs) to control traffic flow.

Ensure minimal latency between AZs by keeping CIDRs contiguous and subnets close in the AZ topology.

Optional: Implement VPC Peering or Transit Gateway for cross-account connectivity.

Step 6: Monitoring & Failover

CloudWatch

Enable alarms for instance health, CPU, memory, and AZ-level metrics.

Auto Scaling

Automatically replace failed instances in any AZ.

AWS Systems Manager

Centralized operational visibility, automation scripts, and patch management.

Failover Testing

Periodically simulate AZ failures to ensure SAP applications and databases fail over correctly.

Diagram – Multi-AZ High Availability

High Availability Across AZs

• App EC2 instances and DB replicas are distributed across AZ1 and AZ2.
• Ensures fault tolerance if one AZ fails.

Elastic Load Balancer

• Distributes traffic evenly across both AZs for high availability.

Subnet Design

• Separate subnets per AZ maintain isolation and improve resiliency.

Fault-Tolerant Database Setup

• Primary DB in AZ1, replica in AZ2 for automatic failover.

Notes and Best Practices

• Multi-AZ deployment ensures uptime SLA > 99.9%.
• Production workloads always leverage multi-AZ HA; non-prod environments may use single-AZ for cost efficiency.
• Apply consistent security, monitoring, and logging policies per subnet/AZ.
• Regularly test failover scenarios to ensure reliability.
• Use CloudWatch, Auto Scaling, and Route53 health checks to maintain HA.