SAP Integration Suite DNS Failover: Azure Traffic Manager vs. AWS Route 53

SAP Integration Suite DNS failover redirects new client connections to a healthy secondary tenant when the primary endpoint fails its health checks. Azure Traffic Manager and AWS Route 53 can support this routing pattern, but the actual recovery time depends on health-check settings, DNS caching, client behavior, and whether the secondary tenant and its dependencies are ready.

This guide compares both approaches, explains the DNS prerequisites your network team must provide, and shows how to test failover and failback across regions.

Why does a standby tenant need its own routing layer?

Because SAP's built-in resilience stops at the region boundary, and nothing inside SAP moves traffic between two tenants.

Inside one region, SAP spreads Integration Suite across availability zones and backs it with a 99.95% SLA. Across regions, the customer takes over. Integration content isn't copied between tenants automatically, and the failover route needs a load balancer that you supply. On that point, the SAP Community architecture post is direct:

"SAP does not manage the Load Balancer, so SAP cannot provide an SLA."

So the component that decides where traffic goes during an outage usually belongs to your network and infrastructure team.

ITIC's 2024 downtime survey of more than 1,000 organizations found that over 90% of mid-size and large enterprises lose more than $300,000 for every hour of downtime. For 41%, the figure ranges from $1 million to over $5 million. Our article on the real cost of SAP Integration Suite downtime breaks this down for integration landscapes.

How does DNS failover move SAP Integration Suite traffic?

Clients reach the tenant through a hostname. A traffic manager controls which tenant that hostname resolves to, based on health checks.

Here's the path a request takes:

Partner / app / SAP Cloud Connector
        │  1. looks up the integration hostname
        ▼
Enterprise DNS ──CNAME──▶ Traffic manager (Azure Traffic Manager or Route 53)
                               │  2. probes both tenants every 10–30 s
                   ┌───────────┴────────────┐
                   ▼                        ▼
          Primary tenant / EIC        Standby tenant / EIC
          returned while healthy      returned when primary fails probes

In plain terms:

The traffic manager keeps checking whether each tenant responds.
While the primary passes, DNS answers point to the primary.
When the primary fails enough checks in a row, DNS answers point to the standby.
Each client switches the next time it looks up the hostname, once its cached answer runs out.

That fourth step is the one teams tend to underestimate.

Load balancer or DNS traffic manager: what's the difference?

Both decide where traffic goes. The difference is who runs that decision and what SLA stands behind it.

	Customer-run load balancer (SAP native model)	DNS traffic manager (OneFailover model)
Where the decision is made	A load balancer you build and operate outside SAP	Azure Traffic Manager or Route 53, driven by monitored health checks
How cross-region DR is set up	Manually, with tenants in several regions behind your load balancer	DNS-based failover between configured tenants, automated by OneFailover
SLA behind the routing layer	Only what your own setup provides; none from SAP	The hyperscaler's published SLA, plus your DNS redundancy

On the hyperscaler side, Microsoft commits to answering Traffic Manager DNS queries at all times, provided clients retry. It also runs the service across many Azure regions so that one regional failure doesn't take it down. AWS issues Route 53 service credits whenever a hosted zone's monthly availability drops below 100%.

The SLA on your SAP tenants stays the same either way. What improves is that the switch itself runs on a service with a published commitment.

For the full shared-responsibility picture, see SAP Integration Suite Disaster Recovery: The Coverage Gap.

Azure Traffic Manager or AWS Route 53: which fits your SAP landscape?

Use the one that matches the cloud where your Edge Integration Cell and network already run. OneFailover uses Azure Traffic Manager on Azure and Route 53 on AWS. The surrounding building blocks change with the cloud:

Building block	On Azure	On AWS
DNS traffic management	Azure Traffic Manager, set as the Health Probe URL endpoint in the OneFailover group. The customer provides it.	Route 53 health checks with latency-based routing; AWS Global Accelerator can sit in front
Kubernetes for Edge Integration Cell	AKS, sized for Edge runtimes and OneFailover pods	Amazon EKS
Ingress for Edge endpoints	Internal Load Balancer plus AKS ingress (NGINX or Application Gateway Ingress Controller)	NLB or ALB plus EKS ingress (NGINX or AWS Load Balancer Controller)
Network	VNet and subnets for AKS, private endpoints and Traffic Manager targets	VPC and subnets for EKS and load balancers
Private link to on-premises	VPN Gateway or ExpressRoute	Site-to-Site VPN or Direct Connect

