Moving workloads from EC2 to Kubernetes is one of the most common infrastructure transitions teams make. The operational and scaling benefits are well understood. The security implications are less often discussed, and they are significant, because Kubernetes does not just change where your workloads run. It changes what your attack surface is made of.
If you are planning a migration from EC2 to a Kubernetes platform such as EKS, this guide walks through the security surfaces that change and what to have in place before you cut over. It draws on how one team went about securing EC2 workloads through a Kubernetes migration in healthcare, where the transition window was the highest-risk period. The goal is to migrate without opening a coverage gap during the transition, which is exactly when many teams are most exposed.
Why the Security Surface Changes
On EC2, your security model is built around instances, security groups, IAM roles, and the network. It is a relatively flat model: a workload is an instance, and you reason about the instance.
Kubernetes introduces an entire orchestration layer on top of that, which is why Kubernetes security is treated as its own discipline. Now you also have pods, deployments, service accounts, role-based access control (RBAC), network policies, namespaces, and admission control. Each of these is a new configuration surface with its own failure modes. Securing your EC2 instances well does not automatically secure any of these, because none of them existed in the EC2 model. This is the core reason a migration is a security event, not just an operational one.
The Readiness Checklist
1. Establish Your EC2 Baseline First
Before you migrate, know where you stand. Have a clear picture of your current posture on EC2, misconfigurations, exposed instances, over-permissioned roles, so you are migrating from a known state rather than carrying unknown problems into a more complex environment. Migrating unresolved issues does not fix them; it relocates them into a system that is harder to reason about.
2. Plan RBAC From the Start
Kubernetes RBAC is powerful and easy to get wrong. Overly broad ClusterRole bindings, default service accounts with more access than they need, and wildcard permissions are common early mistakes. Decide your RBAC model before you migrate, principle of least privilege applied to every service account and role, rather than granting broad access to “get things working” and intending to tighten later. Later rarely comes. Pairing RBAC with Kubernetes JIT keeps engineer access time-bound from day one — the approach behind eliminating standing Kubernetes privileges with JIT access for EKS cluster RBAC.
3. Design Network Policies Deliberately
By default, pods in a Kubernetes cluster can talk to each other freely. That flat internal network is convenient and dangerous, it means a single compromised pod can reach everything else. Plan network policies that restrict pod-to-pod communication to what is actually required, so a compromise in one workload does not automatically become lateral movement across the cluster.
4. Map Identity: IRSA and Service Accounts
On EC2, workloads assume IAM roles via instance profiles. On EKS, the mapping between Kubernetes service accounts and AWS IAM roles (IRSA) is a new identity surface. Misconfigured, it can grant pods far more cloud access than intended. Plan how pod identities map to cloud permissions, and apply the same least-privilege discipline you would to any IAM role.
5. Address Image Provenance and Vulnerabilities
Containers run images, and images come from somewhere. Pulling from public registries without scanning, without digest pinning, and without knowing the provenance of what you run introduces supply-chain risk that plain EC2 did not have in the same form. Establish where your images come from, scan them for vulnerabilities, and pin to digests so you are running what you think you are running.
6. Harden Pod Configuration
Kubernetes lets pods request capabilities that are dangerous by default, privileged mode, host networking, host path mounts, running as root, writable root filesystems. Each expands the blast radius of a compromised container, potentially toward the host. Define pod security standards that disallow these unless explicitly justified, and enforce them through admission control rather than hoping every manifest gets them right.
7. Don’t Lose Runtime Protection at the Cutover
If you have runtime protection on your EC2 workloads, plan how Kubernetes runtime security moves with them rather than treating it as something to figure out after the migration. A unified container security view that spans both the old and new environments makes that continuity far easier to maintain. The transition window, workloads moving, clusters spinning up, the team learning a new platform, is precisely when runtime visibility matters most.
Losing it at the cutover means running in your least-familiar environment with your protection turned off.
8. Extend, Don’t Restart, Your Attack-Path View
On EC2, an attack path runs through instances, security groups, and IAM roles. On Kubernetes it also runs through pods, RBAC bindings, and service accounts. If you reason about attack paths today, make sure that reasoning extends to the new resource types, otherwise you lose visibility into how a compromise could chain through the cluster exactly when the environment becomes more complex.
Avoiding the Coverage Gap
The recurring theme across this checklist is continuity. The riskiest part of a migration is not the destination; it is the transition, the period when workloads are in motion and the team is rebuilding operational muscle for a new platform. Teams that plan security as an integral part of the migration, rather than a follow-up project, avoid the window where controls are half-configured and the environment is half-migrated.
Practically, that means favouring approaches where your existing security model extends to Kubernetes rather than being rebuilt for it. Whether that is your posture management, your identity analysis, or your runtime protection, the less you have to reinvent at the migration, the smaller your exposure window during it.
The Bottom Line
Migrating from EC2 to Kubernetes is not a lift-and-shift from a security standpoint. It adds pods, RBAC, service accounts, network policies, image provenance and scanning, and admission control to your attack surface, none of which your EC2 controls address on their own. Establish your baseline first, plan the new surfaces deliberately, and make sure posture, identity, runtime, and attack-path coverage extend through the transition rather than restarting after it. Migrate with security continuous, not with security resumed.
