How to Use Services From Multiple Clouds in One Application: Identity, Networking, Data, and the Platforms That Make It Work

One application can use services from several clouds when it can authenticate to each provider without long-lived keys, reach each service over a secure network path, and keep data movement and egress cost under control. Infrastructure as code, Kubernetes, and governance tools each cover part of this. On Control Plane, a workload running in any Control Plane location, on AWS, GCP, Azure, or your own infrastructure, calls AWS, GCP, and Azure services through Control Plane’s Universal Cloud Identity (UCI), with short-lived credentials issued at runtime.

Disclosure: Control Plane publishes this guide.

TL;DR

One application can call services across AWS, GCP, and Azure once it solves four problems: identity, networking, data gravity and egress, and operations.

• Identity. Your workload needs credentials each provider accepts. Options range from static access keys to workload identity federation to a platform-provided identity on all three clouds.
• Networking. Every cross-cloud call needs a secure path: public endpoints with TLS, private connectivity, or application-level tunnels to specific endpoints.
• Data gravity and egress. Providers charge for data leaving their network. Run compute close to the data it reads most, and send small requests and results across clouds.
• Operations. Each provider has its own SDKs, quotas, failure modes, and billing. Centralize observability, policy, and cost tracking.
• Platforms that help. Infrastructure as code provisions resources, Kubernetes distributions standardize deployment, management platforms govern policy, and secrets brokers issue credentials. Control Plane runs the application across clouds with identity on AWS, GCP, and Azure.

Can an application on one cloud use services from another?

Yes. Common patterns:

• An application on AWS calls a model through Azure OpenAI in Microsoft Foundry because the model it needs is offered there.
• A product analytics pipeline writes to BigQuery on GCP, while the application generating the events runs on AWS.
• A managed PostgreSQL database lives on one provider, and services on other providers read from it.
• An acquisition brings a team running on Azure into an organization standardized on AWS, and both systems call each other’s APIs.

Teams do this for best-of-breed services, model availability, existing data, contracts, and regulation. Every cross-cloud call must solve authentication, traverse a network path, and possibly move data that incurs egress charges.

How do I call AWS, GCP, and Azure services from one application without managing cloud keys?

Use workload identity federation or a platform-provided identity, so each cloud issues short-lived credentials at runtime and no long-lived keys sit in code. Four approaches compare as follows.

Federation removes static secrets, but its setup differs between AWS, GCP, and Azure: each has its own trust policy syntax, token audience rules, and role bindings. Teams running many services across two or three clouds maintain a matrix of trust configurations. For how federation works on each provider, see Control Plane’s guide to workload identity federation.

How should the network path between clouds work?

Public endpoints with TLS and provider firewalls. Most cloud services expose HTTPS endpoints. You restrict access with IP allowlists and identity-based policies. This path suits low-volume, latency-tolerant calls; traffic crosses the public internet, and access control rests on provider-side rules. Many services, including Azure OpenAI and BigQuery, also offer private endpoints (Azure Private Link, Google Private Service Connect), which a workload on another cloud can reach only over private connectivity.

Private connectivity. Site-to-site VPNs, dedicated interconnects such as AWS Direct Connect or Azure ExpressRoute (cross-connected at a colocation facility or through a network partner for cloud-to-cloud use), and cross-cloud products such as Google Cloud Cross-Cloud Interconnect provide private, dedicated paths that bypass the public internet. Dedicated links do not encrypt traffic by default, so add MACsec or IPsec where required. Costs include circuit fees, provisioning lead time for dedicated links, and link maintenance.

Application-level tunnels to specific endpoints. You can tunnel traffic to individual TCP endpoints in a remote VPC or data center, which limits exposure and avoids full network peering. Control Plane’s Cloud Wormhole is one example.

For a comparison of private networking options across AWS, GCP, and Azure, see cross-cloud private networking for VPCs and VNets.

Data gravity and egress: where should each component run?

Cloud providers charge for data leaving their network, with rates that vary by provider, region, and volume tier. Ingress from the internet is usually free. Egress also applies between regions inside one cloud, and private interconnects usually carry lower per-GB rates than internet egress.

Data attracts the compute that reads it. If an application reads large volumes from a database on GCP and sends small inference requests to Azure, run the database-reading workload on GCP and keep the Azure call cross-cloud.