Beyond the cloud match, three differences can shape your decision.

Routing methods. Traffic Manager supports six methods: priority, weighted, performance, geographic, multivalue and subnet. For pure failover, priority is the natural choice. Traffic goes to the primary, and a backup takes over only when the primary is down. That's the method the minimal OneFailover Azure setup uses.

How health is judged. Route 53 sends health checks from several locations worldwide. It treats an endpoint as healthy only when more than 18% of those checkers agree. This guards against one bad network path triggering a failover.

Getting around DNS caching. On AWS, Global Accelerator gives clients fixed anycast IP addresses instead of relying on DNS answers. Clients then don't have to wait for a cached record to expire before they move.

If you run on Google Cloud, the equivalent pairing is Cloud DNS routing policies with health checks, plus Cloud Load Balancing.

How the two SAP runtimes resolve. The Cloud Integration hostname resolves through a DNS profile. The Edge Integration Cell hostname resolves through a private DNS zone behind an application gateway. Every OneFailover failover group has its own health probe, and the probe URL in the group configuration is the Traffic Manager endpoint.

How long does SAP Integration Suite DNS failover take?

Add the time to detect the failure to the time clients hold on to old DNS answers. With default settings, that usually comes to a few minutes.

Setting	Azure Traffic Manager	Amazon Route 53
Health check interval	30 s by default, or 10 s with fast probing	30 s by default, 10 s at minimum
Failed checks before switching	3 tolerated by default, adjustable from 0 to 9	3 by default, adjustable from 1 to 10
Check timeout	10 s by default at a 30 s interval	Not applicable

Assume 30-second probes, 3 tolerated failures and a 30-second TTL. Traffic Manager marks the primary as down after its fourth failed probe in a row, roughly 2 minutes after it stops responding. A client that looked up the hostname just before then can keep using the old answer for up to 30 more seconds. Then any open connection has to reconnect.

Four ways to bring that down:

Switch to 10-second probes.
Tolerate fewer failures, while keeping enough margin that a brief network glitch doesn't trigger a failover.
Shorten the TTL on the traffic manager profile and on any CNAME records in your enterprise DNS.
Check SAP Cloud Connector and key clients for DNS caches that hold answers longer than the TTL.

What DNS prerequisites does SAP Integration Suite failover need?

Five DNS pieces must be ready before DNS-based failover can work, and the customer supplies all five.

What you need	Why	Owner
Internal DNS service (AD DNS, BIND or cloud private DNS)	Hosts or forwards the zone for Edge Integration Cell and group listener endpoints. Internal clients and SAP Cloud Connector rely on it to find Edge runtimes.	Customer network team
A zone for Edge endpoints (for example `edge.<corp>.local`)	Holds the A, AAAA or CNAME records that point to each Edge runtime's internal load balancer or ingress, and to any group listener endpoints set up in OneFailover	Customer
Health probe and traffic manager records	CNAME or A records that tie the group Health Probe URL and traffic manager names to real endpoints. This is where OneFailover's probe settings meet your actual DNS.	Customer, with OneFailover team input
Conditional forwarders or split-horizon rules	Make branches, on-premises sites and cloud VNets all resolve these zones the same way. Use split-horizon when one hostname serves both internal and external clients.	Customer
Redundant, monitored DNS	Keeps resolution available during an incident and alerts you when lookups fail	Customer

Don't treat the last row as optional. Both the health probes and the listener endpoints depend on DNS resolving correctly. If your DNS goes down during an outage, failover goes down with it. DNS redundancy and resolution monitoring are part of the recovery path itself.

Who owns each part of the failover setup?

You own DNS and the traffic manager. The record mapping between the health probe and the traffic manager is shared with the OneFailover team.

Responsibility	Customer	OneFailover team
Internal DNS, Edge zone, forwarders	✔
DNS redundancy and monitoring	✔
Traffic Manager profile (Azure)	✔
Health probe and traffic manager record mapping	✔	✔ (input and agreement)
Failover group and health probe configuration		✔
Health probe and routing approach agreed before rollout	✔	✔
SAP Cloud Connector parity for on-premises flows	✔	✔

Settle the shared rows during onboarding. A mismatch between the probe configuration and real DNS records is one of the easiest ways for failover to look ready and still fail.

How should you design the health probe?

Point the probe at something that proves integrations can actually run. A gateway or load balancer can keep returning HTTP 200 while the runtime behind it has stopped.

