Multi-Cloud Performance Bottlenecks and Fixes

Multi-cloud often gets slower and more expensive for the same few reasons: too many cross-cloud hops, weak routing, late scaling, poor workload placement, scattered data, and split observability.

If I had to sum up the fix in one line, it would be this: keep apps and data close together, cut synchronous cross-cloud calls, scale on the signals that show strain first, and watch the whole path in one place. That matters because multi-cloud latency can jump from 25–35 ms in one cloud to 65–75 ms across several, Kubernetes scale-out can take 60–90 seconds, and public-cloud overspend is common, with only 6% of users staying within budget in one UK-cited report.

If you’re dealing with this now, I’d focus on six checks first:

• Latency: Track p95 and p99, not just averages
• Routing: Fix DNS failover, health checks, and path choice
• Service layout: Stop request flows bouncing between clouds
• Scaling: Use latency, queue lag, and error rate, not CPU alone
• Data placement: Keep hot data near the compute that uses it
• Observability: Put traces, logs, and metrics into one view

Here’s the article in one simple view:

For UK teams, this hits both performance and cost. £0.07–£0.09 per GB egress, uneven UK/EU user experience, and GDPR or sector rules can all turn a design choice into a service problem. So as I read this piece, I see one clear theme: multi-cloud works best when you remove avoidable distance, delay, and blind spots.

::: @figure {Multi-Cloud Performance Bottlenecks: Key Metrics & Fixes at a Glance} :::

Cross-cloud latency and weak routing

Why latency rises between clouds

Latency tends to climb when a request has to cross cloud boundaries on the critical path. Every extra hop adds delay, and those delays stack up. A common example is front-end services in one cloud calling an identity provider in another. On paper, each part may look fine. To users, the whole journey feels slow.

A multi-cloud database benchmark found query latency rising from 25–35 ms in a single cloud to 65–75 ms when the workload spanned AWS, Azure and GCP because of synchronisation and transfer overhead.[7] That gap helps explain why users notice the issue even when each cloud appears healthy on its own.

The warning signs are usually easy to spot once you know where to look:

• Region-specific slow page loads
• Intermittent timeouts
• Response times that vary by user geography
• Failover events where the service stays up but becomes much slower

If failover keeps the service available but performance drops off a cliff, the issue is often path selection rather than raw capacity.

Routing fixes to try first

Those symptoms often point to routing, but don't guess. Measure first. Start with RTT, jitter, packet loss and DNS resolution time between UK users and each cloud region. Track p95 and p99 latency, not just averages. Routing issues usually hide in a small slice of very slow requests, so the mean can look fine while users still have a bad time.

Once you have that baseline, DNS and failover are usually the first things to fix. Use health-aware DNS with short TTLs - 60 seconds is a sensible starting point for critical records - and rely on application-level health checks rather than simple port checks.[4][1][5][6] A region may answer on port 443 and still be a poor failover target if API responses are degraded.

The table below sums up the main routing options and the trade-offs.

For latency-sensitive front doors, edge termination and private interconnects usually beat default routing. Anycast is a good fit for global entry-point services such as authentication, API gateways and DNS. Dedicated interconnects such as AWS Direct Connect, Azure ExpressRoute and Google Cloud Interconnect can reduce median RTT by 3–15 ms and improve p99 latency by up to 50% compared with equivalent public internet paths.[2][3]

For UK teams, location matters more than many expect. Putting latency-sensitive services in London, Dublin or Frankfurt and using nearby interconnect points of presence can make a clear difference.

When to redesign the service layout

Routing fixes only go so far. The clearest warning sign is when tightly coupled services are split across clouds but call each other synchronously on every request. Anycast can improve the way traffic enters the system, but it won't repair a call graph that bounces across cloud boundaries several times before a response comes back.

A multi-cloud workload orchestration study reported a 31% throughput improvement and 27% latency reduction after optimising placement and connectivity for cross-cloud workloads.[8]

In practice, the redesign options are fairly plain:

