Migrate from Amazon Web Services (AWS) Application Load Balancer to Azure Application Gateway

If you currently use AWS Application Load Balancer (ALB) and plan to migrate your workload to Azure, this guide can help you understand the migration process, feature mappings, and best practices. On Azure, Azure Application Gateway provides application load balancing capabilities that enable you to manage traffic to your web applications.

You'll learn how to:

• Assess your current environment
• Plan and prepare the migration
• Execute the transition while maintaining application availability and performance

What you'll accomplish

By following this guide, you'll:

• Map AWS ALB features to Application Gateway capabilities
• Prepare your environments for a successful migration
• Plan and execute a migration with minimal downtime
• Validate that your migrated workload meets performance and reliability requirements
• Learn to iterate on the architecture for future enhancements

This article uses a scenario to demonstrate common patterns like path-based routing, multi-zone distribution, and mixed compute environments that apply to many workloads.

Example scenario: Microservices architecture migration

In this example, a financial services company operates a microservices workload using AWS Application Load Balancer (ALB) to route traffic between multiple back ends. The workload's architecture includes a user authentication service running on EC2 instances and a transaction processing service deployed on AWS Fargate containers. The ALB performs path-based routing, directing /auth/* requests to the authentication service and /transactions/* requests to the containerized transaction processing service. This business-critical setup supports their core business function of processing secure financial transactions with high availability across multiple availability zones.

Architectural overview