• Run compute close to the data it reads most. A service whose primary data source is BigQuery belongs on GCP.
• Send small requests and results across clouds. A model call sends a prompt and receives a response, both small.
• Keep large datasets in their home cloud. Analyze a large dataset where it lives and send the summary to the other cloud.

Every cross-cloud call also adds network round-trip time, so component placement matters for latency as much as for cost.

Can an application running on AWS use Google BigQuery or Azure OpenAI?

Yes. The application authenticates to each provider through federated identity, calls their public or private endpoints, and keeps heavy data reads on AWS. Example: an e-commerce company runs order processing on AWS, generates product descriptions with Azure OpenAI in Microsoft Foundry, and writes analytics events to BigQuery.

1. Identity for Azure OpenAI. The application gets a short-lived token from AWS STS through IAM outbound identity federation. In Microsoft Entra, the team adds a federated identity credential to a user-assigned managed identity (or app registration) that trusts that issuer, subject, and audience. The application exchanges the token for a Microsoft Entra access token. The managed identity holds the Cognitive Services OpenAI User role on the Azure OpenAI resource, and no API key is stored in the application.
2. Identity for BigQuery. The team creates a GCP Workload Identity Federation pool with an AWS provider for the AWS account. Google verifies the application’s IAM role credentials through a signed GetCallerIdentity request and exchanges them for a short-lived Google credential. The federated principal, or a service account it impersonates, holds a BigQuery role on the dataset. No service account key file is involved.
3. Network path to Azure OpenAI. The team calls the public HTTPS endpoint over TLS, sends from fixed egress IPs on AWS (for example through a NAT gateway), and allowlists them in the Azure resource’s firewall rules. Prompts and responses are a few kilobytes of text.
4. Network path to BigQuery. The application calls the BigQuery API over TLS, with access limited by the IAM grant from step 2.
5. Data flow. The application reads order data from a PostgreSQL database on AWS. Analytics events are batched and compressed before each write to BigQuery. All heavy reads stay on AWS.
6. Failure handling. Each Azure OpenAI call has a timeout sized to the user-facing latency budget and retries with exponential backoff and jitter, honoring Retry-After on rate-limit responses. If retries fail, the application serves a cached description or a template. Events go to a durable queue on AWS, such as Amazon SQS, and flush when BigQuery recovers; writes carry insert IDs so retries do not duplicate rows. The application caches federated credentials until shortly before expiry, so a token-exchange outage does not block every call.
7. Observability. The team instruments the application with OpenTelemetry. Each request produces one trace with client spans for the Azure OpenAI call. Batched BigQuery writes get their own spans, linked to the requests that produced the events. Managed services do not continue your trace, so the application records provider request IDs, latency, and status codes as span attributes, and the team sees every cross-cloud dependency’s latency and errors in one backend.

On Control Plane, steps 1 and 2 become one identity with Azure and GCP access rules, and the workload receives short-lived credentials for both at runtime.

Which platforms let one application use services from multiple clouds?

Five categories of platforms address this. Control Plane covers identity, networking, and deployment in one platform; the others each cover one layer.

For a broader comparison, see the best multi-cloud management platforms in 2026.

What are the challenges of using services from multiple cloud providers in one application?

• Identity sprawl. Each cloud has its own IAM model, role syntax, and trust policy format.
• Network path design. Public endpoints, private interconnects, and tunnels each carry different cost, latency, and security trade-offs.
• Egress cost. Charges for data leaving a provider’s network grow with high-volume traffic.
• Latency. Every cross-cloud call adds round-trip time, which constrains placement for latency-sensitive features.
• Different SDKs and quotas per provider. Client libraries, rate limits, error codes, and retry semantics differ.
• Compliance and data residency. Rules on where data is stored and processed apply to every provider in the path, and audits must trace data flows across all of them.
• Failure handling when one provider ’s service is down. Each cross-cloud call needs timeouts, retries, and a fallback.
• Observability across providers. Traces, metrics, and logs from different clouds must be correlated in one view.
• Cost attribution. Allocating spend to teams, features, or customers is harder across several billing systems.

Which platform unifies identity, networking, and deployment across AWS, GCP, and Azure?

Control Plane covers all three in one platform. Control Plane’s Universal Cloud Identity handles identity, Cloud Wormhole and mTLS handle networking, and Control Plane’s Global Virtual Cloud (GVC) handles deployment.

Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, and Azure, VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises. Workloads run active-active across regions and clouds.

