You Migrated VMware Workloads to Amazon EKS. Here Are the 8 Things to Set Up Next

Key points:

Migrated your VMware workloads to Amazon EKS and wondering what to set up next? Do these eight things, in this order, each with the concrete tool named:

1. Cluster add-ons and storage - Amazon VPC CNI, CoreDNS, kube-proxy, the Amazon EBS CSI driver (plus EFS CSI for shared volumes), and the AWS Load Balancer Controller, all installed as managed EKS add-ons.
2. Backup and DR - Velero plus CSI VolumeSnapshots (or AWS Backup for EKS if you want one AWS-native policy).
3. Observability - Prometheus/Grafana or CloudWatch Container Insights, plus EKS control plane audit logs turned on.
4. GitOps delivery - Argo CD or Flux.
5. Autoscaling and right-sizing - Karpenter plus HPA and VPA recommendations.
6. Runtime security and policy - Pod Security Standards, NetworkPolicy, and Falco or Amazon GuardDuty EKS Runtime Monitoring.
7. Cost visibility - OpenCost/Kubecost or AWS Split Cost Allocation Data.
8. Developer self-service - an internal developer platform or portal so engineers stop filing tickets for environments.

The rule for the order: fix what breaks a running workload first, protect data second, change how you ship third, and save money fourth. Nothing on the optimization list matters if you cannot restore a PersistentVolumeClaim.

The migration got a celebration. Somebody sent the "we're off VMware" message, the team took a screenshot of the empty vCenter, and everyone moved on. Then week two arrived and a database pod got evicted, and nobody in the room knew who restores its volume or whether a backup even existed. That gap is what day 2 is about.

I have watched enough of these to know the failure mode is always the same. Teams treat the lift-and-shift as the finish line when it is the starting line. The Broadcom licensing shift is real - VMware ended the sale of perpetual licenses in favor of subscriptions in early 2024, and that is what pushed a lot of you onto EKS. But the licensing math is not what will hurt you in month two. The missing plumbing is.

This is the checklist I would hand a platform team the day the migration "finishes." It is tool-fair. I recommend Velero, Argo CD, Karpenter, Falco, GuardDuty, and Kyverno by name, and I say plainly where the AWS-native option is the better call for a small team. The one place I get opinionated about our own product is the developer self-service section near the end, where the question actually comes up.

What should you set up first after migrating VMware workloads to Amazon EKS?

Eight things, in priority order: cluster add-ons and storage, backup and DR, observability, GitOps delivery, autoscaling and right-sizing, runtime security and policy, cost visibility, then developer self-service. Order them by blast radius: what breaks a running workload comes before what protects data, which comes before what changes how you ship, which comes before what saves money.

Split the work into week-1 wins and 90-day items. Week 1 is add-ons pinned, StorageClasses defined, DNS wired, a first Velero backup taken, and control plane audit logs switched on. The 90-day items are Karpenter consolidation, cost showback, and developer self-service. If you try to do cost optimization in week 1, you will optimize a cluster you cannot yet restore.

Two migration-specific traps will bite you no matter how clean the cutover was. First, workloads moved with VMware HCX or a VM-to-container conversion carry their VM-shaped CPU and memory allocations straight into pod requests, so nothing bin-packs. Second, NSX assumptions do not map onto the VPC CNI, where every pod gets a routable VPC IP address and can exhaust a subnet you sized for VMs.

Be honest about what AWS hands you and what it does not. AWS runs and backs up the EKS control plane and etcd, and it manages the add-on lifecycle. AWS does not give you delivery, environment management, or a developer interface. Those are yours to build or buy.

Which Amazon EKS add-ons and cluster basics are non-negotiable on day 2?

The baseline is Amazon VPC CNI, CoreDNS, kube-proxy, the Amazon EBS CSI driver (plus EFS CSI for ReadWriteMany volumes), EKS Pod Identity, and the AWS Load Balancer Controller. Install them as managed EKS add-ons so AWS handles version compatibility across cluster upgrades instead of you chasing Helm chart drift.

Managed add-ons matter more than they look. They let you preview version compatibility before an upgrade and cut the "we upgraded the cluster and CoreDNS fell over" class of incident. Self-managed Helm installs work, but you own every compatibility surprise.

Storage is where VMware habits do the most damage. VMFS and vSAN datastores translate to EBS (block storage, single-AZ, ReadWriteOnce) and EFS (shared, ReadWriteMany). The classic failure is a VM that shared a datastore becoming three pods that all expect read-write-many on an EBS volume, which EBS cannot do. Define your StorageClasses, reclaim policy, and volumeBindingMode before anything stateful lands.

Networking is the other trap. The VPC CNI gives every pod a real VPC IP, so a small node can hit its IP ceiling long before its CPU is full. An m5.large tops out around 29 pods on secondary IP addresses, while prefix delegation assigns /28 blocks of 16 IPs each and lifts you toward the default cap of 110 pods per node. If you inherited /24 subnets from the VMware network plan, you will exhaust them faster than you expect.

