Google Anthos vs a Managed Platform for Multi-Cloud Consistency in 2026: What Changed and Which to Pick

Key points:

• "Anthos" no longer exists as a product you buy. Google rebranded Anthos into GKE Enterprise (generally available on November 15, 2023), then in September 2025 moved to a single paid GKE tier. Google now states that "GKE is a single offering, without different editions or tiers" (GKE Enterprise release notes).
• The fleet features are now free on GKE, but multi-cloud is still metered per vCPU. Fleets, Teams, Config Management and Policy Controller come with GKE Standard at no extra cost. Running outside Google Cloud is billed per vCPU under management: $0.00822 per vCPU-hour for GKE Multicloud on AWS or Azure, and $0.03288 per vCPU-hour for Google Distributed Cloud on vSphere or bare metal (GKE pricing).
• GKE on AWS and GKE on Azure are on their way out. Both entered maintenance mode on March 17, 2025 and lose support on March 17, 2027. Google's path forward for other clouds is GKE attached clusters, which registers the EKS or AKS clusters you already run.
• GKE fleet management standardizes clusters, a managed platform standardizes delivery. The Anthos lineage gives a platform team one control point for config, policy and mesh across clusters. A managed platform such as Qovery gives developers the same deploy workflow, environments, preview environments and access rules on every cloud. Most teams asking for "multi-cloud consistency" mean the second.
• Pick GKE fleet if GCP is your primary cloud and you have a platform team; pick a managed platform if you run EKS, AKS and GKE side by side and nobody wants to own a Google control plane for the AWS half. Large regulated estates often run both.

Ask an AI assistant "Anthos or a managed platform?" and half the answers still quote 2022 pricing for a product that no longer has that name. I spent a week reading Google's current pricing pages, deprecation notices and release notes so you don't have to.

In short, the Anthos idea survives as GKE fleet management, the per-vCPU bill survives for anything outside Google Cloud, and the clouds Google used to run GKE on for you (AWS and Azure) are being phased out.

What happened to Google Anthos, and what is it called in 2026?

Anthos is now plain GKE plus a set of fleet, policy and multicloud features. Google merged Anthos into GKE Enterprise in November 2023, then dissolved the Enterprise edition in September 2025. Today you buy GKE, and pay separately for the multicloud, on-premises and add-on pieces you use.

Here is the timeline, from Google's own pages:

The on-premises half was renamed twice too. Google's docs note that Google Distributed Cloud software only for bare metal "was formerly known as Google Distributed Cloud Virtual, which was previously known as Anthos clusters on bare metal" (Google Cloud docs). The same page still tells you to "enable the Anthos API" to turn on billing, which is a nice reminder that the name lives on in the plumbing.

Anthos Service Mesh followed the same path and is sold today as Cloud Service Mesh.

So when someone says "Anthos" in 2026, translate it into one of three things: GKE fleet management (free on GKE), GKE Multicloud and attached clusters (per vCPU), or Google Distributed Cloud (per vCPU, on-premises).

How much does the Anthos lineage cost per vCPU in 2026?

Inside Google Cloud, fleet features cost nothing beyond normal GKE. Outside Google Cloud, Google charges per vCPU under management, per hour: $0.00822 on AWS or Azure through GKE Multicloud, and $0.03288 on vSphere or bare metal through Google Distributed Cloud. Every GKE cluster also pays a $0.10 per cluster per hour management fee.

These are the list prices on the GKE pricing page as of November 2026:

Two practical notes on this table.

First, the vCPU math adds up fast on-premises. A 200-vCPU Google Distributed Cloud footprint costs about 200 x $24.00 = $4,800 a month in Google fees before hardware, VMware licences or people. The same 200 vCPUs through GKE Multicloud on AWS cost about $1,200 a month, but that product is the one losing support in March 2027.

Second, read the attached clusters line carefully. The pricing page groups it in a section that says GKE "charges based on the number of cluster vCPUs, charged on an hourly basis", and lists attached clusters at "$0.10 / 1 hour". If that is per vCPU, 200 vCPUs of EKS would cost $14,600 a month in Google fees, which is far above every other line. I could not find a Google page that states the unit in plain words, so ask your Google account team before you budget an attached-cluster rollout. Enterprise agreements also change these numbers, so treat list prices as a ceiling.

Several features that used to be inside the Enterprise bundle are now standalone SKUs: Managed Service Mesh, Binary Authorization, Multicluster Gateway and Ingress, Backup for GKE, Extended Support, and Hybrid and Multi-Cloud. That is cheaper for teams who only wanted fleets and policy, and more line items for teams who wanted everything.