Check a real runtime path, such as a lightweight health iFlow or a runtime status endpoint, not a static page.
Send the probe the same way client traffic goes, through ingress and private DNS, so a failure in either one also counts.
Keep it light and side-effect free. It runs every 10 to 30 seconds, from several locations.

What does DNS failover not move?

DNS redirects new inbound connections and nothing else. Plan for these separately:

Messages already in flight. Anything queued or mid-process on the failed tenant stays there. Artifact sync and message recovery handle this, not DNS.
Outbound calls. Integrations calling back-end systems from the standby side need their own connectivity, including SAP Cloud Connector.
Partner allowlists. If a trading partner's firewall accepts only your primary tenant's IP addresses, it will block the standby. Register the standby addresses ahead of time.
Clients that skip DNS. Anything connecting by fixed IP, or caching DNS answers longer than the TTL, won't follow the switch.

How do you fail back without causing a second incident?

Make failback a planned step, not an automatic one. Priority routing in Traffic Manager and failover records in Route 53 both send traffic back to the primary as soon as it passes health checks. If artifacts or settings on the primary are out of date, traffic can land on a tenant that isn't ready.

A safer sequence:

Keep the recovered primary disabled in the traffic manager.
Resync artifacts and configuration from the tenant that handled the outage.
Re-enable the primary in a planned window, and watch probes and message processing closely.

How do you prove failover works? Run a drill

Simulate an outage on purpose and time every stage.

Disable or block the primary endpoint during a test window.
Note the moment the traffic manager marks it unhealthy.
Note when apps, SAP Cloud Connector and a test partner actually reach the standby.
Confirm outbound calls and partner connections work from the standby.
Fail back using the planned sequence and time it again.

Planned SAP maintenance windows are a natural time to rehearse. See SAP planned maintenance downtime and cross-region resilience for SAP Integration Suite for related guidance.

What changes when routing becomes part of DR

The traffic switch stops being a manual step and becomes a monitored, automated part of recovery.

Health checks make the call. Monitored probes on the group Health Probe URL trigger the switch, instead of a person or a separately managed load balancer.
The routing layer has a published SLA. It runs on Azure Traffic Manager or Route 53, with your DNS redundancy underneath.
Latency can drop, if you route for it. Route 53 latency-based routing and Traffic Manager performance routing send users to the nearest healthy endpoint. Priority routing, used for straight failover, doesn't change latency.

Where this leads is DR that's routine rather than exceptional. Teams fail over during planned maintenance, track recovery time across drills, and watch DNS resolution as closely as the runtime.

Frequently asked questions about SAP Integration Suite DNS failover

What is DNS failover, and how does it work? DNS failover sends new traffic to a backup endpoint when the primary one fails its health checks. A traffic management service stops returning the failed endpoint in DNS answers. Clients move over when they resolve the hostname again, so caching and TTL settings affect how fast that happens.

What is the difference between Azure Traffic Manager and AWS Route 53 for DNS failover? Both route traffic by DNS and fail over on health checks. Azure Traffic Manager uses methods like priority and performance routing, while Route 53 uses failover and latency-based routing policies. The right choice usually follows your cloud. OneFailover uses Traffic Manager on Azure and Route 53 on AWS.

How does disaster recovery work in SAP Integration Suite? You need a secondary tenant, synchronized integration artifacts and a way to move inbound traffic to it. Syncing alone doesn't redirect anything. A complete design adds failover routing, endpoint health checks, DNS resolution and connectivity to back-end systems. OneFailover automates the traffic switch with hyperscaler DNS services.

How do health checks trigger automatic DNS failover? The traffic manager probes each endpoint at a configured interval. After a configured number of failed probes, it marks the primary unhealthy and returns the backup in DNS answers. For this to work, the probe URL, endpoint mapping, firewall rules and secondary runtime must all be correct.

How long does DNS failover take, and what affects failover time? Failover time is detection time plus DNS caching. Detection takes roughly the probe interval multiplied by the failure threshold. Resolvers and clients then keep cached answers until the TTL expires, and open connections must reconnect. With default settings that can take a few minutes, so measure it in a test.

What DNS prerequisites are required for SAP Integration Suite failover? You need internal DNS that resolves Edge Integration Cell hostnames, a DNS zone for those endpoints, records mapping the health probe and traffic manager names, conditional forwarders or split-horizon rules where needed, and highly available, monitored DNS servers. The customer network team provides these, with OneFailover input on the mappings.

A standby tenant is a plan. A tested routing layer is a recovery.

See how OneFailover automates SAP Integration Suite failover

SAP failover solution