The Day 2 Operations Checklist After Moving VMware Workloads to EKS: What You Run Every Week, Month, Quarter and Year

Key points:

• Day 2 on EKS is a recurring calendar with named owners. After a VMware exit, the recurring work splits into weekly (alerts, image CVEs, failed deploys), monthly (cost review, node AMI rotation check, access review), quarterly (Kubernetes minor upgrade, restore drill, add-on updates) and yearly (region DR game day, Savings Plans, support-model review) tasks, each with a named owner.
• The rhythm is much faster than vSphere. vSphere 7 got general support from 2020 until October 2, 2025. Kubernetes ships a minor version about every four months, and each EKS version gets 14 months of standard support plus 12 months of extended support, 26 months in total.
• Missing the upgrade calendar costs 6x on the control plane. An EKS cluster costs $0.10 per hour in standard support and $0.60 per hour in extended support, roughly $73 versus $438 per cluster per month, and extended support is on by default.
• Node lifecycle replaces ESXi patching. EKS stopped publishing Amazon Linux 2 AMIs on November 26, 2025, so nodes run AL2023 or Bottlerocket and get replaced, not patched. Karpenter's default expireAfter is 720 hours and EKS Auto Mode caps node life at 21 days.
• A backup you never restored does not count. Schedule a quarterly restore into a scratch namespace with Velero or AWS Backup for EKS (launched November 10, 2025), and a yearly region failover.

Your VMware team had a rhythm. Patch ESXi a few times a year, upgrade vCenter when Broadcom forced it, refresh snapshots, check the datastores. A major vSphere version lived for five years. Then you moved the workloads to Amazon EKS and the rhythm broke, because nothing on EKS lives that long.

I already wrote the one-time setup list, the 8 things to set up after migrating VMware workloads to EKS: add-ons, Velero, GitOps, Karpenter and the rest. This article covers the other half, the recurring checklist your team runs every week, month, quarter and year once the cluster is live. That is where post-VMware teams get hurt, usually six months after the migration party, when the first Kubernetes version falls out of standard support and the bill quietly goes up.

Everything below comes from AWS, Broadcom, CNCF and Karpenter documentation, linked inline, plus what my team has learned operating hundreds of clusters for customers.

What is the day 2 operations checklist after migrating VMware workloads to EKS?

The day 2 checklist after a VMware to EKS migration is a set of recurring tasks grouped by cadence: weekly alert and vulnerability triage, monthly cost and access reviews, quarterly Kubernetes upgrades and restore drills, and a yearly disaster recovery test and commitment review. Each task needs one owner and one written pass criterion, or it slips.

Here is the full calendar. Print it, put names in the last column, and put the quarterly items in your sprint planning tool before anything else.

How is the EKS operating rhythm different from what your VMware team was used to?

The EKS rhythm is roughly three to five times faster than vSphere. A vSphere major version gets years of general support, while an EKS Kubernetes version gets 26 months end to end, and a new one arrives about every four months, so your team upgrades the platform several times a year instead of once every few years.

Look at the dates side by side. Broadcom's own knowledge base confirms vSphere 7 reached end of general support on October 2, 2025, and VMware says vSphere 8 is supported until October 2027 with an optional two-year extension you pay for. Compare that with AWS: a minor version is in standard support for 14 months, then extended support for 12 more. Upstream Kubernetes itself gives about one year of patch support per minor release.

The second difference is ownership. AWS runs the EKS control plane and etcd, so a whole category of vCenter work disappears. But AWS does not upgrade your nodes or most of your add-ons for you. The EKS docs are blunt about it: managed node groups and self-managed nodes "aren't automatically upgraded" when the control plane is.

Many of you left because VMware moved to subscription-only offers in December 2023. Do not replace one surprise renewal with a surprise extended support bill.

How often do you need to upgrade EKS, and what does extended support actually cost?

Plan one Kubernetes minor upgrade per quarter per cluster to stay inside standard support with margin. If you fall behind, AWS moves the cluster into extended support automatically and bills the control plane at $0.60 per hour instead of $0.10, which is about $365 more per cluster per month.