• Group related services by region
• Cut down synchronous cross-cloud dependencies
• Consolidate components that have to talk across providers too often

When routing changes stop improving p95 and p99, the service layout is usually the real issue. If one user action crosses cloud boundaries more than once, the service map is doing too much work.

Poor autoscaling rules and bad workload placement

How weak scaling policies create bottlenecks

Good routing helps, but it doesn't save you when services scale too late or spin up in the wrong place.

A common problem is that CPU rises after demand has already jumped. If you rely on CPU-only autoscaling, the system often reacts when the damage is already done. APIs start timing out during traffic spikes, and queue lag builds up even while CPU still seems normal.[13][20]

The delay is longer than many teams expect. In Kubernetes, the gap between collecting a metric and getting new capacity ready often sits at 60–90 seconds.[10][13][19][22] For mid-size AI inference workloads, model loading can tack on another 60–120 seconds.[10][13][19][22] So when traffic comes in a burst, you've got almost no margin for error.

Multi-cloud adds another layer of trouble. If scaling rules differ across clouds, one environment can end up overloaded while another has spare headroom. The result is simple: one cloud turns into a hotspot, the other sits underused, and users sent to the busy one get hit with higher latency.[24]

Practical fixes for scaling and placement

The answer isn't just adding more capacity. It's using better signals.

Scale different workloads based on what actually shows stress:

• APIs: p95/p99 latency and error rate
• Queue workers: queue depth and oldest message age
• AI inference: GPU utilisation and inference latency

These signals usually tell you trouble is coming sooner than CPU alone.[9][10][11][12][13][14][16][18][19][20]

Placement matters just as much. Cross-cloud RTT between UK-facing regions and US regions can hit 70–150 ms. Within co-located regions, that figure is often under 5 ms.[15][25] That's not a rounding error. That's the sort of delay users can feel.

Put latency-sensitive APIs and inference endpoints in UK or nearby EU regions. Keep data-heavy jobs close to their main data stores. That removes delay that no autoscaling rule can patch over. Here's how the main approaches stack up:

Policy-driven orchestration gives the steadiest placement behaviour, especially when demand jumps fast.[17][21][24]

Signs the architecture needs a wider rethink

Some warning signs are hard to ignore: repeated hotspots, lag that sticks around even after scaling triggers fire, and pipelines so fragmented that teams can't enforce the same rules across environments.[23][24]

When that keeps happening, the issue usually isn't one bad autoscaling setting. It's the shape of the system. At that point, teams may need to split tightly coupled services, consolidate critical workloads, or add a single orchestration layer across clusters.

If scaling is now stable but requests still feel slow, the next bottleneck is data movement.

Data sprawl and cross-cloud data movement

Where data architecture hurts performance

Once scaling is under control, data placement is often the next thing that slows down p95 and p99 response times. This is where data gravity comes in: large datasets pull workloads towards them, and when compute and storage sit in different clouds or regions, simple reads can turn into cross-cloud hops.[28]

Hot data - active customer sessions, real-time feature vectors for AI inference, transactional tables - often ends up far from the services that need it most. A team spins up a second cloud for an AI test, leaves the main data where it is, and never goes back to fix the layout. Then the pain shows up fast: slower page loads, reports that take minutes instead of seconds, and AI pipelines stuck waiting on feature look-ups.

There’s also a plain cost issue. Public internet egress charges average £0.07–£0.09 per GB. Move 100 TB a year over the public internet and the bill can land between £80,000 and £115,000.[29] Private interconnects can cut that to about £0.016 per GB - roughly a 78% saving - but only when the setup is built to use them.[30]

Cross-cloud traffic usually runs over the public internet unless private interconnects are already in place.

Fixes for faster data access

Once you know which data is hot, the answer is usually better placement, not more capacity.

