Control Plane vs AWS (ECS, EKS, Fargate)

Control Plane runs in your AWS account, and can run on GCP, Azure, and on-prem at the same time, so this is not about leaving AWS. ECS, Fargate, and EKS run your containers on AWS alone, tied to AWS IAM, VPC networking, and billing. The difference is architectural: with Control Plane, your workloads and their identity and networking live one level above any single provider, so AWS becomes a place your platform runs instead of the thing your platform is made of.

The core difference: AWS-native primitives vs a cloud-agnostic layer

ECS, Fargate, and EKS are AWS-native container services. ECS is AWS's own orchestrator, Fargate is the serverless way to run ECS or EKS tasks without managing servers, and EKS is managed Kubernetes. All three integrate with AWS-only services: AWS IAM for identity, VPC for networking, CloudWatch, and ALB. That integration exists only on AWS, and with EKS you still operate a cluster and its node groups.

Control Plane sits one level up as a cloud virtualization platform. It turns any mix of clouds, regions, Kubernetes clusters, and on-prem servers into one virtual cloud, so you build your own cloud rather than adopting a single provider's. You deploy standard containers to that layer. They run across AWS, GCP, Azure, and your own servers under one identity and network model, with nothing to operate underneath. It is built on Kubernetes, but on Control Plane's managed compute you never have to operate a cluster or bring Kubernetes expertise to do so. Teams that already run Kubernetes keep that option: Managed Kubernetes (MK8s), where Control Plane operates fully managed Kubernetes clusters for you, and Bring Your Own Kubernetes (BYOK), where you connect and run your own existing clusters under Control Plane, both sit alongside the managed compute. The resource model is simple: an Org contains GVCs (global virtual clouds), and a GVC contains Workloads.

The same model extends past containers. Control Plane runs full Linux and Windows virtual machines as first-class workloads next to serverless, standard, stateful, and cron containers, so VM-based apps lift in as they are and containerize on your schedule instead of being re-architected first. Sandboxes do the same for AI agents and untrusted code: isolated workloads you create and tear down like any other, under the same identity, network, and deployment model. On AWS those shapes live in separate services with separate models, EC2 for VMs and ECS or EKS for containers; here they are entries in one deployment surface.

Why teams look past AWS-only

AWS-native services couple your platform to AWS by design. When your compute, identity, and networking are ECS tasks, AWS IAM roles, and VPCs, your platform is portable in name only. Moving later means re-plumbing IAM, rebuilding networking, and renegotiating billing. All of that raises the cost of ever leaving and weakens your position at renewal time.

The drivers that push teams to a cloud-agnostic layer are concrete: resilience against a single provider's outages or region failures, data sovereignty rules that require workloads in specific jurisdictions or clouds, cost leverage from running where each workload is cheapest, and acquisitions that suddenly leave you operating across two or three clouds at once. Adopting a portable layer early is far easier than retrofitting one later, once your compute, identity, and networking are already wired to AWS IAM, VPC, and billing.

Which one should you pick?

Control Plane vs AWS, side by side

What credential-free access actually looks like

"Credential-free" can sound like magic until you see the configuration. On Control Plane, cloud access is declared on an identity, and the workload links to it. This is the entire setup for a workload that needs an S3 bucket:

kind: identity
name: my-app-identity
gvc: my-gvc
aws:
  cloudAccountLink: //cloudaccount/my-aws
  policyRefs:
    - my-app-s3-policy   # or an AWS-managed policy: aws::AmazonS3ReadOnlyAccess
---
kind: workload
name: my-app
gvc: my-gvc
spec:
  identityLink: /org/my-org/gvc/my-gvc/identity/my-app-identity

Control Plane provisions a matching least-privilege IAM role in your AWS account and hands the workload short-lived credentials at runtime through the native identity interface, the same way an EC2 instance receives its role. The AWS SDK finds them with zero configuration in your code, no keys are stored anywhere, and the identity works the same whether the workload happens to be running on AWS, GCP, Azure, or on-prem. The full mechanics are in the identity docs.

Which fits your scenario

Control Plane fits: a team that cannot afford to be anchored to one cloud. Picture a company running its platform on AWS today, but facing a data-sovereignty rule to keep some workloads in the EU, or absorbing an acquisition that runs on GCP. The platform layer absorbs both events instead of the team: EU workloads deploy to EU regions, the acquired GCP estate joins the same deployment surface, and nothing about identity or networking gets rebuilt per cloud. Each workload keeps reaching native services like S3, DynamoDB, or BigQuery credential-free through Universal Cloud Identity, with no Kubernetes cluster anyone is forced to operate.