Here is the current calendar straight from the AWS release table, as of today:

If you migrated off VMware in late 2025 and created clusters on 1.33 or 1.34, you are either already paying extended support or you start on December 2, 2026. Billing starts at the beginning of that day, UTC.

The math, using the EKS pricing page:

• Standard support: $0.10 x 730 hours = about $73 per cluster per month
• Extended support: $0.60 x 730 hours = about $438 per cluster per month
• A typical post-VMware estate of 6 clusters (dev, staging, production in two regions, plus a tooling cluster) sitting in extended support for 6 months pays about $13,140 extra for the privilege of not upgrading

Extended support is not a scam. AWS keeps shipping control plane security patches, VPC CNI, kube-proxy and CoreDNS patches, and updated optimized AMIs during that period. Paying it on purpose for a cluster you will retire in two months is a fine decision. Paying it because nobody looked at the calendar is the failure.

Two policy decisions belong on your yearly review:

• Upgrade policy per cluster. Extended support is enabled by default. Setting a cluster to the STANDARD policy means AWS auto-upgrades it at the end of standard support instead of billing you. I use STANDARD for dev, preview and CI clusters, and EXTENDED (deliberate, ticketed) for production. I covered the full sweep in the 1.34 extended support audit.
• What happens at the end. After 26 months, AWS auto-upgrades the control plane only. Managed node groups and self-managed nodes stay behind, and AWS gives no notice of the exact moment. That is the worst possible way to upgrade.

What goes on the quarterly upgrade runbook?

The quarterly upgrade runbook has six steps in a fixed order: check upgrade insights, upgrade the control plane one minor version, roll the nodes, update managed add-ons, update controllers and Helm charts, then update clients. AWS documents the order in its cluster update guide.

1. Read EKS upgrade insights. They flag deprecated API usage over a rolling 30-day window, so a fix you made yesterday can still show as an issue. Cross-check with the upstream deprecated API migration guide.
2. Upgrade one minor version at a time. EKS cannot skip versions. Going from 1.33 to 1.35 means two upgrades. The control plane update needs up to five free IP addresses in the cluster subnets, which is exactly the kind of thing a /24 inherited from the VMware network plan runs out of.
3. Roll the nodes. Match the control plane version before the next hop. The kubelet can be up to three minor versions behind, but do not live there.
4. Update the managed add-ons. VPC CNI, CoreDNS, kube-proxy, EBS CSI driver, Pod Identity agent.
5. Update everything else that touches the API. Karpenter, the AWS Load Balancer Controller, cert-manager, external-dns, Argo CD or Flux, your monitoring stack, every operator you installed for a migrated database.
6. Know your rollback window. EKS now lets you roll back to the previous minor version within 7 days of an in-place upgrade. After that, rolling back means a new cluster.

Budget honestly. AWS says the control plane update takes several minutes. The whole hop, with add-ons, node rollout and verification, is closer to half a day per cluster in my experience. Three hops a year across six clusters is 18 cluster-hops, roughly 9 engineer-days a year, before anything breaks. My CTO Pierre talked through how we do this at scale in upgrading hundreds of Kubernetes clusters.

How do you manage node lifecycle now that there is no ESXi to patch?

You stop patching nodes and start replacing them. On EKS, nodes are disposable EC2 instances built from an AMI, so the monthly task is to make sure every node runs a current AL2023 or Bottlerocket image and none is older than your maximum node lifetime.

This is the biggest mindset change for a vSphere team. On ESXi you patched a long-lived host in place and used vMotion to move VMs off it first. On EKS, you publish a new AMI and let the autoscaler drain and replace nodes. Pods restart; nothing live-migrates.

Three dates make this urgent for anyone who migrated recently:

• EKS stopped publishing Amazon Linux 2 AMIs on November 26, 2025. Kubernetes 1.32 was the last version with EKS-optimized AL2 AMIs.
• Amazon Linux 2 itself reached end of support on June 30, 2026. If you still run AL2 nodes, you are running an unsupported OS today.
• AL2 status is independent of extended support. AWS states you need to move to AL2023 or Bottlerocket "even if you are using EKS extended support."

