Secure Private EKS Access and SSO-Protected Frontends with Cloudflare Tunnel on EC2
How to replace VPN infrastructure with a Cloudflare Tunnel to provide both zero-trust VPC access via WARP and SSO-gated frontend…
Secure Private EKS Access and SSO-Protected Frontends with Cloudflare Tunnel on EC2
How to replace VPN infrastructure with a Cloudflare Tunnel to provide both zero-trust VPC access via WARP and SSO-gated frontend application delivery through a private ALB on public domains.

What I Built
The system uses a Cloudflare Tunnel running on a single EC2 instance to provide WARP routing for engineers to access private VPC resources and application-level ingress that exposes frontend apps on public subdomains with SSO enforcement. The entire underlying infrastructure remains private with no inbound ports exposed to the internet.
System Architecture
The architecture routes two distinct access patterns through a single tunnel instance based on the following components:
EC2 instance — A t4g.micro instance running RHEL 9 in a private subnet with no public IP, no SSH access, and no inbound ports.
Cloudflare Tunnel — A daemon running on the EC2 instance that establishes outbound QUIC connections to Cloudflare’s edge to route VPC traffic.
Cloudflare Access Applications — An identity-aware reverse proxy configuration mapping public subdomains to the private ALB.
Private ALB — An internal AWS Application Load Balancer fronting frontend services in EKS.
AWS Secrets Manager — External storage for the Cloudflare tunnel token.
Security group — A restrictive network boundary with egress-only rules for the EC2 instance and ingress allowed from the tunnel to VPC resources.
IAM role — An identity role scoped strictly to Secrets Manager and SSM access.
EKS cluster security group rule — A firewall rule allowing ingress traffic from the tunnel instance.
Management happens exclusively through SSM Session Manager.
Core Technical Behavior
On boot, the EC2 instance retrieves the tunnel token from AWS Secrets Manager and starts the cloudflared daemon as a systemd service. The daemon establishes outbound QUIC connections on ports 7844–7845 to Cloudflare’s edge.
For engineer access, team members with the WARP client enrolled in the Zero Trust organization route traffic to private VPC addresses. Commands hit the EKS API server directly, and database connections reach RDS instances through the tunnel.
For frontend access, Cloudflare Access intercepts browser requests to public subdomains like app.jakops.cloud and presents an SSO login page backed by an identity provider. Upon authentication, Cloudflare forwards the request through the tunnel to the private ALB, which routes traffic to the frontend pods running in EKS. Cloudflare handles TLS termination, DNS, and identity verification at the edge.
One-line caption for the egress security group rule
egress {
from_port = 7844
to_port = 7845
protocol = "udp"
cidr_blocks = ["0.0.0.0/0"]
description = "Allow outbound QUIC for Cloudflare Tunnel"
}
One-line caption for the ingress security group rule
ingress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = [var.vpc_cidr_block]
description = "Allow all traffic from VPC for WARP routing"
}
Key Engineering Decisions
Dual-purpose tunnel handles both WARP routing for L3/L4 VPC access and Cloudflare Access applications for L7 ingress with identity enforcement on a single instance.
Public domains point to Cloudflare’s edge while keeping the underlying AWS infrastructure completely private without public load balancers or internet-facing security groups.
SSO authentication happens at the Cloudflare edge before traffic reaches the VPC, removing the need for frontend applications to implement internal auth gates.
Private ALB usage eliminates the DDoS surface, certificate management burden, and public security group rules by accepting external traffic exclusively through the tunnel.
ARM architecture selection using a t4g.micro instance reduces compute costs because cloudflared is a lightweight Go binary that does not require heavy compute headroom.
Hardcoded AMI pinning prevents unexpected instance replacements during terraform apply operations when new base images are published.
Single instance configuration without an Auto Scaling Group relies on manual recreation via terraform apply, as sub-minute recovery was not a requirement for this staging environment.
IMDSv2 is enforced on the EC2 instance to block SSRF-based credential theft from the instance metadata endpoint.
Dedicated system user execution ensures the cloudflared process runs as a non-login user with no shell to minimize blast radius.
KMS-encrypted EBS root volume protects data at rest using a customer-managed key.
Trade-offs
Optimized for: cost, simplicity, zero-trust posture, unified access control, operational minimalism, elimination of public attack surface.
Sacrificed: high availability (single instance), self-healing (no ASG), automated AMI rotation, independent scaling of frontend proxy vs. WARP routing, centralized logging (logs stay on-instance via journald).
Results / Cost Impact
The architecture reduced running infrastructure costs to a total of approximately $7.33 per month.
t4g.micro (on-demand) — ~$6.13
8GB GP3 EBS — ~$0.80
Secrets Manager secret — ~$0.40
This setup eliminated the need for a managed VPN solution, public ALB, WAF, public DNS configuration, and ACM certificate validation, which previously cost over $75 per month. Operationally, frontend delivery requires no certificate rotation, WAF rule management, or public security group auditing.
Conclusion
A Cloudflare Tunnel on a single EC2 instance provides zero-trust network access for engineers via WARP and SSO-protected frontend delivery on public subdomains. By keeping the AWS infrastructure private and routing traffic through Cloudflare’s edge, the environment remains secure and invisible to the internet.
Combining WARP routing with Cloudflare Access applications on a single tunnel gives you both L3 infrastructure access and L7 application delivery with SSO on real domains with zero public infrastructure for under $8/month.
Further Reading
For the full implementation details, see the complete article at jakops.cloud.
Need Help?
If you want to deploy a zero-trust setup including Cloudflare Tunnel on EC2, WARP routing, private ALB ingress for EKS, and Terraform modules with IMDSv2 and KMS encryption, you can find assistance directly at https://jakops.cloud.
메타데이터
- post_id
- 4a446d178c5b
- slug
- secure-private-eks-access-and-sso-protected-frontends-with-cloudflare-tunnel-on-ec2-4a446d178c5b
- url
- https://medium.com/@jakops/secure-private-eks-access-and-sso-protected-frontends-with-cloudflare-tunnel-on-ec2-4a446d178c5b
- canonical_url
- https://medium.com/@jakops/secure-private-eks-access-and-sso-protected-frontends-with-cloudflare-tunnel-on-ec2-4a446d178c5b
- author_url
- https://medium.com/@jakops
- status
- ok
- fetched_at
- 2026-08-04 04:36:11