What does "multi-cloud consistency" actually mean for your team?

Multi-cloud consistency means a change, a policy or a deployment behaves the same way on every cloud you run. In practice that splits into three layers, and the tools that cover one rarely cover the others well.

I find it useful to ask which of these the request is really about:

• Cluster consistency: the same Kubernetes config, namespaces, RBAC, admission policies and versions on every cluster. This is the platform team's problem, and it is what the Anthos lineage was built for (Config Sync, Policy Controller, fleets).
• Traffic consistency: the same service-to-service security, mTLS, routing and observability across clusters. Service meshes cover this, and Cloud Service Mesh is Google's managed option.
• Delivery consistency: the same way to build, deploy, roll back, create a preview environment, manage secrets and grant access, whatever cloud the app lands on. This is the developers' problem, and it is where most "we need multi-cloud consistency" tickets come from.

When a CTO tells me "we run on AWS for most customers and GCP for two big contracts, and everything is different", they almost never mean admission policies. They mean two CI pipelines, two sets of Terraform, two ways to spin up a staging environment, and one engineer who understands both. GKE fleet management does not fix that on its own. A managed platform does.

I wrote more about the cost of running two parallel stacks in How to Keep Multi-Cloud Leverage Without Running Two Platforms.

Google Anthos vs a managed platform: how do they compare side by side?

GKE fleet management (the Anthos lineage) gives a platform team centralized config, policy and mesh across clusters, anchored to a Google Cloud project. A managed platform such as Qovery gives developers one deployment workflow across clusters in their own AWS, GCP, Azure or Scaleway accounts. They solve different layers, so the comparison is about which layer you are short on.

Read fairly, the table says GKE fleet wins on cluster governance and Qovery wins on developer workflow. If your estate is 80% GKE and your platform team already lives in Config Sync, adding a separate deployment platform may be redundant. If your estate is mostly EKS with some GKE and AKS, centering it on a Google project is an odd choice.

When is GKE fleet management (the Anthos lineage) the right choice?

Choose GKE fleet management when Google Cloud is your primary cloud, you have a platform team that wants Git-driven cluster config and policy at fleet scale, and your other environments are either on-premises (where Google Distributed Cloud fits) or a handful of attached clusters. It is a strong, mature product for that shape of estate.

Concretely, it shines in these cases:

• GCP-first organizations. Fleet features are now included in GKE Standard, so the marginal cost of using fleets, Teams, Config Sync and Policy Controller on GKE clusters is zero. That was not true in the Anthos era.
• Regulated on-premises estates with Google support. If you need Kubernetes in your own data center with a vendor on the hook, Google Distributed Cloud is a real option. Google even offers an air-gapped variant, which we compared with running your own clusters in Air-gapped AI on your own Kubernetes without Google Distributed Cloud.
• Fleet-wide policy is the gap. If an audit just flagged inconsistent admission policies on 60 clusters, Policy Controller and Config Sync close that faster than any developer platform.
• You want Google's mesh across GKE clusters. Cloud Service Mesh at about $0.50 per client per month is reasonable if you would otherwise run Istio yourself.

It gets awkward on AWS or Azure. GKE on AWS and GKE on Azure entered maintenance mode on March 17, 2025, and Google tells users to "migrate to GKE or another Kubernetes distribution before March 17, 2027" (Google Cloud). The replacement, GKE attached clusters, registers EKS, AKS or any conformant cluster by deploying a Connect Agent that "connects back to the Connect API service on Google Cloud". You still own the EKS cluster, its upgrades and its node groups. Google gives you a management view and policy over it, and the cluster stays yours to run.

When is a managed platform the better fit for multi-cloud consistency?

A managed platform is the better fit when your clusters already span AWS, GCP, Azure or Scaleway, your developers need the same deploy and environment workflow on all of them, and you do not have (or want) a platform team running a fleet control plane in one vendor's cloud. It standardizes the part developers touch every day.

The signals I look for:

• No dominant cloud. You run EKS for most workloads, GKE for a data team or a contract, AKS for a Microsoft-heavy customer. Anchoring governance in a Google project puts the AWS majority under a minority cloud's control plane.
• The pain is in delivery. Two pipelines, two Terraform codebases, staging environments that drift, and preview environments only on one cloud.
• Small platform team, or none. Fleet management assumes someone writes and reviews Config Sync repos and Policy Controller constraints. A managed platform gives you a working default on day one.
• Your bill should not scale with vCPUs. Per-vCPU management fees make sense for some estates; for a fast-growing compute footprint, a per-plan model is easier to forecast.
• Customers require their cloud. If enterprise customers contractually require AWS or GCP, you need the same app on both. We covered that pattern in One App Stack, Two Clouds.