One trap hits VMware estates in particular. Many lifted-and-shifted Java apps run an old JDK 8. AL2023 uses cgroup v2, and AWS documents that JDK 8 builds older than jdk8u372 cannot read container memory limits under cgroup v2, size the heap from the node's total memory, and get OOM-killed. If your migrated monolith started restarting after an AMI change, check the JDK before you check anything else.

Which node lifecycle settings should you set once and audit monthly?

Set a maximum node lifetime, a disruption budget and pod disruption budgets once, then check monthly that they are doing their job. The settings depend on how you provision nodes:

The monthly check is short. Count nodes older than your lifetime, count nodes on a non-current AMI, and list pod disruption budgets with maxUnavailable: 0 or minAvailable equal to replicas. Those PDBs block every node replacement, and they are common in migrated stateful apps whose owners wanted "no downtime, ever."

Also check the subnet math monthly. The VPC CNI gives every pod a VPC IP address, and subnets sized for a VM estate run dry quietly. A cluster that cannot get IPs cannot replace nodes, and a cluster that cannot replace nodes cannot upgrade.

How do you prove that backups and DR actually work every quarter?

You prove it by restoring. Once a quarter, restore one real production namespace, including its persistent volumes, into a scratch namespace or a fresh cluster, time it against your RTO, and treat a failed drill as an incident. Once a year, do the same for a whole cluster in another region.

On vSphere, Site Recovery Manager gave you a test failover button and a report your auditors liked. EKS has no equivalent button. AWS runs and backs up etcd for you; everything you deployed into the cluster is yours to protect.

You have two mainstream options, and many teams run both:

What goes on the quarterly drill checklist:

• Pick the namespace on rotation, not the easiest one. The database that came off a 2 TB VMDK is exactly the one to test, restored somewhere isolated from production.
• Run application-level checks beyond "pods are Running": row counts, a login, a test transaction.
• Record the measured restore time next to your RTO. If restore takes 3 hours and the RTO says 1, one of them is wrong.
• Check that backup retention and cross-region copies match what your compliance team promised.

The yearly DR game day is the SRM full recovery plan equivalent. Recreate the platform from code in a second region, restore data, switch DNS, and time the whole thing. The first one surfaces hardcoded ARNs, region-pinned AMIs and secrets nobody exported.

What should observability and on-call look like after a VMware exit?

Observability on EKS needs a weekly hygiene loop: review every alert that fired, delete the ones nobody acted on, and make sure each remaining alert has an owner and a runbook. Without that loop, a migrated estate inherits VMware-era alerts that no longer mean anything plus new Kubernetes alerts nobody understands.

The baseline from your setup phase (Prometheus and Grafana or CloudWatch Container Insights, control plane logs, OpenTelemetry for traces) is only useful if someone tends it. OpenTelemetry is now the second-highest-velocity CNCF project with over 24,000 contributors, per the CNCF Annual Cloud Native Survey, so the hard part now is keeping signal over noise.

The recurring items I would put on the calendar:

• Weekly: review fired alerts, failed deployments and pods restarting more than N times a day. Pod restarts are the new "VM rebooted unexpectedly", and they hide easily.
• Monthly: check log retention and cost. EKS control plane logs go to CloudWatch Logs, which keeps data indefinitely unless you set a retention period.
• Quarterly: re-validate service level objectives for the migrated apps. The latency profile changes when a VM becomes three pods behind an ALB.
• After every upgrade: confirm dashboards still work. Metric names change between exporter versions, and a silent dashboard is worse than a missing one.

How do you keep the EKS bill from drifting back up every month?

Run a monthly cost review that compares requested resources to actual usage per namespace, checks non-production schedules, and lists idle storage and extended support charges. Costs on Kubernetes drift by default, so a one-time right-sizing exercise after migration is not enough.