For identity, drop the VM habit of static credentials and one broad node role. Use EKS Pod Identity (or IRSA) scoped per workload - one IAM role per service. For ingress and DNS, the AWS Load Balancer Controller provisions ALBs and NLBs, and external-dns writes the Route 53 records a vSphere admin used to create by hand.

One permanent tax to plan for on day 2: cluster upgrades. Kubernetes ships a new minor version roughly every four months, and each version gets 14 months of EKS standard support before it rolls into 12 months of extended support at a higher price. Decide now who owns that cadence.

How do you back up and restore stateful workloads on EKS without vSphere snapshots?

vSphere snapshots, VM backup agents, and Site Recovery Manager have no drop-in Kubernetes equivalent. You need something for Kubernetes objects plus something for volume data, and you must complete a tested restore before you decommission vSphere. In practice that means Velero plus CSI VolumeSnapshots, or AWS Backup for EKS if you want a single AWS-native policy.

Velero, a CNCF project, captures two things: your Kubernetes API objects to an S3 bucket, and your persistent volume data through one of two methods. Use CSI VolumeSnapshots when your storage driver supports them (the fast path on EBS), and File System Backup, which uses Kopia or Restic, when it does not or when you need file-level portability.

A sane starting config is namespace-scoped scheduled backups, a separate bucket per environment, and pre/post hooks that quiesce databases so the snapshot is application-consistent. Define your RPO and RTO in Kubernetes terms - how much data can this namespace lose, how fast must it come back - not in the VM terms your DR runbook still uses.

AWS Backup now supports Amazon EKS as a fully managed path that went GA in late 2025. It protects the cluster's Kubernetes resources plus stateful data in EBS, EFS, and S3, and it can restore into a brand-new cluster it provisions for you. Reach for it when you want one backup policy governing RDS, EBS, and EKS together under AWS Organizations. Reach for Velero when you need portability, granular object filtering, cross-cluster restore, or multi-cloud coverage.

AWS manages and backs up etcd for you, so your scope is workload and volume state, not the control plane. That is a real reduction in responsibility compared to running your own Kubernetes on vSphere.

The rule I will not bend on: a backup you have never restored is not a backup. Put a quarterly restore drill into a scratch namespace on the calendar, with a written exit criterion - the restore completes in under one hour - and treat a failed drill as a production incident.

What replaces vCenter for deployment, observability, and policy on EKS?

Nothing replaces vCenter one-for-one. Its job splits three ways: GitOps delivery through Argo CD or Flux (both CNCF graduated projects), observability through Prometheus/Grafana or CloudWatch Container Insights, and policy through Kyverno or OPA Gatekeeper with Pod Security Standards as the baseline.

On delivery, pick Argo CD when you want a UI and app-of-apps visibility across teams, and Flux when you want a lighter, controller-only footprint that fits neatly with Terraform. Both are solid. The reason GitOps matters specifically after a migration is that it restores the auditable change record vCenter tasks and events used to give you, except now it lives in git where you can diff and revert it.

Observability has a few EKS gotchas that surprise VMware admins. Control plane audit logs are opt-in and billed through CloudWatch, so turn them on deliberately. kube-state-metrics and node-exporter are not installed by default. And per-pod cost or usage attribution only works if you label workloads on purpose.

For policy, PodSecurityPolicy is gone. Use Pod Security Standards for the baseline, then Kyverno or Gatekeeper for org rules - required labels, no :latest image tags, mandatory resource requests. For secrets, wire AWS Secrets Manager to the cluster with the External Secrets Operator or the Secrets Store CSI driver, and kill the vSphere-template habit of baking credentials into images.

Why did your AWS bill go up after leaving VMware, and how do you fix it?

Your bill went up because the pod requests you inherited from VM CPU and memory allocations are almost always oversized, so nodes never bin-pack and Karpenter has nothing to consolidate. Fix the requests first, then node provisioning, then purchasing, in that order. Buying commitments on oversized requests just locks in the waste.

This is not a rounding error. CAST AI's Kubernetes Cost Benchmark, drawn from thousands of production clusters, found the average cluster uses a small fraction of the CPU it provisions and leaves most requested memory idle. The CNCF's FinOps microsurvey puts numbers on the pattern: 49% of organizations said Kubernetes drove their cloud spend up, and 70% named overprovisioning as the main cause.

Start with a diagnosis loop, not a change. Compare requested versus actual p95 CPU and memory per workload for two to four weeks using VPA recommendations, Goldilocks, or Kubecost/OpenCost. Only then touch the numbers.

For node provisioning, Karpenter's consolidation removes empty nodes and replaces underutilized ones with cheaper instances that still fit the workload, picking instance types on the fly and handling Spot interruptions. Cluster Autoscaler is still fine if you have stable, homogeneous node groups and do not want to manage NodePools. Most migrated estates are neither, which is why Karpenter usually wins.

For visibility, OpenCost and Kubecost give per-namespace and per-team showback, and AWS Split Cost Allocation Data brings pod-level CPU and memory cost into the Cost and Usage Report so it lands in native AWS billing with tags like aws:eks:namespace and aws:eks:workload-name.