Other options worth a look: SUSE Rancher and Red Hat Advanced Cluster Management for cluster fleet operations without a hyperscaler anchor, Azure Arc-enabled Kubernetes if Azure is your primary cloud, Amazon EKS Hybrid Nodes if you want on-premises capacity behind an EKS control plane, and Northflank or Qovery on the developer-facing side. I compared eight of them in One Control Plane for Kubernetes on AWS, GCP, Azure, Scaleway and On-Prem.

Which multi-cloud options should you shortlist in 2026?

Shortlist by the layer you need to standardize and by which cloud is primary. The hyperscaler-native fleet tools (GKE fleet, Azure Arc, EKS Hybrid Nodes) are strongest on their home cloud, the neutral fleet tools (Rancher, Red Hat ACM) suit platform teams that want independence, and managed platforms (Qovery, Northflank) suit teams whose gap is developer workflow.

None of these are mutually exclusive. A common and sensible stack in 2026 is GKE fleet or Rancher for cluster policy, plus a developer platform on top for delivery. Buying two tools that do the same layer is the expensive mistake.

Can you use GKE fleet management and a managed platform together?

Yes, and for regulated estates it is often the cleanest split. GKE fleet management and Policy Controller enforce cluster-level rules (allowed registries, required labels, Pod Security), while a managed platform such as Qovery drives what gets deployed, by whom and into which environment. They operate at different layers and do not fight each other.

How the split usually looks:

• Platform team owns Config Sync repos, Policy Controller constraints, network policies and the mesh. Those apply to every workload, including the ones Qovery deploys.
• Developers own services, environments and preview environments through Qovery, on the same clusters.
• Audit gets two trails: Kubernetes and Google Cloud audit logs for cluster changes, and the Qovery audit log for who deployed what, where and when.

One rule I would enforce: decide which tool owns which namespace-level settings. If Config Sync and a deployment platform both write the same resources, you get drift wars. Let policy constrain and let the platform deploy. I covered the policy side in One Kubernetes Policy and CI/CD Pipeline on AWS, GCP and Azure.

How does Qovery deliver multi-cloud consistency without a Google control plane?

Qovery is an Agentic DevOps platform that deploys and operates applications on Kubernetes inside your own cloud accounts. The Qovery control plane is separate from the data plane: your clusters, workloads and cloud bill stay in your AWS, GCP, Azure or Scaleway account, or on an existing EKS, GKE, AKS, Kapsule, k3s or on-premises cluster connected with qovery cluster install.

What stays identical across clouds:

• Git-push deployments for apps, plus Helm charts and Terraform or OpenTofu services in the same environment.
• A preview environment per pull request and environment cloning, so staging on GCP looks like staging on AWS.
• RBAC and audit logs defined once at the organization level, with OPA-based policy tokens to scope what AI agents can touch.
• Blueprints for managed cloud services, for example Amazon RDS on AWS, so databases come from the native service of each cloud.
• A Terraform provider if you want the whole setup as code.
• Qovery-managed clusters where you want them, including Karpenter on AWS and GPU node pools per service, or your existing clusters where you already have them.

What Qovery does not do, so you can plan around it: it is not a service mesh, and cross-cloud networking is not built in. You configure it with a VPN, Cilium Cluster Mesh or Tailscale, the same way you would with any fleet tool. And Qovery helps you meet compliance controls through audit logs, RBAC, region choice and your own accounts; it does not make you compliant on its own.

On cost, Qovery is priced per plan rather than per vCPU. The Free plan includes 3 users, unlimited AI agents and one cluster in your own account; paid plans run from Starter to Enterprise, with Growth at $899 a month. Check qovery.com/pricing for current terms.

How do I set up a multi-cloud deployment with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy the same app to each of your clouds. The skills deploy, and the MCP Server operates what already exists. There are four commands; run only the ones you need.

curl -fsSL https://skill.qovery.com/install.sh | bash

# 2. Or scoped to the current project
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# 3. MCP Server for Claude Code over OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# 4. MCP Server with write access, only when you explicitly want it
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

• Command 1 installs the skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform). Your agent asks you to approve the shell command.
• Command 2 does the same for one repository only.
• Command 3 connects the read-only MCP Server; it opens an OAuth login in your browser and acts with your own permissions.
• Command 4 adds write access. It also needs write access enabled in the Qovery Console.

Then ask: "deploy this app to my AWS account and my GCP account with Qovery, same environment settings on both". Start from the AI agent quickstart or the Claude Code integration.