In the CNCF FinOps microsurvey, 49% of respondents said Kubernetes drove their cloud spend up. VMware-origin workloads make it worse because their pod requests were copied from VM sizes, and VMs were sized for peak with headroom.

The monthly cost checklist:

• Requests vs usage per workload. Use VPA recommendations, Goldilocks or OpenCost. Any workload using under 30% of its requested CPU for a month gets a ticket.
• Non-production schedules. Dev and staging running nights and weekends are usually the single easiest saving.
• Orphaned storage. EBS volumes from deleted PVCs with a Retain policy, old snapshots, unattached volumes.
• Extended support line items. Search the bill for extended support charges every month. It should be zero or a known, ticketed exception.
• Commitments last. Buy or resize Savings Plans in the yearly review, on right-sized usage. Committing to oversized requests locks the waste in for one to three years.

What security work recurs on EKS that vSphere and NSX used to centralize?

The recurring security work is image vulnerability triage weekly, access reviews monthly, certificate and secret rotation checks quarterly, and a policy and pen-test review yearly. On vSphere a lot of this lived in one console; on EKS it is spread across IAM, Kubernetes RBAC, the registry and your runtime detection tool.

Two items catch post-VMware teams off guard:

• Image CVEs replace guest OS patching. The OS inside a container image is part of the app now. A monthly AMI rotation does nothing for a vulnerable base image. Scan in CI, enable registry scanning, and give app teams a weekly list of critical CVEs in what is running.
• Access drifts faster. EKS access entries, IAM roles for Pod Identity, Kubernetes RoleBindings and your CI credentials all grant access. Review them monthly against your staff list. When someone leaves, removing their SSO account is not enough if a static kubeconfig or a long-lived token still works.

Runtime detection (GuardDuty EKS Runtime Monitoring or Falco) needs the same weekly triage as alerts, or it is just a checkbox.

Who should own day 2 operations after the VMware team?

Day 2 needs one accountable owner per row of the calendar, usually a small platform team, with app teams owning their images, alerts and restore validation. If you do not have a platform team, reduce the number of rows you own before you try to staff them.

The CNCF Annual Cloud Native Survey found the top obstacle to cloud native adoption is now "cultural changes with the development team", cited by 47% of respondents, ahead of lack of training (36%) and complexity (34%). That matches what I hear from teams leaving VMware. The tools are learnable. The hard part is that the virtualization team owned "the platform" end to end, and now ownership is split between AWS, a platform team and every app team.

My opinion: do not try to rebuild a VMware-sized ops team around EKS. Retrain your vSphere people on Kubernetes storage, networking and capacity, then push as many rows of the calendar as possible onto something that runs them for you. Here are the three realistic models:

EKS Auto Mode is a strong answer for the node lifecycle rows, but it costs a per-instance management fee on top of EC2 and does not give your developers a way to ship. Qovery does not replace your backup tool or your DR plan either. Qovery takes the upgrade, environment and deployment rows off your platform team's calendar, on Kubernetes in your own AWS account (or GCP, Azure, Scaleway, or an existing cluster), so the cloud bill and your Savings Plans stay in your name. Qovery is an Agentic DevOps platform: its control plane is separate from your cluster, and your apps never run on Qovery's infrastructure.

For the executive version of this argument, my colleague wrote an executive guide to Kubernetes day 2 operations.

How do I set this up with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills, optionally add the Qovery MCP Server, then ask your coding agent in plain language to connect your EKS cluster and deploy. The agent asks you to approve each action.

1. Install the Agent Skills for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI). This adds skills such as qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize and qovery-preview:

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

1. Add the Qovery MCP Server to Claude Code so the agent can read clusters, environments, deployment status and logs. It uses OAuth and is read-only by default:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

1. Only if you want the agent to change things, add write access. This also requires enabling write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Then ask something like: "Onboard my existing EKS cluster to Qovery, deploy the services from this repo, and turn on auto-stop for staging." Later, with the MCP Server: "List my clusters and tell me which ones are close to the end of standard support." Start with the AI agent quickstart or the Claude Code integration.