When you need it
Your teams need Kubernetes, but the cluster is the easy part. Ingress, certificates, secrets, policies, monitoring and upgrades take months to get right, and until then every team sets up its cluster its own way.
What sets the quote
- One platform: EKS, AKS, GKE, or managed OpenShift as Red Hat OpenShift Service on AWS (ROSA) or Azure Red Hat OpenShift (ARO).
- One region and one cluster per environment, for up to 3 environments.
- One identity provider for cluster access, and GitOps with Argo CD or Flux.
- Up to 10 platform add-ons, for example ingress or Gateway API, cert-manager, External Secrets, external-dns, Kyverno or Gatekeeper, managed Prometheus and Grafana, and Karpenter or the cluster autoscaler.
- Up to 3 reference services onboarded.
- Self-managed OpenShift, more clusters or more regions are quoted separately after sizing.
What changes
- Teams deploy by merging to Git, and Argo CD or Flux applies the change and reverts drift.
- Every cluster runs the same add-ons, policies and access rules, all defined as code.
- Services get cloud permissions through workload identity and secrets from your secret store, never from the repository.
- Your team can onboard the next service by following a reference service, and upgrades follow a tested runbook.
What you get
- Clusters for up to 3 environments as Terraform code, with private networking and workload identity
- A GitOps repository in which Argo CD or Flux manages the add-ons and services
- Up to 10 platform add-ons, installed, configured and pinned to tested versions
- Cluster access through your identity provider, with roles for platform and service teams
- A baseline policy set in Kyverno or Gatekeeper, run in audit mode before it is enforced
- Dashboards and alerts for cluster and service health
- Up to 3 reference services onboarded, with a template for the next ones
- Upgrade and rebuild runbooks, and a handover session
What we cover on each platform
| Area | EKS | AKS | GKE | Managed OpenShift |
|---|---|---|---|---|
| Cluster access | Access entries mapped to IAM Identity Center roles | Microsoft Entra ID with Kubernetes RBAC or Azure RBAC | IAM and Google Groups for RBAC | OpenShift OAuth with your identity provider |
| Workload identity | EKS Pod Identity or IRSA | Microsoft Entra Workload ID | Workload Identity Federation for GKE | IAM roles for service accounts on ROSA; workload identity on ARO |
| Ingress | AWS Load Balancer Controller | Application Gateway for Containers | GKE Gateway controller | OpenShift routes through the Ingress Operator |
| Monitoring | Amazon Managed Service for Prometheus and Amazon Managed Grafana | Azure Monitor managed service for Prometheus and Azure Managed Grafana | Google Cloud Managed Service for Prometheus, with Grafana | Built-in OpenShift monitoring, including user workload monitoring |
Not included
- Self-managed OpenShift (quoted separately)
- Containerising legacy apps (a separate package, legacy app modernisation)
- Service mesh, multi-region failover and databases on the cluster
- Running the platform after handover (available as Platform Care)
What we need from you
- AWS: an IAM Identity Center permission set with AdministratorAccess in the platform accounts for the length of the build.
- Azure: Contributor and Role Based Access Control Administrator on the platform subscriptions.
- Google Cloud: Editor and Project IAM Admin on the platform projects.
- An admin of your identity provider for groups and single sign-on, and admin rights on the GitOps and service repositories.
- A platform owner for 2–3 hours a week, and a developer from each reference service team.
How it works
Free 30-minute call, then a written fixed quote based on your platform, environments, add-ons and services.
Design workshop to agree the cluster layout, networking, access model, add-ons and GitOps repository structure.
We build the clusters and add-ons as code, one environment at a time, and you review every change as a pull request.
We onboard the reference services and rehearse a version upgrade with your team on a non-production cluster.
Handover with runbooks, with the option to continue under Platform Care.
At a glance
- Duration
- 5–6 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related services
Container platform check
A one-week, read-only review of your Kubernetes clusters or serverless container runtime, with evidence for every finding, a hardening plan ordered by risk and a readout with your team.
Serverless container platform
A platform for your containerised services on ECS on Fargate, Azure Container Apps or Google Cloud Run in 3–7 weeks, built as code with one reusable service module for every team.