The single largest one-day saving is usually the most boring one: non-production environments running 24/7. Turning them off nights and weekends is the easiest lever to ship, and it beats most right-sizing work on effort-to-impact.

What security controls do you now own on EKS that VMware and NSX handled for you?

AWS secures the EKS control plane and etcd. You now own node hardening, image supply chain, runtime detection, network policy, RBAC, and audit logging - everything vSphere and NSX used to centralize behind one console. The shared responsibility line moved, and the pieces below the line are yours.

For runtime threat detection, Falco is the open source option, Amazon GuardDuty EKS Runtime Monitoring is the lowest-effort AWS-native option, and Sysdig Secure or Aqua Security are the commercial ones. GuardDuty runs a managed agent that watches process execution, file access, and network connections and flags privilege escalation and suspicious API calls. If you have no dedicated security engineer, turn GuardDuty on first and add Falco later.

For the image supply chain, scan in CI and turn on Amazon ECR enhanced scanning, then use admission control to block unsigned or unscanned images from running. For network policy, the VPC CNI supports Kubernetes NetworkPolicy, and Calico or Cilium give you richer rules when you outgrow it. The target state is default-deny per namespace, which is the closest thing to NSX micro-segmentation.

For access control, map your old vCenter roles onto Kubernetes RBAC plus EKS access entries, scoped per namespace and per environment, never cluster-admin by default. For node hardening, run Bottlerocket or EKS-optimized AMIs and replace nodes on a schedule instead of patching long-lived VMs. Immutable nodes are the biggest mindset change for a VMware admin, and the biggest operational win.

Finally, turn on EKS control plane audit logs on day 2 and ship them somewhere queryable. Without them you have no forensic trail when something goes wrong, and something eventually will.

Do you need an internal developer platform on top of EKS, or is Argo CD enough?

Argo CD is enough if your developers are comfortable writing Kubernetes manifests and Helm charts. If they are not, and your platform team is authoring every chart and hand-creating every environment, you need a developer-facing layer - Backstage, Port, Humanitec, or Qovery - or the migration will not change your delivery speed at all. You will have swapped vSphere tickets for Kubernetes tickets.

The symptoms are easy to spot. The platform team writes every Helm chart. Environments get created by ticket. Pull requests get tested on one shared staging cluster because nobody can spin up a fresh one. Onboarding a new service takes days. If two of those are true, self-service is the missing piece, not another controller. Gartner expects 80% of large software engineering organizations to run platform teams by 2026, up from 45% in 2022, which is the industry admitting this out loud.

The honest option comparison: Backstage is an open source portal where you build the plumbing and the golden paths yourself. Port and Humanitec are portal and orchestration products that assemble faster on a SaaS control plane. DIY Argo CD plus Helm plus Terraform gives maximum control and ongoing maintenance. Qovery is an opinionated internal developer platform that installs into your own cloud account or existing cluster.

Where Qovery fits this specific situation is the bring-your-own-Kubernetes model. It runs on the EKS cluster you just migrated to, inside your own AWS account, so the cloud bill and any Savings Plans stay in your name. On top of that it adds git-push deployments, preview environments for every pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.

Be clear about what it is not. Qovery does not replace Velero, Argo CD, Karpenter, or Falco. It sits above them as the developer-facing layer, and teams commonly run both - Qovery for self-service and environments, Argo CD for GitOps, Velero for backup, Falco for detection. And because most post-VMware estates do not land 100% on AWS, the same model applies on GCP, Azure, Scaleway, or an existing self-managed Kubernetes cluster.

Set one concrete first milestone: one team, one service, a git push to a live preview environment, inside a day. If you cannot hit that in a quarter, your self-service layer is not real yet.

What does a realistic 90-day post-migration plan look like?

Days 1-14 stabilize: pin add-ons, define StorageClasses, wire DNS, take a first Velero backup, and turn on control plane audit logs. Days 15-45 observe and secure: stand up metrics and logs, apply NetworkPolicy, enable runtime detection, and adopt GitOps. Days 46-90 optimize and hand over: right-size requests, enable Karpenter, ship cost showback, roll out developer self-service, and only then decommission vSphere.

Write testable exit criteria for each phase so anyone can verify them. A restore into a scratch namespace completes in under one hour. Every namespace has a default-deny NetworkPolicy. No workload runs without CPU and memory requests. One team deploys via git push without filing a ticket. If a criterion is not measurable, it is a wish, not a gate.

The decommission rule is simple: do not power off vSphere until you have a tested restore and 30 days of clean observability on the EKS side. The old environment is your rollback until both are true.

Sort out ownership while you are at it. Decide what the platform team owns, what application teams own, and how you retrain vSphere skills - storage, networking, capacity planning - into Kubernetes ones instead of backfilling with new hires. And face the recurring cost VMware never imposed: Kubernetes ships a minor version every four months, EKS standard support per version is finite, and extended support costs more per cluster-hour than standard. Decide on day 2 whether you own upgrades or outsource them.