This architecture example showcases common application load balancing features in AWS and Azure, including path-based routing, traffic distribution across diverse back-end servers, and multi-zone deployment patterns. The goal is to migrate this architecture from AWS ALB to Application Gateway while maintaining equivalent functionality and meeting workload expectations on performance, reliability, security, and others. In our architecture diagram /service-a/* represents the /auth/* path and /service-b/* represents /transactions/*.

Here's the architecture of the workload in AWS:

This is the architecture for the same workload, migrated to Azure:

Both architectures provide equivalent functionality, including:

• High availability deployment: Resources distributed across multiple availability zones for fault tolerance

• Network isolation: Virtual network with dedicated subnets for load balancer, application tiers, and data services

• Path-based routing: URL path-based request routing to different back-end services (/auth/*, /transactions/*)

• Multi-target flexibility: Back-end services distributed across different compute platforms and availability zones

• Mixed compute support: Combination of virtual machines and containerized workloads

• Advanced request routing: Sophisticated routing rules based on URL patterns with configurable health monitoring

• Integrated security: Web application firewall protection with security rule sets

• Network security controls: Security groups/rules controlling traffic flow between network tiers

• Secure Socket Layer (SSL) or Transport Layer Security (TLS) termination: Centralized certificate management and HTTPS endpoint handling

• Autoscaling capabilities: Automatic scaling based on traffic demand and resource utilization

• Comprehensive monitoring: Detailed metrics, access logs, and health monitoring for troubleshooting and optimization

Production environment considerations

This migration is designed as a cutover migration. With this approach, you build your Azure infrastructure in parallel with your existing AWS setup. This minimizes the complexity of moving users in batches and enables rapid rollback if problems arise. You can experience a brief period of downtime during the DNS cutover; the process is designed to minimize user disruption.

Expected downtime:

• DNS propagation time: 5-15 minutes for 300-second TTL
• Session disruption: Existing user sessions can be interrupted during cutover
• Service availability: Individual services remain available during migration

Recommended maintenance window:

• Duration: 1-2 hours during low-traffic period
• Buffer time: Extra 30 minutes for unforeseen issues
• Rollback time: 15-30 minutes if needed

Step 1: Assessment

Before you migrate from AWS Application Load Balancer to Application Gateway, assess the existing architecture and identify capabilities to map or replace. This assessment helps ensure a smooth migration and maintains your application's functionality.

Direct capability mapping

The microservices architecture capabilities map from AWS ALB to Application Gateway as follows:

Capability mismatches and strategies

If your workload uses ALB capabilities or other capabilities that can't be addressed in Application Gateway, consider the following strategies to still arrive at a comparable outcome.

• Direct functional replacement using other Azure service: Replace AWS ALB capabilities with Application Gateway equivalents while maintaining core functionality. This approach prioritizes minimal disruption and uses native Azure integrations for security, monitoring, and certificate management. For example, the capabilities offered in Auto Scaling Integration support is handled differently in Azure.

• Architecture enhancement approach: Use migration as an opportunity to modernize beyond AWS ALB capabilities by incorporating AKS with Application Gateway Ingress Controller, Azure API Management for advanced routing, and Azure Front Door for global distribution.

• Accept functional differences: Some AWS ALB capabilities don't have direct Application Gateway equivalents and require accepting different behavior in your migrated architecture. You'll need to assess the impact of these differences on your workload and determine if compensating changes are needed.

Auto Scaling Integration

AWS ALB capability: AWS ALB provides integration with Auto Scaling groups where:

• Instances are automatically registered/deregistered as targets when launched or terminated

• ALB health checks can trigger Auto Scaling actions to replace unhealthy instances

• Auto Scaling can use ALB metrics (request count per target) to scale capacity based on traffic demand

Application Gateway approach: Application Gateway doesn't have direct auto scaling group capabilities, but provides equivalent functionality through:

• Virtual Machine Scale Sets: Configure scale sets as Application Gateway back-end pools with automatic instance registration and health-based scaling

• AKS: Use Application Gateway Ingress Controller (AGIC) with Horizontal Pod Autoscaler for container-based workloads

• Azure Monitor integration: Implement custom scaling rules based on Application Gateway metrics and back-end pool health

Note: Application Gateway v2 (Standard_v2/WAF_v2) supports autoscaling and zone-redundant deployments; however, autoscaling is managed at the gateway level (scaling gateway instances) and differs from AWS Auto Scaling group behavior for back-end instances. Use Virtual Machine Scale Sets for back-end instance scaling and AGIC/AKS or scale set health integration when you need automatic target registration and pod/instance level scaling.

Step 2: Preparation

A detailed assessment can reveal opportunities to adjust resources at the source, easing both the migration process and post-migration operations. This step focuses on targeted adjustments to AWS ALB configurations and related services to ensure compatibility and performance on Azure.

Source service configuration

A successful migration requires detailed documentation of the existing AWS ALB configurations and dependent services to ensure a smooth transition to Application Gateway.

Path-based routing rule documentation

• Document existing AWS ALB listener rules to ensure equivalent Application Gateway routing rules. Use AWS CLI commands for load balancers to gather detailed configuration information.

• Export all routing configurations, health check settings, and SSL/TLS termination configurations using the AWS ALB listener rules documentation.

• Ensure all configurations are captured to prevent functionality gaps during migration, as Application Gateway requires explicit routing rule configuration.

SSL/TLS certificate preparation

• Export SSL/TLS certificates from AWS Certificate Manager for Azure Key Vault import.

• Convert certificates to PFX format with private keys, as Application Gateway requires this format for certificate management. Follow the Azure Key Vault certificate integration guide.

  Note

  Verify that the ACM certificate you plan to export is permitted to be exported by ACM. Some ACM-managed certificates (for example, certificates that are managed entirely by AWS for certain services) can't be exported; check the ACM documentation before relying on certificate export as part of your migration.

  Note

  This approach assumes you're utilizing the same domain names and existing certificates with an external DNS cutover. If the migration uses different domain names, you need to obtain new certificates.

Health check configuration mapping

Map AWS ALB health check configurations to Application Gateway health probe equivalents using the Application Gateway health probe configuration guide. This ensures back-end service health monitoring continues to function correctly after migration.

Dependency changes

Prepare for migration by updating dependent services and configurations to ensure compatibility with Application Gateway.

Back-end service changes

• If your application used HTTP headers injected by AWS ALB, update the applications to handle Azure-specific HTTP headers instead following Rewrite HTTP headers and URL with Application Gateway.

• Configure health check endpoints for Azure health probes following the Application Gateway back-end pool configuration guide.

• Configure logging integration with Azure Monitor using the Application Gateway diagnostic settings to maintain observability.

These changes ensure applications function correctly with Application Gateway's request processing and monitoring capabilities.

DNS configuration changes

• Reduce DNS TTL values on your DNS records to 300 seconds for faster cutover.

• If you plan to use Azure DNS, create A records pointing to Application Gateway public IP addresses by using the Azure DNS TTL configuration guide. This change enables rapid DNS propagation during migration cutover.

Back-end pool updates

• Configure back-end pool members across multiple availability zones and implement automatic failover capabilities.

• Use Azure Container Apps for serverless container back ends or AKS with Application Gateway Ingress Controller for orchestrated containers.

Environmental changes

Prepare your Azure environment by deploying the necessary infrastructure. Configure security and monitoring components to support the migrated workload. This preparation helps ensure a smooth transition and minimizes potential issues during the migration process.

Azure resource provisioning

• Deploy Application Gateway, Virtual Machines, and Container Apps using Infrastructure as Code before cutover following the Application Gateway deployment guides.

• Enable thorough testing and validation before production cutover through advance deployment.

Network security setup

• Set up Network Security Groups matching AWS security group rules.
• Maintain security posture before, during, and after migration.

Monitoring configuration

• Configure Azure Monitor workspace and Application Gateway diagnostic settings using the diagnostic settings configuration guide.

• Set up equivalent dashboards and alerting rules to match existing AWS CloudWatch monitoring using the Azure Monitor Application Gateway guide.

• Ensure continuous observability during and after migration.

Change sequence and dependencies

The following list outlines a logical sequence of changes to implement during migration. This sequence ensures that all dependent services are available before configuration begins, preserving system functionality throughout the migration. Think of it as your preflight checklist for migration day.

The general flow of changes is infrastructure deployment, back-end service migration, and then configuration of routing rules, health probes, and monitoring. This sequence ensures that all dependent services are available before configuration begins, preserving system functionality throughout the migration.

While the specific steps can vary based on your architecture, the general sequence is as follows:

1. Azure infrastructure deployment - Deploy Application Gateway and back-end resources first as it's necessary for subsequent configuration steps.

2. Back-end service migration - Migrate applications to Azure VMs and Container Apps. This can be done in parallel with the Azure infrastructure deployment to save time.

3. SSL/TLS certificate migration - Import certificates to Azure Key Vault using the Key Vault certificate integration guide. This step ensures that SSL/TLS termination is configured correctly before routing rules are applied.

4. Health probe configuration - Configure health probes matching AWS health check behavior using the Application Gateway health probe guide. This ensures back-end service health monitoring continues to function correctly after migration.

5. Routing rules configuration - Implement path-based routing rules. This step is crucial to ensure that requests are routed correctly to the appropriate back-end services based on URL paths.

6. Back-end pool optimization - Configure multi-zone distribution. This step ensures high availability.

7. Monitoring setup - Configure Azure Monitor dashboards and alerting using the Azure Monitor configuration guide.

   This step ensures that you have visibility into the performance and health of your Application Gateway and back-end services.

8. DNS preparation - Reduce TTL values in your current DNS environment, and prepare DNS record updates. This can be done in parallel with other steps as long as the DNS records aren't yet updated to point to Application Gateway until migration day. This step is crucial for ensuring a smooth cutover with minimal downtime.

In general, the migration process involves deploying and migrating resources first, followed by configuring routing rules, health probes, and monitoring. This sequence ensures that your Application Gateway is built and your back-end services are migrated before configuring the rest of the environment.

Step 3: Evaluation

Validation of the defined success criteria involves both automated and manual testing to ensure all functionality and performance benchmarks are met. Test key areas including routing accuracy, SSL/TLS termination, back-end health, response times, and session handling against the original AWS ALB configuration. Automated tests are best suited for verifying repeatable aspects like traffic distribution, throughput, and health check performance. Manual testing should be used to confirm more complex behaviors, such as custom error page display, configuration consistency, and SLA compliance. By combining these approaches, you can confidently validate that the Azure environment meets the required standards and mirrors the expected behavior from AWS.

Validation criteria

During preparation, define validation criteria that measure migration success. These criteria help ensure all capabilities function as expected after migration.

Success criteria definition

Establish validation criteria based on the original AWS ALB capabilities identified in the assessment section:

Functional criteria

• Path-based routing accuracy: Requests route to correct back-end pools based on URL paths

• SSL/TLS functionality: HTTPS connections terminate and re-encrypt properly with Azure Key Vault certificates

• Back-end service health: All back-end services report healthy status across availability zones

• Multi-zone distribution: Traffic distributes correctly with automatic failover

• Error handling: Error pages display correctly with proper failover behavior. If you have custom error pages configured in AWS ALB, ensure they're replicated in Application Gateway.

• HTTP timeout handling: Ensure HTTP timeout values are matched between AWS and Azure. Timeout values should be migrated as-is to preserve expected behavior, especially for upload/download scenarios.

Performance criteria

• Response time baseline: Average response time within 10% of AWS ALB baseline

• Throughput capacity: Handle equivalent requests per second as AWS ALB

• Concurrent connections: Support same number of concurrent users

• Health probe efficiency: Health checks execute without impacting performance

Reliability criteria

• Session handling: Maintain session affinity where configured

• Configuration drift: Monitor for configuration drift between environments to prevent reliability issues post-migration

• Compliance and SLA alignment: Validate that the migrated solution meets required compliance standards and Azure SLAs for uptime and reliability

Monitoring validation

Verify monitoring capabilities match AWS CloudWatch functionality:

• Response time trends matching expected patterns
• Request volume charts with accurate traffic distribution
• Error rate monitoring with appropriate alert triggers
• Back-end health status reflecting actual service health

Validation methods

Define methods for validating the success criteria established in the previous section. This includes both automated and manual testing approaches to ensure comprehensive coverage of all capabilities.

Remember that your environment might have unique requirements, so adjust the validation criteria and methods accordingly. In general, automated testing should be used where possible to cover most functional and performance criteria, and manual testing should be used as the fallback option to validate criteria.

Automated testing

• Create comprehensive automated tests covering all capabilities following the Application Gateway testing best practices:
  • Path-based routing validation for all services using the Application Gateway URL path-based routing
  • Performance and load testing against baseline metrics
  • SSL/TLS certificate validation and security testing
  • Error handling and failover scenario testing

Manual validation checklist

• Test user journeys across all services
• Validate file upload/download functionality
• Test authentication flows and session management
• Verify user experiences
• Test API functionality for all services
• Validate error scenarios and error page display

Step 4: Process

With your migration plan in place and preparatory changes completed, you're ready to move forward. Follow these detailed steps to execute the migration smoothly on migration day.

Migration execution

Migration execution involves a series of steps to ensure a smooth transition from AWS ALB to Application Gateway. The process includes final validation, parallel testing, DNS cutover, post-cutover validation, and AWS resource decommissioning.

Final validation and testing

Validate the defined success criteria by using automated and manual testing to ensure all functionality and performance benchmarks are met. Here's key functionality that you want to validate based on your evaluation criteria:

• Test HTTPS endpoints with valid certificates
• Verify path-based routing for all services
• Confirm multi-zone back-end pool distribution and failover
• Validate SSL certificate configuration and routing rules using test domains
• Execute service functionality tests through Application Gateway
• Validate microservices functionality across multiple zones
• Test high availability and failover scenarios
• Compare performance against AWS ALB baseline metrics

DNS cutover execution

Execute DNS cutover from AWS ALB to Application Gateway. Update DNS records to point to Application Gateway public IP addresses and monitor DNS propagation using standard DNS tools.

Post-cutover validation

During the post-cutover step, you validate the success of the migration by ensuring that all services are functioning correctly and that performance meets expectations.

Functional validation:

• Verify all service routing functions correctly
• Validate TLS/SSL certificate functionality
• Test error pages and failover behavior
• Validate health probe behavior and back-end health

Performance validation:

• Monitor response times against AWS ALB
• Verify throughput capacity meets requirements

AWS resource decommissioning

After successful validation, decommission AWS resources:

• Monitor Application Gateway for 24-48 hours
• Verify no traffic routing to AWS ALB
• Backup AWS ALB configuration for rollback capability
• Terminate AWS ALB and associated resources

In general, the migration is considered successful when all success criteria are met consistently over a 7-day monitoring period with no performance degradation compared to the AWS ALB performance. Depending on your specific workload, you might need to adjust the time period to ensure that all services are functioning correctly and that performance meets expectations.

Iterative optimization

After migration, focus on optimizing the Application Gateway configuration and validating routing accuracy, performance, and high availability. This iterative improvement process ensures that the migrated workload meets all success criteria established during the assessment step following the Azure Well-Architected Framework service guide for Application Gateway.

Iterative improvement process

The migration process is iterative and should be adjusted based on feedback and testing results until success criteria are met:

Performance optimization cycle

1. Baseline measurement: Compare Application Gateway metrics to AWS ALB baseline

2. Bottleneck identification: Identify performance gaps in routing, SSL termination, or back-end communication

3. Configuration tuning: Adjust Application Gateway settings, back-end probe intervals, or connection limits

4. Validation testing: Retest performance and measure improvements

5. Monitoring adjustment: Update monitoring thresholds and alerting rules

Routing accuracy refinement

1. Traffic pattern analysis: Monitor actual request routing patterns versus expected patterns

2. Rule optimization: Refine path-based routing rules to handle edge cases

3. Error rate analysis: Identify and fix routing rules causing errors

4. User experience validation: Ensure end-user journeys work seamlessly across services

High availability validation

1. Traffic distribution verification: Confirm traffic distributes correctly across availability zones

2. Failover process testing: Validate automatic failover between zones

3. Recovery capability: Test rapid recovery from zone failures

4. Health check accuracy: Ensure health checks correctly identify service problems

Key takeaways

Migrating a workload that uses AWS Application Load Balancer to Azure requires careful planning and systematic execution to obtain equivalent functionality or alternative approaches. The key success factors include:

Assessment and planning: Map AWS ALB capabilities to Application Gateway equivalents early in the process. Pay special attention to path-based routing, health probes, and certificate management differences.

Use Azure integrations. Take advantage of Azure Key Vault for certificate management, Azure Monitor for observability, and Virtual Machine Scale Sets for autoscaling.

Test thoroughly before cutover. Use parallel testing with temporary domains to validate all functionality. Establish baseline metrics from your AWS environment and ensure Application Gateway meets or exceeds performance expectations.

Plan for minimal downtime. Reduce DNS TTL values beforehand and prepare all infrastructure in parallel. The actual cutover involves only DNS changes, minimizing service disruption.

Monitor and optimize post-migration. Use the iterative improvement process to fine-tune performance, routing accuracy, and high availability. Application Gateway provides extensive monitoring capabilities to optimize your configuration over time.