Modernizing Sales Applications on AWS: How We Rolled Out a New Sales App Using API Gateway + Lambda Routing

Rolling out a new version of a business-critical application is always a balancing act. On one side, the business wants users to experience the new improvements as quickly as possible. On the other, even a small production failure can disrupt operations and harm customer trust.

We recently faced exactly this challenge: the New Sales App was ready for release, while the Old Sales App continued to run in production. A big-bang switchover wasn’t an option. What we needed instead was a controlled, safe, and reversible rollout—where most users would continue using the old version while a small percentage gradually experienced the new one.

• Old Sales App: (stable, running on Amazon EC2 behind an ALB) was live in production

• New Sales App: (modernized, containerized on Amazon ECS with its own ALB) built & ready.

• The business expected:
  ✅ Minimal user disruption
  ✅ Gradual traffic rollout (starting with a small % to the New App)
  ✅ Instant rollback in case of unexpected behavior

1. DNS Weighting with Amazon Route 53

Weighted routing in Amazon Route 53 lets you split traffic between application endpoints by assigning weights to DNS records. For this rollout, two ALIAS records can be created—one for the Old Sales App ALB and another for the New Sales App ALB—with a traffic split like 95/5. Adjusting these weights allows gradual rollout or rollback.

Advantages: Simple configuration, no code changes required, fully AWS-native, and low cost.

Limitations: DNS caching affects precision, no stickiness between sessions, rollback depends on TTL expiry, and limited visibility into per-endpoint performance.

Best Use: Lightweight rollouts or low-risk apps where short DNS propagation delays are acceptable.

2. CDN-Level Weighting with CloudFront

Amazon CloudFront enables edge-level routing using Lambda Edge or CloudFront Functions. Requests are distributed between Old and New Sales App origins based on weights, with optional stickiness through cookies. Weight updates take effect globally within seconds.

Advantages: Precise routing at the edge, supports geo/device targeting, faster rollback, and reduced latency.

Limitations: Requires Lambda @ Edge setup, more complex logging, global replication delay, and higher operational cost.

Best Use: High-traffic or global rollouts needing fine-grained control and fast rollback.

3. API Gateway + Lambda Redirector (Chosen Approach)

🔹API Gateway serves as the single-entry point.

🔹Lambda function executes routing logic using environment variables (traffic weights).

🔹Instant rollback by updating a variable — no waiting for DNS or CDN propagation.

🔹Stickiness can be enabled (via cookie) or disabled depending on test needs.

1. Users click the Sales App link on the company website.

2. The link points to a neutral domain: https://sales.com.

3. This domain is mapped to Amazon API Gateway with an ACM-issued SSL certificate.

4. API Gateway invokes the Lambda Redirector function.

5. Lambda logic:
• Reads environment variables (OLD_SALES_APP_URL, NEW_SALES_APP_URL, TRAFFIC_WEIGHT_OLD, TRAFFIC_WEIGHT_NEW).
• Chooses between Old or New Sales App based on the defined weights (e.g., 95/5).
• Optionally sets a cookie for stickiness.
• Responds with an HTTP 302 redirect.

6. The browser follows the redirect transparently and loads either:
• Old Sales App via ALB → EC2 backend
• New Sales App via ALB → ECS service

Why This Approach is Safe

• Gradual rollout → Start with 5% on New Sales App, then ramp up.
• Immediate rollback → Update Lambda env var (TRAFFIC_WEIGHT_NEW=0) to send 100% traffic back to Old Sales App.
• No user disruption → Redirect is seamless, with negligible latency.
• Full observability → CloudWatch + ALB logs provide visibility into performance and error rates.

🔹Business stakeholders gained confidence through a risk-controlled, reversible rollout.

🔹End users experienced zero disruption.

🔹We collected real-world production performance data for the New Sales App before scaling further.

🔹Scaling was as simple as updating environment variables — no code redeployment required.

✅Avoid “all at once” migrations for critical apps.

✅Consider all three routing approaches:
• Route 53 → simplest, but less precise.
• CloudFront → powerful, but complex.
• API Gateway + Lambda → precise, safe, and instantly reversible.

✅Cookie-based stickiness is optional but useful for consistent user journeys.

✅Always keep a rollback lever — in this case, just an environment variable update.

This rollout pattern isn’t limited to sales platforms. It can be reused for:

✔️Migrating legacy systems to containers or serverless platforms
✔️Testing new API versions with live traffic
✔️Phased UI/UX rollouts in production

Rolling out a new application shouldn’t come at the expense of reliability. By combining API Gateway and Lambda, we were able to strike the perfect balance between control, safety, and agility, ensuring a smooth transition from the Old Sales App to the New Sales App—without disruption and with complete rollback confidence.

Join us in shaping the future of reliable, modern application delivery. Whether you’re modernizing systems or rolling out new platforms, now is the time to build with confidence. Partner with us to create resilient architectures and deliver innovation without disruption.
Contact us today

Date: 05/12/2025  :   Written by –