Private EKS clusters solve inbound exposure but create a daily access problem for engineers. Here's how the common options compare, and why an outbound-only, identity-aware approach scales better than running bastions or stitching together SSM tunnels. See the Twingate Kubernetes Operator docs for setup details.

In April 2026, AWS added IAM condition keys that let organizations write SCPs rejecting any EKS cluster whose API endpoint isn't private-only. The same release introduced one-click CloudShell access to private endpoints, aimed at short inspection tasks. The net effect: platform teams can now mandate endpointPublicAccess: false across every account in the org, and the compliance argument is basically over.

That leaves the operational question nobody has fully solved. If your API server is only reachable from inside the VPC, how do fifty engineers run kubectl without each cluster growing a bastion, a jump host, or a tangle of SSM port forwards?

What "private EKS" actually changes

A private EKS cluster means the Kubernetes API server endpoint resolves to a private IP inside your VPC. No public endpoint, no 0.0.0.0/0 allow list, no chance of someone finding your API server with a Shodan query. This is a good default.

The side effect is that kubectl get pods from an engineer's laptop doesn't work anymore. The laptop isn't in the VPC. Neither is your CI runner, your on-call dashboard, or the SRE spinning up a debug pod at 2am. Every one of those paths needs a network route into the VPC plus an authorization story for the cluster itself.

Most teams end up running a handful of options in parallel, usually without planning to.

The options, honestly compared

Here's how the common approaches stack up on the things that actually matter at scale: how many credentials end up in circulation, how much per-cluster work is involved, what the audit trail looks like, and whether it survives going from three clusters to thirty.

Bastion host

Bastion hosts are still the default in a lot of organizations. One EC2 instance per VPC, SSH in, run kubectl. It works, but every bastion is a small production system: patching, SSH key rotation, CloudWatch alarms, someone to notice when it fills its disk. Multiply by cluster count. The audit story is also split: SSH logs tell you who connected, Kubernetes audit logs tell you what they did, and nobody correlates them until there's an incident.

SSM Session Manager port forwarding

A real improvement over SSH bastions. No open ports, IAM-based access, session logs to S3 or CloudWatch. The usual pattern is aws ssm start-session with AWS-StartPortForwardingSessionToRemoteHost to tunnel 443 from the EKS endpoint to localhost, then point kubectl at https://localhost:4443.

Tunnel a local port to the private EKS API endpoint through an SSM-managed EC2 instance:

aws ssm start-session \
  --target i-0123456789abcdef0 \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["ABCD1234.gr7.us-east-1.eks.amazonaws.com"],"portNumber":["443"],"localPortNumber":["4443"]

When you have thirty engineers and twelve clusters, the friction ramps up. Each engineer needs IAM permissions scoped to the right SSM targets, a kubeconfig per cluster, and the muscle memory to remember which local port maps to which environment. Session logs capture that a session happened, but the actual kubectl commands inside the TLS tunnel are opaque unless you're also scraping Kubernetes audit logs and joining on timestamps.

CloudShell with VPC access

The April 2026 release made this genuinely useful for quick checks. You get a browser shell inside your VPC, kubectl is pre-installed, and it works against private endpoints. The catch is in the name: it's a shell, not a workstation. Sessions are ephemeral, there's no local tooling, no IDE integration, no way to run a script from your repo. AWS positions it for "short inspection tasks" for a reason. Nobody is going to debug a failing Helm release from CloudShell.

VPN or Direct Connect

A site-to-site VPN or Direct Connect circuit puts engineer laptops on the VPC network. kubectl works like the cluster is local. This is the classic approach and the one that scales worst. You're giving every engineer network-level reachability to everything in the VPC, not just the API server. Policy enforcement happens at the firewall layer, which was never designed to answer "should Jane be allowed to exec into pods in the payments namespace?" The audit trail is network flows, not user actions.

For regulated environments this is often the thing auditors flag first.

Zero trust access

The zero trust model inverts the question. Instead of putting the engineer on the network, you put a lightweight proxy inside the network that only brokers connections to specific resources, verified per request, tied to the engineer's IdP identity. This is how Twingate works.

For EKS specifically, this looks like deploying a Twingate Connector into the cluster itself (or a shared cluster in the same VPC), which then makes the private API server reachable to authorized users without any inbound firewall rules, without a bastion, and without anyone holding long-lived AWS or Kubernetes credentials.

What changes when you mandate private clusters org-wide

Once the SCP is in place, three things break for most teams:

1. CI pipelines that assumed a public endpoint need a new path in.

2. Break-glass access becomes harder to grant quickly during incidents.

3. Audit becomes louder: you've closed the public endpoint but now your kubectl traffic is tunneled through infrastructure your security team didn't design.

The question stops being "how do we lock down the API server" and becomes "how do we give engineers a daily workflow that doesn't quietly recreate the risk we just eliminated." Most bastion and SSM setups end up with a small number of highly-privileged IAM roles and shared kubeconfigs, which is the same lateral-movement risk taking the cluster private was supposed to reduce.

How Twingate handles private EKS access

Twingate's approach to private EKS doesn't require any new network path, any public exposure, or any credential outside the engineer's existing IdP login.

The Connector runs inside the cluster. You deploy it via the Twingate Kubernetes Operator, typically as a Helm chart. The Connector establishes an outbound TLS connection to Twingate's control plane. No inbound firewall rules on the VPC, no NAT changes, no public IPs. The EKS API endpoint stays private.

Install the Twingate Operator and deploy a Connector into your EKS cluster:

Identity passes through to the cluster. When an engineer runs kubectl, they authenticate through their IdP (Okta, Entra, Google, whatever you already use). Twingate verifies the identity on both the Client and the Connector before a connection is established. The engineer's IdP identity is what the cluster sees, which means native Kubernetes RBAC still handles authorization. No separate kubeconfig secrets handed out per engineer. No shared service account tokens.

The API server endpoint resolves transparently. The engineer runs kubectl get pods against the normal EKS endpoint hostname. Twingate's Client intercepts the DNS query, routes the traffic through the Connector inside the VPC, and the engineer's local tooling behaves as if the cluster were directly reachable. No local port forwarding, no https://localhost:4443, no mental overhead about which tunnel is which.

Per-user command logs stay on your infrastructure. For API server access and for Layer 7 traffic via Twingate's Identity Firewall, command-level activity can be logged and routed to your SIEM. The trail ties kubectl activity back to the IdP identity that executed it, not to a shared EC2 instance role or a bastion session.

One deployment pattern for every cluster. The Operator runs the same way whether you have one cluster or forty. No per-cluster bastion, no per-cluster SSM target to maintain, no per-engineer IAM policy to update when someone joins or leaves. Access changes happen in your IdP groups.

What to do next

If you're being pushed toward private-only EKS by the April 2026 SCP changes (or by your own security team, which is likely the same conversation), the thing worth doing first is auditing how your engineers reach clusters today. Count the bastions. Count the kubeconfigs in circulation. Count the IAM policies that grant SSM access to prod instances. That number is your real attack surface, and shrinking it is the actual goal — the private endpoint is just the easy part.

For the setup walkthrough, deployment manifests, and RBAC integration specifics, see the Twingate Kubernetes Operator documentation and the guide to securing EKS clusters.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.