Enhancing Legacy Application Reliability in AWS

This guide focuses on strategies to improve the reliability and availability of "traditional" or legacy applications when migrating to AWS, specifically in scenarios where the application code cannot be modified (the "Lift and Shift" approach).

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between traditional and cloud-native application architectures.
• Calculate application availability for both hard dependencies and redundant components.
• Identify AWS services that provide high availability for legacy workloads without requiring code changes.
• Select appropriate migration tools (MGN, DMS) to preserve application integrity during the cloud transition.

Key Terms & Glossary

• High Availability (HA): A system's ability to remain operational and accessible even during the failure of one or more components.
• Fault Tolerance: The property that enables a system to continue operating properly in the event of the failure of some of its components.
• Multi-AZ Deployment: Deploying resources across multiple isolated locations (Availability Zones) within an AWS Region to protect against data center failures.
• Hard Dependency: A relationship where the failure of one component (e.g., a database) causes the immediate failure of the entire application.
• RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time.
• RTO (Recovery Time Objective): The maximum acceptable delay between the failure of service and the restoration of service.

The "Big Idea"

Legacy applications often lack the inherent "self-healing" or "stateless" properties of cloud-native apps. However, we can wrap these applications in Reliability Shields provided by AWS. By using managed services like Application Load Balancers (ALB) and RDS Multi-AZ, we can achieve high availability at the infrastructure level, even if the application code remains unchanged and fragile.

Formula / Concept Box

Hierarchical Outline

• Migration Strategies for Legacy Apps
  • AWS Application Migration Service (MGN): Automated lift-and-shift of physical/virtual servers.
  • AWS Database Migration Service (DMS): Migrates databases with minimal downtime; supports homogeneous and heterogeneous migrations.
• Infrastructure Reliability Patterns
  • Compute Layer: Use EC2 Auto Scaling (even with a fixed count) to replace failed instances automatically.
  • Network Layer: Use Application Load Balancers (ALB) to perform health checks and route traffic away from unhealthy legacy instances.
  • Storage Layer: Use Amazon EBS snapshots for backups and Amazon EFS for shared file systems that don't require code changes to access.
• Database Reliability
  • RDS Multi-AZ: Synchronous replication to a standby instance in a different AZ for automatic failover.
  • RDS Proxy: Improves scalability by pooling database connections without modifying application code.

Visual Anchors

Legacy HA Architecture

This diagram shows how a traditional application is protected by AWS services in a Multi-AZ environment.

Availability Probability Mapping

This TikZ diagram visualizes how adding redundant components exponentially decreases the probability of failure.

Definition-Example Pairs

• Lift and Shift (Rehosting): Moving an application to the cloud without changing its code. Example: Exporting a VMware VM of an old accounting software and running it on an Amazon EC2 instance.
• Statelessness: A design where servers do not store user session data locally. Example: Storing user login sessions in Amazon ElastiCache instead of the local RAM of an EC2 instance, allowing users to stay logged in even if the server restarts.
• Amazon RDS Proxy: A managed database proxy that sits between the app and the DB. Example: A legacy app that opens thousands of connections and crashes the DB; RDS Proxy pools these into a manageable number, preventing the crash without code changes.

Worked Examples

Example 1: Calculating Cumulative Availability

Scenario: A legacy application runs on a single EC2 instance (90% availability) and connects to an RDS Multi-AZ database (99.95% availability). What is the total application availability?

Step 1: Identify dependencies. Both are hard dependencies. Step 2: Apply the formula $A_{total} = A_{EC2} \times A_{RDS}$. Step 3: $0.90 \times 0.9995 = 0.89955$. **Result:**$\approx 89.96% availability, which equates to roughly 36 days of downtime per year.

Example 2: Improving Availability with Redundancy

Scenario: If we add two more redundant EC2 instances (total of 3), what is the new availability of the compute tier (assuming instance availability is 90%)?

Step 1: Calculate the failure rate (F$) for one instance: $1 - 0.90 = 0.10$. Step 2: Calculate the combined failure rate for 3 instances: $0.10 \times 0.10 \times 0.10 = 0.001$. **Step 3:** Calculate the new availability: $1 - 0.001 = 0.999$. Result: The compute tier now has 99.9% availability (3 Nines).

Checkpoint Questions

1. Why is the availability of a system with hard dependencies always lower than the availability of its weakest component?
2. Which service would you use to migrate an on-premises physical server to AWS without refactoring the application?
3. How does a Multi-AZ RDS deployment improve RTO compared to a single-AZ deployment with daily backups?
4. What is the primary benefit of using an Application Load Balancer for a legacy application that cannot be virtualized into multiple instances?

[!TIP] In the exam, if an application "cannot be changed," look for solutions that provide reliability at the network (ALB), compute (Auto Scaling), or database (Multi-AZ) layers rather than application-level refactoring.