What AWS-native is. ECS, EKS, and Fargate run containers on AWS alone, integrated with AWS IAM, VPC, CloudWatch, and the surrounding tooling. Even if you run only on AWS today, Control Plane runs the same containers in your own AWS account with no cluster you are required to operate, credential-free access to those AWS services, and true scale-to-zero, and it leaves you free to add another cloud later without re-plumbing IAM and networking. Adopting it early costs nothing and removes the lock-in that AWS-native primitives build in.

Why teams consolidate on Control Plane. The moment resilience, data sovereignty, cost leverage, virtual machines, or workloads spanning more than one cloud enter the picture, AWS-native primitives stop being enough, and re-plumbing IAM and networking later is far harder than adopting a portable layer early. With the portable layer in place, adding a cloud is a deployment target rather than a migration project, and you keep the whole AWS ecosystem without running two platforms.

What about Control Plane's own cost? A fair question: Control Plane is itself a paid layer, and cutting your AWS bill only counts if your total spend goes down. Control Plane bills on consumption, and the layer pays for itself through what it eliminates. Scale-to-zero stops billing for idle services, Capacity AI right-sizes CPU and memory from actual usage so you pay for what workloads consume rather than what someone once reserved, and the observability, load balancing, and security extras that appear as separate line items on an AWS bill are built in. That mechanism, not a discount, is how teams typically cut cloud compute costs 30 to 50 percent, and how SAFE Health cut AWS spend by 75%.

Frequently asked questions

• Is Control Plane a replacement for AWS ECS, EKS, or Fargate?

  Yes, and it runs in your AWS account too, so it is not about leaving AWS. ECS, EKS, and Fargate run your containers only on AWS, tied to AWS IAM, VPC networking, and AWS billing. Control Plane runs the same standard containers across AWS, GCP, Azure, and on-prem as one layer in your own cloud accounts, with credential-free cross-cloud access to native services and no Kubernetes cluster you have to operate. It gives you AWS and every other cloud under one identity and network model, so your platform is not locked to a single provider.

• Does Control Plane run on AWS or does it replace AWS?

  It runs on AWS, in your own AWS account, and also on GCP, Azure, and on-prem at the same time. Control Plane is a cloud virtualization platform that turns any mix of clouds, regions, Kubernetes clusters, and on-prem servers into one virtual cloud. You keep using AWS; you just stop being locked to only AWS for compute, identity, and networking.

• How does Control Plane handle access to AWS services like S3 and DynamoDB?

  Through Universal Cloud Identity, which gives each workload credential-free, least-privilege access to native cloud services using temporary session credentials, regardless of which cloud the workload runs in. A workload running on GCP can call DynamoDB or read from S3 with a real AWS IAM role. A workload on AWS can reach BigQuery or Microsoft Entra ID the same way, with no long-lived keys to store or rotate.

• What is the difference between AWS-native container services and Control Plane?

  ECS, EKS, and Fargate are AWS-native primitives. They integrate with AWS-only services, and tie your platform to AWS IAM, VPC networking, and AWS billing. With EKS you still operate a cluster. Control Plane is a cloud-agnostic layer one level above the providers: your workloads, identity, and networking are defined once and placed on any mix of AWS, GCP, Azure, and on-prem in your own accounts, with no cluster to operate and credential-free access to each cloud's native services.

• Does Control Plane just shift my AWS bill somewhere else?

  No. Control Plane bills on consumption, and the savings come from what the platform eliminates rather than from moving spend: scale-to-zero stops billing for idle services, Capacity AI right-sizes CPU and memory from actual usage, and observability, load balancing, and security extras that are separate line items on an AWS bill are built in. Teams typically cut cloud compute costs 30 to 50 percent net of the platform.

• Do I have to operate a Kubernetes cluster with Control Plane?

  You never have to. Control Plane is built on Kubernetes, but its managed compute means there is no control plane to run, no nodes to patch, and no Kubernetes expertise needed to ship. Teams that want Kubernetes keep it: Managed Kubernetes (MK8s) has Control Plane operate fully managed clusters for you, and Bring Your Own Kubernetes (BYOK) connects your existing clusters under Control Plane. That contrasts with EKS, where operating the cluster and its node groups is mandatory. ECS and Fargate reduce AWS-specific operational surface but do not remove it. You deploy workloads and Control Plane handles the rest.