Classify data as hot, warm or cold based on access frequency and latency needs. Keep hot data in the same cloud and region as the compute that uses it. Warm data, such as recent transaction history for weekly reports or near-real-time dashboards, can stay in moderately fast storage close to the main analytics workload. Cold data - compliance archives, historical logs - can sit in low-cost archival tiers where extra latency is fine.

It also helps to use selective replication instead of copying everything everywhere. Small reference datasets with high day-to-day use, like product catalogues or feature look-up tables, are often worth replicating into each cloud where they are used. Large tables that are rarely queried usually are not. And bulk transfers belong in batch windows, off the critical path, not inside live user requests.

For UK workloads, keep latency-sensitive data and compute in the same UK region so user-facing reads stay local. AWS eu-west-2 and GCP europe-west2 keep traffic inside UK data centres and under 5 ms between them, while EU-only data should stay in the right EU regions to match residency rules.[26][27]

When data placement needs to be redesigned

When data has to cross clouds on the critical path, tuning can only do so much.

Small config changes - like pointing a BI tool at a local replica or moving a storage bucket - can help in the short term. But if a service depends on remote data by design, no config tweak will remove that cross-cloud call from the critical path. The only fix is to move the data or move the service.

If remote data is eating most of the latency budget, that’s the point where a redesign makes sense. A review is justified when more than 50–70% of the latency budget is spent on remote data access rather than compute, or when governance teams can’t clearly show UK/EU residency boundaries for key datasets.[26][27]

If p95 for a key journey breaks the target and remote data is the main reason, trigger a data-architecture review. Tying that trigger to UK GDPR residency duties turns a fuzzy performance problem into a clear decision point that can be checked and recorded.

Tooling gaps, redesign decisions and next steps

How observability gaps slow incident response

Good data placement helps, but incidents still drag on when nobody can see the whole request path.

In multi-cloud setups, logs, metrics and traces often live in different tools. That slows diagnosis because engineers have to stitch the story together across providers. Split telemetry also muddies the picture: routing faults, autoscaling faults and data-transfer faults can all look the same. You might see the same slow p99, but the root cause changes depending on which cloud handled the request last. That kind of fragmentation also makes configuration mistakes and change errors harder to spot, even though they account for 45% of major cloud incidents.[37]

A better approach is to use OpenTelemetry so traces, metrics and logs are collected in one format across every cloud. One OpenTelemetry Collector can pull telemetry from all environments into a single layer.[36][31] From there, define SLOs at the service level. For example, 99.9% of payments complete within 800 ms over 30 days. That gives every cloud involved in that service the same target to meet.[32][35] It also helps to give one platform or SRE team clear ownership of the stack and the runbooks.[34]

A simple framework for deciding: fix or redesign

Once telemetry is unified, the next decision is simple in theory and hard in practice: can you fix the bottleneck where it sits, or does the service need a redesign? If the same failure keeps showing up on the critical path, that usually points to architecture rather than tuning.

Point fixes are the right place to start when the issue is tightly scoped and easy to measure. Targeted changes fit cases where the same bottleneck keeps returning across releases, or where it affects an important but non-critical flow. A system-wide redesign makes sense when bottlenecks sit on revenue-critical or safety-critical paths, incidents keep needing manual intervention, or observability is too split up to support dependable diagnosis.[32][33]

For UK firms, regulation, SLAs and resilience demands should push critical-path issues towards redesign rather than patching around the edges.

Conclusion: Fewer cross-cloud hops, smarter scaling and clearer visibility

The clearest rule is this: cut cross-cloud hops where they do the most damage.

The same pattern shows up across each bottleneck covered here. Complexity was added bit by bit, but without a clear plan for how all the parts would behave together. The answer is to tighten routing, scale on the signals that matter, place workloads and data deliberately, and sort out observability before the next incident makes the choice for you. If your team is working through cloud cost engineering, DevOps transformation, cloud migration or cloud infrastructure optimisation, Hokstad Consulting works with UK organisations on these exact problems.

Multi-Cloud Architecture: 4 Latency & Resilience SECRETS Senior Engineers MUST Know

FAQs