Identity. Control Plane’s Universal Cloud Identity lets a workload call 600+ AWS, GCP, and Azure services with no long-lived cloud keys in your code, from any location, including locations on a different cloud. You connect each cloud account once (an IAM role on AWS, a service-account grant on GCP, a connector function deployed to your Azure subscription), instead of maintaining a separate federation trust per cloud, and workloads receive short-lived, least-privilege credentials at runtime.

Deployment. On Control Plane, a workload deployed to a Global Virtual Cloud (GVC), Control Plane’s named set of locations across one or more clouds, runs in every location of that GVC from one definition. Locations can be regions of one cloud or regions on AWS, GCP, and Azure together, and Control Plane’s built-in global endpoint routes each request to the nearest healthy location. For more, see how to run the same app on AWS, GCP, and Azure.

Networking. Control Plane’s Cloud Wormhole connects workloads to specific TCP endpoints in VPCs, data centers, and other private networks through an agent you install in that network. Every workload has a deny-by-default internal firewall with mTLS between services.

Operations. Control Plane handles Day 2 operations for you, including autoscaling, security, and built-in logs, metrics, and tracing for every workload. On Control Plane-managed locations there is no Kubernetes cluster to operate. The CLI, console, Terraform and Pulumi providers, and the Control Plane MCP server all work through the same Control Plane API, and Control Plane complements the infrastructure as code you already run. Teams can consolidate multiple clouds into one platform incrementally and keep using provider-specific services where they help; see managed services vs portability.

Reliability, compliance, and cost. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. You pay for the CPU and memory a workload reserves, with no contracts or minimums.

FAQ

Short answers for teams combining services from AWS, GCP, and Azure in one application.

Is it safe to use services from different clouds in one app?

Yes, when identity and networking are handled correctly. Use short-lived, least-privilege credentials through workload identity federation or a platform-provided identity, encrypt all cross-cloud traffic with TLS, and apply deny-by-default rules between services. Control Plane provides mTLS between workloads and a deny-by-default internal firewall for every workload.

How do I avoid egress fees when using multiple clouds?

You can reduce them. Run compute close to the data it reads most, send small requests and results across clouds, keep large datasets in their home cloud, batch and compress payloads, and cache frequently used data locally.

Do I need Kubernetes to use services from multiple clouds?

No. Any compute environment can call another cloud’s services through its APIs. Control Plane-managed locations need no cluster of your own, and teams that want Kubernetes can run workloads on their own clusters or on Control Plane’s Managed Kubernetes.

What is workload identity federation?

Workload identity federation lets a workload authenticate to a cloud provider by presenting a token from a trusted identity issuer. The provider verifies the token and issues short-lived credentials. AWS, GCP, and Azure all support it. See Control Plane’s guide to workload identity federation.

Can an application on AWS call Azure OpenAI without storing an API key?

Yes. Microsoft Entra workload identity federation exchanges a trusted token, such as one from AWS IAM outbound identity federation, for a short-lived Microsoft Entra access token for an identity that holds the Cognitive Services OpenAI User role. On Control Plane, Universal Cloud Identity issues that access at runtime.

How do I handle failures when one cloud provider’s service is down?

Give every cross-cloud call a timeout, retries with exponential backoff and jitter, and a fallback. Buffer writes to external services in a durable queue so they flush when the service recovers, and for critical features keep a fallback on a different provider or a degraded mode.

How do I get one view of calls across AWS, GCP, and Azure?

Instrument the application with OpenTelemetry and propagate trace context between your own services. Record provider request IDs, latency, and status codes on the client spans for managed-service calls, and send traces, metrics, and logs to one backend. On Control Plane, workload telemetry is built in and can feed your existing observability stack.

Can I start with one cloud and add another later?

Yes. Most teams start on one cloud and add cross-cloud calls as they adopt services from other providers. Set up identity federation and networking patterns early so each new service follows the same pattern. On Control Plane, you add a location on another cloud to the workload’s GVC, and workloads in that GVC deploy to the new location from their existing definitions.

What is the biggest hidden cost of using services from multiple clouds?

Operational complexity. Egress fees get attention, but the ongoing work of managing different IAM models, SDKs, error handling, billing systems, and compliance requirements across providers can exceed them. Centralizing identity, observability, and policy reduces it.

To run one application across AWS, GCP, and Azure with identity on all three, talk to the Control Plane team or sign up free.

Originally published on the Control Plane blog.