Google Anthos was Google Cloud’s platform for running and governing Kubernetes clusters across on-premises data centres, other public clouds and the edge from a single control point. The product name has since moved twice. This guide explains what the platform does, how its parts fit together, and where the operating cost sits.
Quick Overview
What you’ll learn:
- What Anthos was built to solve, and which product name carries that work today
- How fleets turn a scatter of clusters into one administrative object
- How Config Sync, Policy Controller and the service mesh divide the governance job between them
- What changes when clusters run on VMware, on bare metal, or inside AWS and Azure
- How identity, storage and delivery behave once environments stop being uniform
- Where the money goes, and which part of the bill does not move
Who this article is for:
- Platform engineers inheriting a multi-cluster estate
- Architects deciding whether a single control plane is worth its operating cost
- IT managers weighing a hybrid strategy against consolidation into one provider
Reading time: 32 minutes
What Anthos Was — and What the Product Is Called Now
Anyone researching Anthos today needs the naming history before anything else, because the console will not show them a product with that name.
Anthos launched as Google Cloud’s answer to a specific customer shape: an enterprise running Kubernetes in more than one place and operating each place differently. Its components carried the brand — the GKE Enterprise release notes archive monthly component releases for Anthos clusters on VMware, Anthos clusters on bare metal, Anthos clusters on AWS and Anthos clusters on Azure, with the archived series running through December 14, 2022. The brand was then retired in favour of GKE Enterprise, a premium tier of Google Kubernetes Engine. That is where most of the surviving third-party writing about the platform stops.
It has moved again since. The same release notes page now states that the features that were part of GKE Enterprise have become part of the standard Google Kubernetes Engine offering, or exist as products you can use in addition to GKE, and that GKE is a single offering without different editions or tiers. Read plainly, that is the end of the separate-product era: fleet management, configuration sync, policy enforcement and the service mesh are no longer things you buy alongside GKE, they are things GKE has.
The practical consequence for a reader is worth stating bluntly, because it changes what to search for. Documentation, pricing pages and console labels use the GKE vocabulary. Job adverts, internal runbooks and vendor decks written before the change still say Anthos. Both refer to the same set of mechanisms, and this article describes those mechanisms rather than the label attached to them in any given quarter.
What has not changed is the design idea, and that is why the material remains worth learning. The platform’s premise is that a Kubernetes cluster should be an interchangeable target: the same manifest, the same policy, the same identity model and the same observability regardless of whether the cluster sits in a Google region, a colocation rack or another provider’s account. Everything else in the architecture follows from that premise. When teams describe the platform as “Kubernetes with extra buttons”, they are describing the parts they installed and not the part that matters — the shift from managing clusters individually to managing a population of them.
The honest counterpoint belongs here too. A platform that normalises many environments only pays for itself when you genuinely have many environments. An organisation with one cloud account and one cluster gets the operating overhead and none of the leverage.
The Problem It Was Built For: Estates That Grew in Several Directions
Large IT estates rarely arrive at hybrid architecture by choosing it. They arrive by accumulation: a data centre that predates the cloud strategy, a lift-and-shift programme that moved some workloads, an acquisition that brought a second provider, and a regulated system nobody is willing to move at all.
The result is operational fragmentation, and it is more expensive than it looks on an architecture diagram. Each environment brings its own console, its own access model, its own deployment scripts and its own monitoring conventions. The cost is not primarily the tooling licences — it is that the knowledge required to operate the estate stops being transferable between teams. An engineer fluent in the on-premises environment cannot cover for one who owns the cloud environment, which turns holiday cover into a risk register entry.
Migration is the second recurring problem. Moving a business-critical application to the cloud is expensive and risky, and the risk concentrates at the cut-over. A platform that runs identically on both sides of the move changes the shape of that risk: the application can be containerised in place, run in production on the existing infrastructure, and relocated later as a scheduling decision rather than a rewrite. That is a genuinely different project plan, not a marketing reframe of the same one.
Security is where fragmentation is most costly and least visible. When each environment has its own policy mechanism, “we require encryption in transit” becomes a sentence that is true in some environments and unverified in the rest. Audits then consume weeks of manual evidence-gathering, and the evidence is a snapshot that expires the moment someone changes a configuration by hand.
The fourth driver is modernisation. Legacy applications need somewhere consistent to land as they are decomposed, and a platform that behaves the same everywhere lets that decomposition proceed one service at a time instead of as a single high-stakes programme.
Problems and the mechanism that answers them
| Problem | Mechanism | What changes operationally |
|---|---|---|
| Fragmented consoles and processes | Single control plane over registered clusters | Skills and runbooks become transferable between environments |
| Risky cloud migration | Identical runtime on both sides of the move | Relocation becomes a scheduling decision, not a rewrite |
| Inconsistent security posture | Centrally declared and enforced policy | Compliance evidence is generated, not assembled by hand |
| Stalled modernisation | Uniform target for decomposed services | Legacy decomposition proceeds service by service |
None of these are solved by the platform on its own. Each is solved by the platform plus a decision about who owns the central definition — and that ownership question is the one organisations postpone.
Kubernetes as the Substrate
The platform is not an alternative to Kubernetes; it is an opinionated arrangement of Kubernetes clusters. Everything above it inherits Kubernetes’ semantics, and the parts of the platform that feel unfamiliar are almost always the parts that coordinate across clusters rather than inside one.
Three inherited properties do the load-bearing work. The first is the declarative model: you state the desired state of a workload and controllers reconcile the observed state towards it. That is what makes centralised configuration possible at all — if deployment were an imperative script, a central definition would only describe the moment it ran, not the state it produced.
The second is the standard object vocabulary. Pods, Services, Deployments, ConfigMaps, StatefulSets and namespaces mean the same thing in every conformant cluster. A manifest written against that vocabulary is portable in a way that a provider-specific template is not, which is why the platform’s portability claim is a property of Kubernetes rather than an addition to it.
The third is self-healing. Controllers detect failed containers, unhealthy nodes and drifted replica counts and act on them without a human in the loop. Extended across a fleet, this is what makes it defensible to operate many clusters with a small team: the routine failures are absorbed locally and never reach the central console.
What the substrate contributes
| Kubernetes property | What it makes possible above the cluster | What it does not cover |
|---|---|---|
| Declarative state | A central definition that describes a result, not a moment | Who is allowed to change that definition |
| Standard object vocabulary | Manifests that mean the same thing in every environment | How the infrastructure underneath behaves |
| Self-healing controllers | Routine failures absorbed locally, never centrally | Failures that span clusters |
| Namespaces and labels | A naming scheme that fleets can treat as shared | Agreement on what those names mean |
The limit of the inheritance is worth naming. Kubernetes standardises the inside of a cluster and says nothing about the relationship between clusters. There is no upstream concept of “the same namespace in eleven clusters”, no upstream mechanism for pushing a policy to a group, and no upstream identity that spans installations. Every distinctive feature of this platform exists in that gap, which is also why those features are the ones that behave unexpectedly when a team assumes cluster-local intuitions still hold.
If the cluster-level material underneath all of this is not yet solid, the platform will amplify the gap rather than cover it — our guide to Kubernetes in practice: architecture and application management covers the substrate this article assumes.
The Component Map
The platform is best understood as a small number of components with clearly separated jobs, rather than a suite. Each one answers a question the others deliberately do not.
GKE provides the clusters themselves — managed control planes, node lifecycle, autoscaling and integration with the surrounding cloud services. In the hybrid arrangement, the same product name covers clusters running on Google infrastructure, clusters running in a customer data centre, and clusters running inside another provider’s account.
Fleets provide the grouping. A fleet is the administrative object that turns a set of clusters into something you can address collectively — the prerequisite for every feature that operates on more than one cluster at a time.
Config Sync provides configuration delivery. It continuously reconciles cluster state against a central source of truth, which is what turns “we agreed on a standard” into a state the cluster actually holds.
Policy Controller provides enforcement. It refuses non-compliant resources rather than reporting on them afterwards, which is the difference between a control and a dashboard.
Cloud Service Mesh, historically Anthos Service Mesh, provides the network layer between services: routing, mutual authentication and telemetry, added without changes to application code.
Component responsibilities
| Component | Question it answers | Question it does not answer |
|---|---|---|
| GKE | Where do containers run, and who keeps the cluster alive | How is this cluster related to the others |
| Fleets | Which clusters are governed together | What configuration do they hold |
| Config Sync | What state should every cluster be in | Which states are permitted |
| Policy Controller | Which resources are allowed to exist | How do services reach each other |
| Cloud Service Mesh | How do services communicate, and under whose identity | What runs inside the containers |
Reading the table left to right gives the adoption order most teams end up following whether or not they planned it: clusters, then grouping, then configuration, then enforcement, then the network. Teams that start at the mesh — usually because it is the most interesting component — end up operating a sophisticated network layer over an estate whose configuration still drifts.
Fleets: Many Clusters Treated as One
The fleet is the concept that separates this platform from a collection of independent clusters, and it is the one most often skimmed.
A fleet is a logical grouping of clusters administered together. Its implementation is rooted in a Google Cloud project, referred to in Google’s How fleets work documentation as the fleet host project, and that page is explicit that a given project can only have a single fleet associated with it, or none. The restriction is deliberate rather than incidental: it forces the project boundary to carry the isolation between things that are not governed together. The same page notes that only Kubernetes clusters can currently be fleet members.
That single sentence about projects has more design consequence than it appears to. Because a project holds at most one fleet, “which fleet does this cluster belong to” is answered by the project structure you already maintain for billing and access. Organisations that separated production from non-production at the project level find the fleet boundary already drawn; organisations that put everything in one project discover that they have to choose.
The second concept to absorb is sameness. The How fleets work page describes it as the assumption that certain Kubernetes objects sharing a name across clusters — namespaces being the primary example — are treated by fleet-enabled features as if they were the same thing. This normalisation is what makes cross-cluster features tractable, and it is also a constraint that reaches back into how you name things. If two teams independently used a namespace called backend for unrelated systems, sameness will treat them as one, and the fix is a rename rather than a setting.
Registration is the mechanical step. A cluster joins the fleet by having an agent installed that establishes an authenticated connection back to the control plane, after which the cluster appears in the central inventory and becomes a valid target for fleet-scoped configuration.
Membership also unlocks resources defined at the level of the group rather than the level of the cluster. A service can be declared once and exported across the fleet, so that a caller in one cluster reaches an implementation in another without either side encoding where it landed. The same level structure applies to governance: definitions can be attached at the organisation, at the fleet, or at an individual cluster, with lower levels inheriting what higher levels declared and overriding only where a documented reason exists.
The reason to care about the direction of that inheritance is operational rather than architectural. When a standard is declared at the top and inherited downwards, adding a cluster costs almost nothing — it arrives already governed. When standards are declared per cluster, every new cluster is a small project, and the estate’s growth rate quietly becomes a hiring argument. The difference does not show up in a proof of concept with a handful of clusters; it shows up in the second year, in the form of a backlog nobody can attribute to a decision.
What membership changes
| Before membership | After membership |
|---|---|
| Cluster is addressed individually, by its own endpoint | Cluster is addressable as part of a group |
| Configuration applied by whoever has credentials | Configuration delivered from a declared source |
| Namespace names are local conventions | Namespace names carry cross-cluster meaning |
| Inventory lives in a spreadsheet | Inventory is a property of the platform |
The operational verdict is that fleets move the unit of administration up a level, and that move is only free if your naming and project structure were already coherent. Where they were not, the fleet does not create the mess — it makes the mess addressable, which is uncomfortable but useful.
Config Sync and the GitOps Loop
Config Sync is the component that makes centralised configuration real rather than aspirational, and its behaviour is easy to describe precisely.
The Config Sync overview states that it continuously monitors a central source of truth and automatically reconciles the state of your clusters to match it, preventing configuration drift. It also names what may serve as that source of truth: a Git repository, an OCI image or a Helm chart. That flexibility matters more than it sounds, because it lets an organisation keep its existing artefact pipeline instead of adopting a second one just for cluster configuration.
The loop itself is unremarkable and that is the point. Configuration is written as manifests, reviewed and merged, and an agent in each cluster applies what the source says. Nobody holds cluster credentials to deploy configuration, because deployment is a merge. The Config Sync overview highlights the consequence directly: storing manifests in version control brings peer review, audit trails and straightforward rollbacks to configuration changes that previously happened through a terminal.
Drift correction is the part teams underestimate. A reconciling agent does not merely apply changes; it reverts unmanaged ones. An engineer who edits a live resource to resolve an incident will find the edit undone, and that behaviour is correct — but it needs to be understood in advance, because discovering it at three in the morning teaches the wrong lesson about the platform. The workable operational rule is that emergency changes go through the repository on a fast path, and the fast path is built before it is needed.
Hierarchy is the third feature. Configuration can be declared once at a level that covers many clusters and specialised where a particular environment genuinely differs. The discipline this imposes is that every deviation becomes visible as an explicit override rather than an accumulated difference nobody remembers making.
The failure mode is worth naming. A central repository with no ownership model becomes a shared mutable object with a commit log — better than untracked drift, but not by as much as the diagram suggests. Config Sync enforces the delivery; it does not decide who is allowed to change what.
Teams whose Kubernetes definitions have outgrown hand-maintained YAML usually meet this component alongside templating; our guide to managing deployments with Helm charts covers that step, and Helm charts are one of the source-of-truth formats this component accepts.
Policy Controller: Guardrails That Refuse Rather Than Report
Configuration delivery answers what clusters should contain. Policy enforcement answers what they are permitted to contain, and the distinction is not academic — a policy that reports violations after the fact is a monitoring feature, while a policy that refuses them is a control.
The Policy Controller overview states that the component is based on the open source Open Policy Agent Gatekeeper project and that it supports multiple enforcement points: audit and admission control for the cluster, plus an optional shift-left approach that analyses non-compliant changes before they are applied. The same page describes a library of prebuilt policies for common security and compliance controls, and the bundles named in its documentation map onto recognisable frameworks — CIS benchmarks, NIST publications, the NSA and CISA Kubernetes hardening guidance, PCI-DSS, and the upstream Pod Security Standards.
The prebuilt bundles are the underrated part. A bespoke policy set has to be written, reviewed, tested and defended to an auditor who has never seen it. A named bundle carries an external reference, which converts a conversation about opinions into a conversation about a published control set. That is a shorter conversation, and organisations under regulatory pressure feel the difference immediately.
Admission control is where the enforcement bites. A validating webhook evaluates each attempt to create or modify a resource and rejects what fails. The operational consequence is that non-compliant workloads fail at deployment time, in a pipeline, with an error message — rather than at audit time, in a report, with a remediation ticket.
Audit covers what admission cannot. Resources that existed before a policy was introduced, or that were created while enforcement was disabled, are found by periodic evaluation rather than at the gate. Any real rollout uses both: audit first to discover the scale of existing non-compliance, then admission enforcement once the backlog is small enough that turning it on does not halt every deployment in the estate.
The shift-left path is the one that keeps adoption politically survivable. Validating manifests in a pipeline, before they reach a cluster, means the developer who wrote the non-compliant resource is the person who sees the failure, at the moment they can still fix it cheaply.
Network segmentation belongs in the same conversation, since a policy engine that governs workloads and a cluster with a flat network protect different things — our guide to Kubernetes NetworkPolicy fundamentals and team responsibilities covers who owns that boundary.
Cloud Service Mesh: Traffic, Identity and Encryption Between Services
The mesh sits underneath application traffic and takes over the parts of service-to-service communication that would otherwise be implemented, inconsistently, in each application.
Its foundation is Istio, and Istio’s own security documentation is the precise reference for the behaviour that matters most in a hybrid estate. The Istio security documentation defines peer authentication modes for mutual TLS: PERMISSIVE, in which a workload accepts both mutual TLS and plain text; STRICT, in which it accepts only mutual TLS; and DISABLE, which the same page advises against unless another security solution is in place. When the mode is unset, it is inherited from the parent scope.
Those modes describe a migration path rather than a configuration menu, and reading them that way saves a great deal of trouble. Permissive mode exists so that a mesh can be adopted incrementally: workloads that have not yet joined keep working, and the estate is not required to change everywhere at once. The Istio security documentation says as much, describing permissive mode as most useful during migration and recommending the move to strict once workloads have been migrated. The failure this prevents is the familiar one — a security programme that must land simultaneously across every service, and therefore never lands at all.
Traffic management is the second capability. Requests can be routed on attributes such as headers or source, which is what makes progressive delivery patterns implementable without embedding release logic in application code. Retries, timeouts and circuit breaking move from a library each team chose independently into a layer configured once.
Telemetry is the third, and in a distributed estate it is often the reason the mesh gets funded. Because the proxies see every request, the mesh produces a consistent picture of service-to-service latency and error rates without instrumenting applications individually.
What the mesh takes over
| Concern | Without a mesh | With a mesh |
|---|---|---|
| Encryption between services | Per-application TLS, unevenly implemented | Declared per workload, enforced by the proxy |
| Retries and timeouts | A library choice per team | Configuration in one layer |
| Traffic shaping for releases | Release logic inside the application | Routing rules outside it |
| Service-level telemetry | Whatever each team instrumented | Uniform, collected at the proxy |
The cost is honest and should be budgeted: a mesh adds a proxy to every workload, a control plane to operate, and a new place for latency and failure to originate. It earns its keep in estates with enough services that per-application implementation has already produced inconsistency. Below that threshold it is a platform you operate for its own sake.
Clusters Outside Google Cloud: VMware, Bare Metal, AWS and Azure
The claim that makes this a hybrid platform rather than a cloud feature is that clusters run in places Google does not own, under the same management surface.
On-premises deployment takes either of the shapes an enterprise data centre actually has. Where virtualisation is already standardised on VMware, clusters are deployed onto vSphere, reusing existing hardware, licences and operational practice. Where there is no virtualisation layer, or no appetite to pay for one under a container platform, clusters are deployed straight onto physical servers. The bare-metal option removes a layer of licensing and a layer of abstraction, and it suits latency-sensitive and hardware-attached workloads for exactly that reason.
The other-cloud story is documented as its own product surface. The GKE Multi-Cloud documentation describes creating Kubernetes clusters in AWS and Azure environments, managed from the Google Cloud console, and lists the shapes available: GKE on AWS, GKE on Azure, and GKE Attached clusters for any CNCF-conformant cluster. The clusters integrate with provider-specific resources such as load balancers and persistent storage, which is the part that distinguishes this from running a generic distribution on someone else’s virtual machines.
Attached clusters deserve separate attention, because they change the adoption calculation. A cluster you already run — on another provider, on a different distribution, on hardware in a factory — can be registered and governed without being rebuilt. That converts the platform decision from a migration into an enrolment, and enrolment is a decision a team can reverse.
Deployment shapes and what each is for
| Shape | Where it runs | Typical reason to choose it |
|---|---|---|
| Managed clusters in Google Cloud | Google infrastructure | Lowest operational burden for new workloads |
| Clusters on VMware | Existing virtualised data centre | Reuses hardware, licences and operational practice |
| Clusters on bare metal | Physical servers | Removes a virtualisation layer; latency and hardware access |
| GKE on AWS or Azure | Another provider’s account | Data residency, existing commitments, provider-specific services |
| Attached clusters | Anywhere conformant | Governance without rebuilding what already runs |
The uncomfortable truth underneath the table is that uniformity is a property of the management surface, not of the environments. Storage classes, load balancer behaviour, node provisioning speed and failure modes still differ. What the platform standardises is how you describe, govern and observe those environments — which is most of the operational cost, but not all of it. Teams that have not yet built a cluster to production standard in a single environment will meet those differences at the worst possible moment; our complete guide to a production Kubernetes cluster rollout covers the baseline this section assumes.
Identity and the Connect Gateway
Identity is where hybrid architectures usually leak, because every environment arrives with its own answer and the answers do not compose.
The platform’s approach is to make cloud identity the single front door to every cluster. The GKE Multi-Cloud documentation describes the Connect gateway as the mechanism for connecting to clusters in any cloud using Google Cloud identity for authentication. Stated operationally: an engineer authenticates once, with the identity the organisation already governs, and reaches a cluster in another provider’s account without that cluster’s provider-native credentials being issued to them at all.
The consequence is the one security teams care about. Credentials that are never issued cannot be leaked, rotated late, or left active after an engineer changes role. Access review moves from “audit the credentials on each cluster” to “audit the group memberships in one directory”, and only the second of those is a task that stays current between audits.
Enterprise directory integration completes the picture. The identity service sits between corporate identity providers and the clusters, so the platform consumes the organisation’s existing source of truth for who people are rather than establishing a competing one. Group membership then drives cluster access, which means joiners and leavers are handled by the process that already handles them.
The design limit is worth stating. Centralising authentication does not centralise authorisation: what an authenticated principal may do inside a cluster is still Kubernetes role-based access control, defined per cluster unless something delivers it uniformly. This is precisely where configuration sync and identity meet — access bindings are configuration, and delivering them from a central source is what makes “the same person has the same rights everywhere” a verifiable statement rather than an intention.
The failure mode is a familiar one: organisations centralise the login, celebrate, and leave role bindings to accumulate locally. A year later the identity story is excellent and the permissions story is a spreadsheet.
Storage and Data Across Environments
Storage is the boundary where the portability story becomes conditional, and being clear-eyed about that is more useful than restating the marketing position.
The Kubernetes abstractions carry across environments unchanged. Storage classes, persistent volumes and persistent volume claims mean the same thing everywhere, so a workload requesting durable storage does so identically regardless of what is underneath. The Kubernetes Persistent Volumes documentation defines the access modes a claim may request: ReadWriteOnce, ReadOnlyMany, ReadWriteMany and ReadWriteOncePod. The same page draws a distinction that surprises people in production — ReadWriteOnce restricts a volume to a single node, and can still allow several pods to use it if they happen to be scheduled together, whereas ReadWriteOncePod restricts it to a single pod.
What does not carry across is what the underlying infrastructure will actually honour. An access mode that a cloud provider’s storage supports may be unavailable on the storage array in a data centre, and a claim that binds instantly in one environment can sit pending in another. The abstraction is genuinely portable; the guarantee behind it is a property of the environment. Any workload placement decision that ignores this produces a manifest that deploys everywhere and works in one place.
Replication between environments is the second problem, and it is not one the platform solves for you. Keeping data consistent across a data centre and a cloud region is a data-engineering problem with its own trade-off between synchronous and asynchronous approaches, and the platform’s contribution is that the compute layer stops being a variable while you work on it.
Regulatory placement is the third. Where data may physically reside is frequently the reason a hybrid architecture exists at all, and it is a constraint on scheduling rather than a feature to configure. The workable pattern is to treat data gravity as the fixed point and let workload placement follow it, which inverts the instinct to place workloads first and solve storage afterwards.
The verdict most teams reach eventually is that stateless workloads move freely, stateful workloads move with a project attached, and managed data services remain the default answer wherever they are available — a position our guide to Kubernetes and Docker in cloud application management reaches from the application side.
Delivery: One Deployment Model, Several Targets
Once clusters are uniform targets, the delivery pipeline simplifies in a way that is easy to underrate.
The immediate gain is that the deployment artefact stops branching by environment. A single set of manifests, parameterised where environments legitimately differ, replaces the family of scripts that accumulated one per destination. The pipeline builds an image, pushes it to a registry, and updates a declaration; the platform’s reconciliation loop carries it the rest of the way. Standard tooling — kubectl, Helm, Kustomize — behaves identically against every target, so the knowledge in the pipeline is transferable rather than environment-specific.
The second gain is that credentials leave the pipeline. In a GitOps arrangement the pipeline’s final act is a merge, not a deployment, and the agent inside the cluster pulls what changed. A build system that cannot reach clusters is a build system whose compromise does not immediately become a cluster compromise, and in a multi-environment estate that reduction in blast radius is the strongest security argument the model has.
Container image strategy is the part that stays hard, and the platform does not soften it. Images must be built for the architectures present in the estate, scanned before promotion, and stored somewhere reachable from every environment — including environments with restricted egress, which usually means a registry mirror and a decision about who maintains it. Teams weighing runtime and build tooling for that estate will find the practical differences set out in our Docker vs Podman vs containerd comparison.
Promotion between environments is the third piece, and the one where discipline shows. The portable pattern is that an image is built once and promoted by reference, never rebuilt per environment. Rebuilding produces artefacts that are almost identical, and “almost identical” is precisely the category of difference that surfaces in production and nowhere else.
The residual complexity is honest: uniform delivery does not make releases safe, it makes them consistent. Progressive rollout, database migration ordering and rollback rehearsal remain the team’s problem, and a consistent pipeline simply means the same problem shows up the same way everywhere.
What It Costs and Who Counts It
Cost discussions about container platforms tend to founder on the difference between the platform bill and the infrastructure bill, so it helps to separate them deliberately.
One component of the bill is fixed and easy to reason about. The Google Kubernetes Engine pricing page states a flat cluster management fee of $0.10 per cluster per hour, charged in one-second increments, applying to all clusters regardless of mode of operation, cluster size or topology. Because the figure is per cluster rather than per node, it is one of the few platform costs that scales with your architectural choices rather than your traffic — an estate that answers every isolation question by creating another cluster is choosing a recurring cost, and doing so in a way that never appears on a capacity dashboard.
Everything else scales with what runs. Compute, storage, networking and the managed services around the clusters follow their own meters, and in most estates they dominate. The platform’s contribution to that number is indirect but real: it standardises the requests and limits that determine how much infrastructure the scheduler has to reserve.
Over-requesting is where the money quietly goes. Resource requests set generously “to be safe” reserve capacity the scheduler cannot allocate to anything else, so a cluster reports itself full while a substantial share of what it reserved sits idle. This is not a cloud problem or an on-premises problem; it is a defaults problem, and it compounds across every environment simultaneously. The countermeasure is unglamorous — measure actual usage, set requests from measurement, and re-measure after every significant change.
Three further levers sit in the platform rather than in the invoice, and they compound.
Density is the first. Consolidating workloads onto fewer, better-utilised clusters raises the share of reserved capacity that is actually doing work, and it reduces the count that a per-cluster fee multiplies. The counterweight is blast radius: density and isolation pull against each other, and the defensible answer is a stated position rather than an accumulated default.
Elasticity is the second. Pod-level and node-level autoscaling only reach the bill when the node layer is genuinely allowed to shrink, which requires drainable workloads, disruption budgets and a tolerance for capacity that is not permanently warm. Estates that enable autoscaling and then pin their nodes for safety have bought the complexity and declined the saving.
Visibility is the third, and it gates the other two. Without attribution per team or per namespace, nobody can act on either lever, because nobody can see whose workload is responsible for the reservation. This is the point at which cost management stops being a dashboard somebody checks and becomes a practice with named owners.
Placement is the lever that hybrid architecture uniquely offers. When the same workload runs unchanged in several environments, where it runs becomes a cost decision rather than an architectural one, and the arithmetic can be done per workload class instead of per estate. Teams that want to run that arithmetic properly — with unit economics, shared responsibility for the bill and a defensible allocation model — will find the practice covered in the Advanced FinOps: multi-cloud optimisation and FinOps for AI course, which is where this stops being a technical exercise and becomes a financial one.
Where the platform bill divides
| Cost element | Scales with | Controlled by |
|---|---|---|
| Cluster management fee | Number of clusters | Isolation and topology decisions |
| Compute | Requested capacity, not used capacity | Requests, limits and autoscaler tuning |
| Storage | Provisioned volumes and their class | Retention policy and storage class defaults |
| Egress between environments | Cross-environment traffic patterns | Workload placement and data locality |
| Platform operations | People and their time | Degree of standardisation |
Cost levers and what each one requires first
| Lever | What it reduces | What it requires before it works |
|---|---|---|
| Density | Reserved-but-idle capacity, and the cluster count | An explicit position on isolation |
| Elasticity | Capacity held outside peak demand | Drainable workloads and disruption budgets |
| Placement | The rate paid for the same workload | Portability that has been tested, not assumed |
| Visibility | Nothing directly — it enables the others | Attribution the teams have agreed to |
The last row is the one omitted from most business cases and the one that decides them. A platform that standardises many environments reduces operational headcount growth; a platform adopted for a single environment adds a system to operate and returns nothing for it.
Where This Actually Gets Used
Four situations recur, and recognising which one applies is more useful than a generic capability list.
Deliberate multi-provider strategy. Organisations that operate in several clouds by choice — for negotiating position, for resilience, or because different providers genuinely do different things better — need one operational model over that choice, otherwise the strategy costs more than the leverage it buys. This is the case the platform was designed for, and it is also the case that most rarely exists in the pure form the diagrams assume.
Regulated workloads that cannot move. A bank, a hospital or a public institution frequently has systems that must stay in a specified jurisdiction or on specified infrastructure. Running those systems on the same platform as everything else means the constraint applies to placement rather than to architecture, and the team maintains one set of skills instead of two.
Legacy modernisation at enterprise scale. Organisations carrying a large estate of applications designed for traditional environments need a landing zone that does not force a single high-risk cut-over. Containerising in place, running in production on existing infrastructure, and relocating later is a sequence with checkpoints, and every checkpoint is a place the programme can stop without failing.
Edge and distributed operations. Retail branches, factories and remote sites need workloads running close to where the work happens, with central governance and intermittent connectivity. The fleet model fits this shape because the central plane governs and observes while each site keeps operating when the link drops.
DevSecOps at enterprise scale. Organisations that have standardised delivery but not security find the policy layer is the piece that lets the two converge. Controls declared once and enforced everywhere turn security from a review gate applied late into a property of the platform applied continuously, and the teams shipping software experience the change as faster approval rather than tighter constraint — provided the rollout was gradual enough that they never had to work around it.
Environment standardisation after an acquisition. Integrating an acquired company’s infrastructure is a programme with no natural end, because the estates were built on different assumptions by people who no longer work there. Bringing the acquired clusters under a single management surface does not merge the estates, but it does produce one inventory, one policy set and one access review — which is frequently the difference between integration finishing and integration being quietly renamed.
Use cases and the mechanism that carries them
| Situation | Mechanism that does the work | What to measure to know it worked |
|---|---|---|
| Multi-provider strategy | Fleets plus uniform delivery | Time to deploy the same service to a new provider |
| Regulated workloads | Placement policy plus consistent enforcement | Effort to produce compliance evidence |
| Legacy modernisation | Identical runtime on both sides of a move | Applications relocated without code changes |
| Edge operations | Central governance, local autonomy | Site behaviour during a connectivity outage |
| DevSecOps at scale | Enforced policy inside the delivery path | Lead time from merge to production approval |
| Post-acquisition integration | Single inventory and access review | Time to onboard an inherited cluster |
The fifth situation — “we have one cloud and want to be ready in case we adopt another” — is the one to be sceptical about. Optionality bought before it is needed is paid for continuously, and the flexibility a platform gives you is worth what you actually exercise.
What Gets Hard
The problems that dominate a mature hybrid estate are not the problems the first cluster teaches.
Version lifecycle across environments is the most persistent. A managed cluster in a cloud region and a cluster on hardware in a data centre do not upgrade on the same cadence or with the same effort, and the estate is only as current as its slowest environment. Upgrades have to be a standing commitment with owners and a schedule, because the alternative is not stasis — it is an accumulating migration that gets more expensive each quarter.
Networking between environments is the second, and it is the one that consumes unplanned weeks. Address ranges overlap, firewall rules are owned by a different team, and latency between a data centre and a cloud region is a physical fact that no amount of platform configuration will change. Designing the network before the platform is cheaper than discovering it afterwards, and the discovery usually happens during the first cross-environment failover test.
Skills concentration is the third and least technical. Platforms of this kind produce a small group who understand the whole picture, and estates where that group is small enough to fit around one table have a resilience problem that no architecture review will surface. Deliberate rotation and documented runbooks are the countermeasure; hoping the group stays is not.
Observability at fleet scale is the fourth. Metrics, logs and traces from many clusters in different environments have to arrive somewhere they can be correlated, and the volume grows faster than the estate. Retention policy becomes a real decision with a real bill, and the answer that keeps everything forever is an answer nobody costed.
Cost attribution is the fifth. Once workloads move between environments, “what did this service cost” needs an allocation model rather than an invoice, and the model has to survive contact with teams who disagree with it. Our practical guide to FinOps and cloud cost management covers the mechanics of building one that people accept.
Skills a Team Needs Before It Commits
The platform assumes competence rather than supplying it, and being honest about the prerequisite is the difference between a rollout and a rescue.
Kubernetes fluency is the floor, not the ceiling. Teams need to be comfortable with the object model, with diagnosing why a workload will not schedule or start, and with the tooling — kubectl, Helm, Kustomize — that surrounds it. A team that is still learning these will spend its energy on cluster-local problems and never reach the cross-cluster features that justify the platform.
Container practice is the second requirement. Building images that are small, reproducible and free of unnecessary privilege is a discipline in its own right, and it is the layer where security posture is largely decided. A hardened cluster running carelessly built images is a well-locked door in a wall of glass.
GitOps and infrastructure-as-code practice is the third. The configuration model assumes an organisation that reviews changes, keeps history and can roll back — capabilities that are cultural before they are technical. Introducing a reconciling agent into a team that deploys by editing live resources produces a fight the agent wins and the team resents.
Networking is the fourth and the most commonly missing. Cluster networking, service discovery, ingress and segmentation are prerequisites for the mesh and for any credible security position, and the gap here is usually invisible until it is expensive.
Skill areas and how the gap usually shows
| Area | What competence looks like | How the gap surfaces |
|---|---|---|
| Kubernetes fundamentals | Diagnosing a failing workload without guessing | Escalations that are really tutorials |
| Container practice | Reproducible, least-privilege images | Security findings against images, not clusters |
| GitOps and IaC | Changes reviewed, history kept, rollback rehearsed | Manual edits reverted by the agent, repeatedly |
| Networking | Segmentation and ingress designed, not inherited | Connectivity incidents at environment boundaries |
| Security and policy | Enforcement adopted incrementally | Policy enabled, then disabled after it blocks a release |
Certification is a reasonable way to structure the first row, and the distinctions between the available Kubernetes credentials map onto genuinely different roles — our comparison of CKA, CKAD and CKS certifications in practice sets out which one fits which job.
Where the Platform Is Heading
Predicting product direction is a low-value exercise, but three structural trends are already visible in how the platform is packaged and can be reasoned about without speculation.
The first is consolidation into the base product. The direction of travel is documented rather than forecast: the GKE Enterprise release notes state that the features that were part of the premium tier have become part of the standard offering, and that GKE is now a single offering without editions or tiers. For buyers, this removes an entire class of question — which tier do we need, and when do we upgrade — and replaces it with capability questions. For anyone reading older material, it means tier-based advice is stale by construction.
The second is that management is moving up the stack. Once cluster operation is largely automated, the interesting work shifts to what runs across clusters: placement decisions, cost allocation, policy coverage and the questions that only make sense about a population. The skills that hold value follow that shift, which is worth knowing when planning what a team should learn next.
The third is the pull of AI and machine learning workloads. Accelerated hardware, large datasets and jobs whose cost profile differs sharply from web services put pressure on scheduling, quota and cost models that were designed for stateless traffic. Hybrid estates feel this first, because accelerator availability and data residency rarely point at the same location.
The trend not to bet on is the disappearance of complexity. Each generation of tooling absorbs the previous generation’s routine work and exposes a new frontier of coordination problems — which is the pattern every layer of infrastructure has followed, and there is no reason to expect this one to be the exception.
The Practical Verdict
Strip away the naming history and the component inventory, and the platform makes a single trade that either fits an organisation or does not.
What it gives is a population-level view of infrastructure. Clusters stop being individual systems with individual histories and become instances of a declared standard, which is what lets a team grow the estate without growing in proportion to it. Configuration arrives from one place, policy is enforced rather than requested, identity has a single front door, and telemetry is comparable across environments that have nothing else in common. For an organisation that genuinely operates in several places, that is not a convenience — it is the difference between a strategy and a set of separate estates that happen to share a logo.
What it takes is a platform to operate and a set of prerequisites already met. Kubernetes competence, container discipline, reviewed configuration and a designed network are not things this platform supplies; they are things it assumes. Adopted on top of them, it compounds their value. Adopted instead of them, it adds a layer whose failure modes are harder to diagnose than the ones it was bought to fix, and the diagnosis lands on the smallest team in the organisation.
The decision rule that survives contact with reality is short and slightly uncomfortable. Count the environments you actually operate — not the ones in the strategy deck — and count the clusters you expect to be running in eighteen months. If both numbers are small and stable, the operating cost will outrun the leverage, and disciplined GitOps on a single managed platform is the better answer. If either is large or growing, the coordination problems this platform addresses are already consuming your team’s week, and the open question is not whether to solve them but with what.
What the trade looks like from each side
| What you gain | What you accept |
|---|---|
| A single inventory and access review across environments | A control plane that is itself a system to operate |
| Configuration and policy declared once, enforced everywhere | Drift correction that undoes manual fixes by design |
| Workload placement as an economic decision | Portability that must be tested rather than assumed |
| Skills that transfer between environments | Prerequisites the platform will not teach your team |
| Estate growth without proportional growth in headcount | Upgrade work that never reaches a finished state |
Build Your Skills
The distance between understanding this platform and operating it is mostly hands-on: registering clusters, running a configuration source in anger, enabling enforcement without stopping delivery, and rehearsing an upgrade before it is urgent. The Google Anthos — hybrid and multi-cloud computing course covers exactly that ground with practical exercises. Check the programme and sign up to build your skills with EITT’s experts.
Frequently Asked Questions (FAQ)
Is it worth adopting this platform if we run in only one cloud?
Usually not. The features that justify the operating cost — fleet-wide configuration, cross-environment policy, a single identity front door — are answers to problems created by having several environments. With one environment, standard managed Kubernetes plus disciplined GitOps gives most of the benefit without a platform layer to operate. The exception is an organisation that already knows a second environment is coming on a specific date, which is different from one that suspects it might.
What actually happens to the name — is Anthos discontinued?
The capability is not discontinued; the separate product name is. Google’s own release notes state that the features that had been part of GKE Enterprise are now part of standard Google Kubernetes Engine or exist as products used alongside it, and that GKE is a single offering without editions or tiers. Practically, search the documentation for the capability — fleets, Config Sync, Policy Controller, service mesh — rather than for the brand, and treat any tier-based guidance you find as historical.
Can we govern clusters we already run elsewhere without rebuilding them?
Yes, and this is the least disruptive entry point. The GKE Multi-Cloud documentation describes attached clusters as a way to bring any conformant Kubernetes cluster under the same management surface, alongside purpose-built clusters on AWS and Azure. Registration is reversible in a way that migration is not, which makes it a sensible way to test whether the central governance features earn their cost on your estate before committing to anything structural.
Where should a rollout start if we want it to survive contact with delivery teams?
Start with visibility, not enforcement. Register clusters, get a real inventory, and run policy in audit mode long enough to learn how much existing non-compliance there is. Then deliver configuration from a central source for something uncontroversial before anything contentious. Enforcement comes last and comes gradually. Rollouts that begin by blocking deployments generate exactly one memorable incident, after which the platform becomes politically radioactive regardless of its merits.
Does this remove the need for platform engineers?
No — it changes what they do. Routine cluster operation shrinks; coordination work grows. Somebody still owns the configuration repository, decides which policies apply where, keeps environments on supported versions, and answers for the cost allocation model. The realistic expectation is that a platform of this kind lets a stable team govern a growing estate, not that it lets a growing estate run without a team.