DEV Community: Phu Hoang

OpenVPN on AWS: Secure Access to Private Infrastructure

Phu Hoang — Fri, 12 Jun 2026 01:11:08 +0000

Introduction

Many DevOps engineers and Site Reliability Engineers (SREs) have likely worked on projects where the highest priority during the early stages was always:

“Get the system running first.”

When deadlines are tight, infrastructure must be provisioned quickly, and environments need to be ready immediately for developers to deploy applications, many trade-offs are often made in exchange for deployment speed. SSH is exposed publicly for easier access. Grafana, Jenkins, or ArgoCD are directly accessible from the Internet for easier troubleshooting. Sometimes even databases are temporarily opened to public access simply so the team can move faster.

At that moment, everyone knows:

“This isn’t ideal.”

But most people also think:

““It can be improved later.”

Then real users start arriving, traffic increases, and the production environment begins operating at scale. And that is exactly when security debt starts demanding repayment.

Is it really safe when every service is exposed to the Internet?
How can engineers still access private resources without exposing the entire system?
How do we maintain operational convenience without turning production into a massive attack surface?

In this article, we will explore:

What VPN actually is
Why VPN remains extremely important
How OpenVPN works
A hands-on demonstration of deploying OpenVPN Access Server on AWS and securely accessing private resources.

This article shares practical lessons learned from operating real-world infrastructure.

Section 1 — VPN Fundamentals

1. What Is a VPN?

VPN (Virtual Private Network) is a technology that creates a private and encrypted connection over the public Internet infrastructure.

Instead of exposing the entire system directly to the Internet for access, we create a secure tunnel between the user’s computer and the internal system.

Once the VPN connection is established successfully, your device behaves almost as if it were located inside the company’s private network or cloud infrastructure.

That is why, after enabling VPN, you can:

SSH into private EC2 instances
Access internal databases
Open non-public Grafana dashboards
Interact with private Kubernetes API endpoints

From the system’s perspective, your laptop essentially becomes “a member” of the internal network.

2. What Problems Does VPN Solve?

One common misconception is that VPN is only used to change IP addresses, hide locations and stay anonymous. In reality, those are merely side effects. The true value of VPN lies in creating a secure connection between users and internal systems.

Accessing Private Resources from the Internet

❓If everything is publicly exposed to the Internet, access certainly becomes convenient — but it also means anyone on the Internet can “knock on the door.”

In properly designed systems, many resources are intentionally kept private, such as: EC2 instances, databases, Kubernetes control planes, Jenkins servers. However, operations teams still need daily access to them.

Developers need SSH access for debugging
DevOps engineers need monitoring access
SREs need to handle midnight incidents

✅ VPN solves this problem by creating a secure connection between the user device and the private network. After connecting to the VPN, users can access private resources as if they were operating inside the same internal network.

Reducing the Attack Surface

❓Every service exposed to the Internet — such as SSH, RDP, PostgreSQL, or administrative dashboards — can become a target for port scanning, brute-force attacks, vulnerability exploitation. As systems grow larger, temporarily exposing “just a few services” often evolves into dozens of security groups, numerous exceptions, complex rule chains. Eventually, the environment becomes difficult to manage securely.

✅ VPN reverses this mindset. Instead of exposing services and attempting to protect them afterward, we keep services private from the beginning. Only users with valid accounts, successful authentication, authorized VPN access can reach internal resources.

Replacing Traditional IP Whitelisting & Protecting Data on Public Networks

❓IP whitelisting is a common approach for restricting access by allowing only specific IP addresses. This works well... Until engineers work remotely, travel for business, use mobile networks, sit in coffee shops. Their IP addresses constantly change, leading to requests such as “Can you whitelist my new IP”, “My Wi-Fi changed”, “I’m at the airport”, “I urgently need production access”.

✅ VPN approaches the problem differently. Instead of trusting IP addresses, we trust user identities, certificates, authentication mechanisms, multi-factor authentication (MFA). As long as authentication succeeds, users can securely access the system from anywhere. VPN also creates an encrypted communication channel between the user device and the VPN server, protecting data during transmission.

3. How Does VPN Work?

Behind the seemingly simple “Connect” button, many components work together.

Authentication: Users must authenticate with the VPN server using username/password, certificates, MFA. Only authorized users can establish VPN connections
Tunneling Protocol & Encryption: After authentication succeeds, the VPN establishes an encrypted tunnel between the VPN client and VPN server. All traffic transmitted through this tunnel is encrypted. As a result VPN significantly reduces the risk of traffic sniffing when using public Wi-Fi. Common protocols include TLS, SSL, IPSec
Virtual Network Interface: Once the VPN connection is established, the operating system creates a virtual network interface. For example: Windows creates a new adapter, Linux creates tun0 or tap0 , macOS creates a similar interface. At the same time, the device receives an IP address belonging to the VPN network. At that moment, your laptop officially becomes part of the VPN network
Traffic Routing / Route Table: The VPN client receives required routes from the VPN server. As a result, traffic destined for private networks goes through the VPN tunnel, normal Internet traffic may still go directly to the Internet depending on configuration. This is exactly how Split Tunnel works
NAT: In many VPN deployment models, the VPN server performs NAT or routing to allow VPN clients to communicate with the private network behind it. Depending on the architecture, VPN clients may be routed directly, or NATed through the VPN server before accessing internal resources

4. Full Tunnel vs Split Tunnel

After a VPN connection is established, there are two common routing models.

Criteria	Full Tunnel	Split Tunnel
Traffic through VPN	All traffic	Only internal traffic
VPN Server bandwidth usage	High	Lower
Internet performance	Lower	Better
Level of control	High	Moderate
Suitable for	Enterprises needing full traffic control	DevOps, SRE, Cloud Infrastructure

Throughout this guide, we will use Split Tunnel to access private resources on AWS while allowing normal Internet traffic to go directly to the Internet.

Now that we understand the fundamentals of VPN technology, let’s explore why OpenVPN remains one of the most widely adopted VPN solutions today.

Section 2 — OpenVPN Solution Overview

1. Popular VPN Solutions

Today, many VPN solutions are available on the market. Each solution is designed for different use cases and environments.

Solution	Highlights	Suitable For
OpenVPN	Open-source, stable, widely adopted	Personal use, enterprise, cloud
WireGuard	High performance, modern, simple configuration	Cloud, Kubernetes, homelab
IPSec VPN	Traditional VPN standard integrated into networking devices	Enterprise networks
AWS Client VPN	AWS-managed VPN service	Pure AWS environments
Site-to-Site VPN	Connects two separate networks	Hybrid cloud, data centers

In this article, we choose OpenVPN because it is almost a “classic” technology in the infrastructure world:

Beginner-friendly
Large community support
Rich documentation
Multi-platform support
Excellent for understanding VPN fundamentals

Additionally, many modern VPN solutions still inherit concepts similar to OpenVPN, so understanding OpenVPN also helps explain how other VPN systems operate.

2. OpenVPN Community Edition vs Access Server

OpenVPN currently has two common deployment approaches:

OpenVPN Community Edition
OpenVPN Access Server

Although both are based on the same OpenVPN technology, they target different audiences.

Criteria	Community Edition	Access Server
Cost	Completely free	Free with limited concurrent connections
Management Interface	CLI	Web UI
User Management	Manual	Built-in
Certificate Management	Manual	Automated
Routing Configuration	Manual	Web UI
MFA Support	Manual setup	Built-in
Deployment Complexity	High	Low
Primary Use Case	Learning, deep customization	Fast deployment, easy operations

In this article, instead of spending too much time on manual configuration, we will use Access Server to focus more on VPN concepts, networking flow and operational workflows.

3. OpenVPN Access Server Architecture

One reason OpenVPN Access Server is widely adopted is because its architecture is relatively simple and easy to deploy.

In a basic deployment model, the Access Server acts as the gateway into the internal network.

When users connect to the VPN:

OpenVPN Access Server authenticates the user
A VPN tunnel is established
An IP address belonging to the VPN network is assigned
Required routes are pushed to the VPN client
Traffic is forwarded to internal resources

With the core concepts covered, we can now move on to deploying a practical OpenVPN environment on AWS.

Section 3 — Deploying OpenVPN Access Server on AWS

1. Demo Objective — Hands-On Time

At this stage, the theory should provide a solid understanding of what VPN is, how it works and why it appears in nearly every modern cloud system. So instead of continuing with concepts, we will build a real AWS lab environment to observe how VPN traffic behaves in a production-like environment.

The objectives of this demo are straightforward:

Connect a personal laptop to AWS through VPN
Access an EC2 instance located inside a private subnet
SSH into an instance without a public IP
Observe how traffic is routed through the VPN tunnel

If everything works correctly, our laptop connected from the public Internet will be able to access private infrastructure as if it were located inside the same internal network.

That is the real value of VPN in cloud environments.

2. AWS Architecture

To focus on VPN and networking flow instead of complicated infrastructure, we will use a minimal architecture consisting of:

1 VPC
1 Public Subnet
1 Private Subnet
1 OpenVPN Access Server
1 Private EC2 Instance

In this architecture:

OpenVPN Access Server accepts VPN connections from the Internet
The private EC2 instance has no public IP
All access to the private EC2 instance must go through the VPN

This architecture reflects how many organizations secure production environments on AWS.

3. Preparing AWS Infrastructure

The goal of this article is to focus on VPN and networking concepts rather than detailed infrastructure provisioning. Therefore, instead of manually creating every AWS resource, we will use a prepared Terraform configuration to provision the lab environment quickly.

Terraform Source Code

Terraform provisions the following components:

Resource	Purpose
VPC	Private network
Public Subnet	Hosts OpenVPN Access Server
Private Subnet	Hosts Private EC2
Internet Gateway	Provides Internet access
Route Table	Controls traffic routing
Security Group	Controls network access
EC2 Instance	OpenVPN Server with Elastic IP
EC2 Instance	Private test server without Public IP
Elastic IP	Public IP for OpenVPN Server

Instead of installing OpenVPN manually by:

Generating CA certificates
Creating certificates
Configuring daemons
Setting up routing
Configuring NAT
Managing iptables

we will use the official OpenVPN Access Server AMI from AWS Marketplace. This is a common real-world approach because it enables faster deployment, easier maintenance, practical lab and PoC environments.

Before Terraform can provision the EC2 instance using this AMI, AWS requires the account to subscribe to the Marketplace product first.

Access the OpenVPN Access Server Marketplace product:

AWS Marketplace Procurement Page

Then follow these steps:

→ Select Continue to Subscribe

→ Accept the terms and conditions (Accept Terms)

→ Wait until the status changes to Subscribed

Once completed, you can monitor the subscription status. Please note that the OpenVPN Access Server version used in this article is the BYOL (Bring Your Own License) edition. This version allows free usage with a limited number of concurrent connections, making it suitable for learning and testing purposes.

After completing the Marketplace subscription, we can begin setting up the lab environment. Make sure your computer has:

Install AWS CLI
Configure AWS credentials
Install Terraform CLI

Next, download the Terraform source code and provision the AWS infrastructure using the following commands:

terraform init
terraform plan
terraform apply -auto-approve

The provisioning process may take several minutes.

Once completed, Terraform outputs the public IP address assigned to the OpenVPN Access Server.

4. Installing OpenVPN Access Server

4.1 Creating an OpenVPN Access Server Account

Visit the following link: https://myaccount.openvpn.com/signin/product-select and register for a new account, or sign in using your Google or Microsoft account.

Select the Access Server product and complete the account information setup process.

You will then be redirected to the OpenVPN application console. From the Subscription menu, you will see the default subscription plan set to Free Plan, along with the Activation Key used to activate your OpenVPN Access Server instance. Copy this key for use in the next step.

4.2 Initial Setup

Once the EC2 instance has finished provisioning, OpenVPN Access Server is actually already pre-installed inside the instance through the AWS Marketplace AMI. However, the system still requires an initial setup before it can operate fully.

Access the openvpn-access-server EC2 instance through the AWS Console.

By default, when accessing the instance for the first time, OpenVPN Access Server will prompt you to perform the initial configuration. Alternatively, you can run the following command to start or re-run the setup process:

sudo ovpn-init

During the initial setup, you will be prompted to configure several settings. (You can type Yes or press Enter to use the default configuration.)

The setup process includes:

Accepting the license agreement
Confirming the Primary Node role
Selecting the network interface
Choosing the encryption algorithm
Configuring the ports for the Web Admin UI and OpenVPN Daemon
Setting the password for the Web Admin UI
Entering the Activation Key collected in the previous step
Configuring other optional settings

After the installation is completed, you will see both the Admin UI and Client UI URLs. Please note that these URLs use private IP addresses by default, so you will need to replace them with the corresponding public IP address when accessing them externally.

4.3 Accessing the Admin UI & Client UI

After the initial setup is completed, OpenVPN Access Server provides two interfaces:

Admin UI: used to manage users, routing, authentication, and VPN configurations.
Client UI: used to download the OpenVPN Client application, download connection profiles, and connect to the VPN.

Access the Admin UI in your web browser using the Public IP Address of the openvpn-access-server EC2 instance:

https://<Public-IP>:943/admin

Log in using the username openvpn and the password configured in the previous step. If you skipped that step, you will be prompted to set a new password.

By default, OpenVPN Access Server is typically configured to use the EC2 instance’s private IP address as the Server Address. You can verify this information under Server Details > Server address. However, in this lab environment, clients will connect from the public Internet. If the private IP address remains unchanged, the generated VPN profile will contain a private address, preventing external clients from connecting successfully.

Therefore, after logging into the Admin UI, we need to update the Server Address to use the Public IP Address, specifically the Elastic IP Address associated with the EC2 instance.

Navigate to the VPN Server menu:

→ Enter the Public IP Address in the Hostname (or IP address) field

→ Click the Save button

→ Click the Restart button

Wait for OpenVPN Access Server to restart. Afterward, you should verify that the Server Address has been updated to the public IP address.

The next step is very important. Access Controls, also known as Routing Policy, are used to route connections to private resources. In the Admin UI, create the first policy through the Access Controls menu:

→ Click the New Access Rule button

→ Enter the username openvpn

→ Enter the CIDR 10.0.0.0/16

→ Click Save rule

→ Click the Restart button to apply the configuration changes

Once the Access Controls configuration is completed, OpenVPN Access Server will begin pushing routes to VPN clients, allowing traffic destined for the VPC CIDR to be routed through the VPN tunnel into the AWS VPC. You will verify this behavior in the following steps.

Next, open a new browser tab and access the Client UI:

https://<Public-IP>:943/

Since you have already logged into the OpenVPN Admin UI, your session credentials will also be reused for the Client UI.

In this application, you will perform the following tasks:

Download and install the OpenVPN Client application for your computer or smartphone. Be sure to uncheck the option Include connection profile (User-locked) so that the connection profile can be customized later. OpenVPN clients are also available for multiple platforms including Windows, macOS, Linux, iOS, and Android.
Download the Connection Profile. All required routing information, certificates, and VPN configurations are already embedded inside this profile.

5. Configuring OpenVPN Client

At this point, the infrastructure setup is nearly complete. OpenVPN Access Server is now running on AWS, the client profile has been downloaded, and the private EC2 instance is quietly waiting inside the Private Subnet to be accessed.

Now comes the most interesting part: turning your laptop on the public Internet into a member of the private AWS network through three simple steps:

Open the OpenVPN Client application installed earlier.

Upload the Connection Profile file downloaded in the previous step.

Click Connect and enter your password.

The moment the Connect button is pressed, many things begin happening behind the scenes almost invisibly:

OpenVPN Client starts the handshake process with the VPN Server
Authentication is performed
A TLS tunnel is established
Certificates are validated
The route table is updated
A virtual network interface is created
A VPN IP address is assigned to the device

The entire process usually takes only a few seconds. If everything works correctly, the OpenVPN Client status will change to Securely Connected, along with a small traffic graph.

After the VPN connection is successfully established, your operating system will display a new virtual network interface. You can verify the new interface using the following commands:

# For Windows
ipconfig /all

# For macOS
ifconfig

# For Linux (Ubuntu, Debian, RHEL, ...)
ip addr show

If you want to dig a little deeper, you can also inspect your operating system’s route table. You will notice that traffic destined for the AWS VPC is now routed through the VPN interface instead of going directly to the Internet.

This mechanism that allows a private EC2 instance to remain without a Public IP address while still being securely accessible from your personal laptop.

6. Testing VPN Connectivity

From the AWS VPC’s perspective, your computer has now become a member of the internal network. You now have a “secure tunnel” that allows access to resources inside the Private Subnet — in this case, establishing an SSH connection to the private instance private-test-server.

When provisioning the AWS infrastructure, Terraform also creates an SSH key pair to provide authentication for the private instance. Run the following command to connect:

ssh -i vpn-demo-ssh-key.pem ec2-user@<Private-Instance-IP>

Please note that you should configure secure file permissions for vpn-demo-ssh-key.pem before executing the SSH command above.

Once you successfully connect to the private EC2 instance, it proves that:

The VPN tunnel is working correctly
Routing has been configured properly
Private resources can be accessed without exposing them to the public Internet

This is the true power of VPNs in cloud environments:

Keeping infrastructure private while still allowing operations teams to securely access resources whenever necessary.

At this point, everything is working successfully. You can try disconnecting the VPN session in the OpenVPN Client. The SSH connection will eventually time out because the private EC2 instance does not have a Public IP address and cannot be accessed directly from the Internet.

Section 4 — Conclusion

VPNs are far more than tools for masking IP addresses. It is also one of the most important solutions for protecting infrastructure and controlling access in cloud environments. Through this article, we explored the fundamental concepts of VPNs, how VPNs work, the problems they help solve, and successfully deployed OpenVPN Access Server on AWS to securely access private resources.

Although VPNs significantly improve security, the VPN Server itself is also a critical access point that must be carefully protected. Some recommended security best practices include:

Use strong passwords and avoid using default accounts
Enable MFA whenever possible
Restrict Security Groups following the principle of least privilege
Rotate credentials and certificates regularly
Avoid directly exposing internal resources to the public Internet
Monitor access logs to detect suspicious activities

Understanding VPN fundamentals is essential for building secure cloud infrastructure. OpenVPN provides a practical and accessible way to implement secure remote access while keeping critical systems private.

References

OpenVPN Documentation (https://openvpn.net/as-docs/)
AWS VPC Documentation (https://docs.aws.amazon.com/vpc/?utm_source=chatgpt.com)
AWS EC2 Documentation (https://docs.aws.amazon.com/ec2/?utm_source=chatgpt.com)

Amazon EKS From The Ground Up - Part 2: Worker Nodes with AWS Managed Nodes

Phu Hoang — Sat, 10 Jan 2026 08:03:00 +0000

Introduction

In Part 1, we successfully finished building the EKS Control Plane, we set up the VPC, Subnets, NAT Gateway, the Kubernetes API Server, and configured kubectl connectivity.

VPC, Subnets, NAT
Kubernetes API Server
An IAM role with enough permissions for the Control Plane
kubectl already connected to the cluster

But if you run:

kubectl get nodes

you’ll see… nothing.

That’s the real state of the cluster we created: it has a brain (Control Plane), but no hands and feet (Worker Nodes). Without compute capacity, the Kubernetes Scheduler can only stare at Pods stuck in the Pending state.

In this Part 2, we’ll “grow limbs” for your EKS cluster by deploying Worker Nodes using AWS Managed Nodes - the most practical middle ground between production readiness and operational effort.

This post won’t stop at “click and it works.” We’ll also explore what AWS quietly builds for you in a Managed Node Group, and contrast it with the Self-managed way so you understand the fundamentals and can debug with confidence.

📝A Quick Primer on Worker Nodes

What is a Worker Node, really?

In the most accurate - and simplest - definition:

A Worker Node is an EC2 instance configured to run Kubernetes workloads (Pods).

At minimum, every worker node runs:

kubelet — the agent that talks to the Kubernetes API Server
a container runtime — typically containerd
kube-proxy — manages service/network rules
AWS VPC CNI — the plugin that allocates Pod IPs from your VPC

Following production best practices, EKS worker nodes usually live inside private subnets without public IPs. That significantly reduces exposure: workloads are not directly reachable from the Internet, and outbound connectivity is handled through a NAT Gateway.

Worker Node Deployment Models

AWS offers three main ways to run compute for EKS, each with a different balance of control, operational cost, and “serverless-ness”:

Criteria	Managed Nodes	Self-managed Nodes	AWS Fargate
Infrastructure	EC2 Instances (partly managed by AWS)	EC2 Instances (fully managed by you)	Serverless (no nodes to manage)
Operational cost (OpEx)	Low	High	Very low
Control	Medium	Highest	Lowest
Billing	Per EC2 instance	Per EC2 instance	Per Pod (CPU/Mem)

Fargate hides almost everything—including the “node layer.” That’s convenient, but if your goal is to understand EKS fundamentals, the interesting engineering happens in Managed Nodes vs Self-managed Nodes.

Criteria	Managed Nodes (Managed Node Group)	Self-managed Nodes
Node creation	EKS Console or CLI command creates a Node Group	EC2 Launch Template + ASG + User Data (bootstrap)
ASG management	AWS manages the Auto Scaling Group lifecycle	You manage the ASG entirely
Cluster Join	AWS automatically handles the wiring and credentials for join	You must provide user data calling `/etc/eks/bootstrap.sh`
Node auth mapping (IAM→ RBAC)	AWS typically maps the Node Role automatically	You must manually update `aws-auth` to map the Node Role
Upgrades/Updates	Built-in, managed rolling update workflows	You design and manage `drain` / `replace` strategies
Debug level	Fewer common traps, higher abstraction	More control, but more responsibility for low-level configuration

What AWS does for you in a Managed Node Group

When you click Create Node Group, AWS typically handles a long checklist that Self-managed nodes would require you to build manually:

Creates an Auto Scaling Group
Picks an EKS-Optimized AMI compatible with your cluster version
Creates/manages a Launch Template (or uses one you provide)
Attaches an IAM Instance Profile using your Node IAM Role
Injects the bootstrap configuration so nodes can join the cluster
Automates the node registration path
Provides a rolling update workflow for node group upgrades
Typically handles node role mapping into the cluster auth mechanism

Recommendation: Use Managed Nodes for most production setups to reduce operational overhead. Choose Self-managed only when you have very specific requirements (custom OS hardening, special bootstrap, deep control of the node lifecycle).

Cluster IAM Role vs Node IAM Role

This is one of the most common points of confusion, so let’s make it crystal clear.

Cluster IAM Role

Used by the EKS Control Plane
Allows the Control Plane to manage ENIs and interact with your VPC resources

This role is not meant for workloads.

Node IAM Role

Worker nodes need a Node IAM Role to:

Join the cluster
Allow the VPC CNI to attach ENIs and allocate Pod IPs
Pull images from ECR
Access other required AWS APIs (later: secrets, parameters, logs, etc.)

Your worker nodes won’t become Ready without (at least) these managed policies:

Policy	Purpose
`AmazonEKSWorkerNodePolicy`	Join cluster, talk to the API Server
`AmazonEKS_CNI_Policy`	Attach ENIs, allocate Pod IPs
`AmazonEC2ContainerRegistryReadOnly`	Pull images from ECR

AWS IAM & Kubernetes Authentication

Access to an EKS cluster is a combination of two layers: AWS IAM & Kubernetes RBAC.

IAM = Authentication

IAM answers: “Who are you?”

When a principal (an EC2 node or a human user) calls the Kubernetes API Server, EKS uses IAM authentication to verify:

Which IAM principal (Role/User) the request comes from
Whether the request has a valid SigV4 signature

✅ This is why worker nodes must have a proper Node IAM Role attached.

Kubernetes RBAC = Authorization

RBAC answers: “What are you allowed to do?”

Even if IAM authentication succeeds, the API call can still fail with Forbidden if RBAC doesn’t grant the required permissions.

Bridging the two worlds: mapping IAM → Kubernetes identity

After IAM authentication, EKS maps IAM identity into Kubernetes users/groups so RBAC can evaluate permissions. Two common mechanisms exist:

aws-auth ConfigMap (classic, still widely used), example:

mapRoles: |
  - rolearn: arn:aws:iam::<account-id>:role/EKSNodeRole
    username: system:node:{{EC2PrivateDNSName}}
    groups:
      - system:bootstrappers
      - system:nodes

EKS Access Entries / Access Policies (newer Console-based approach)

For this article:

Nodes must be mapped into groups like system:bootstrappers and system:nodes
Humans/admins are commonly mapped to system:masters or granted an equivalent Access Policy

Hands-on Time

The AWS architecture after completing the steps below:

Step 0 — Preparation

Make sure all resources from Part 1 are created correctly and your cluster is ACTIVE.

Step 1 — Create the IAM Role for Worker Nodes

Open the AWS Console:

→ Go to IAM

→ Choose Roles → Create role

→ Configure Trusted entity:

Trusted entity type: AWS service
Service or use case: EC2
Use case: EC2

→ Click Next

→ Attach policies:

AmazonEKSWorkerNodePolicy
AmazonEKS_CNI_Policy
AmazonEC2ContainerRegistryReadOnly

→ Role name: EKSNodeRole

→ Click Create role

Step 2 — Create a Managed Node Group

→ Open the EKS service

→ Select cluster demo-eks-cluster

→ Go to Compute → Add node group

Configure node group

Name: eks-mng-general
Node IAM role: EKSNodeRole

→ Click Next.

Configure compute & scaling

AMI type: EKS optimized (Amazon Linux / Bottlerocket)
Capacity type: On-Demand
Instance type: t3.medium
Disk size: 20 GiB
Scaling:
- Desired: 2
- Min: 1
- Max: 3

→ Keep other settings as default.

→ Click Next.

Configure networking

Select only the two private subnets.

This is critical: subnet selection here determines where your worker nodes live. Private subnets are ideal for production worker nodes because they don’t expose instances to the Internet.

→ Click Next → Create.

Wait until the node group status becomes Active.

Step 3 - Join the Cluster - AWS handles it

You don’t need to manually configure bootstrap steps for a Managed Node Group - but understanding the join flow is what makes you effective at troubleshooting.

3.1 Node join flow

When you create a Managed Node Group, AWS launches EC2 worker nodes. Each instance gets an Instance Profile containing your Node IAM Role (EKSNodeRole). The join flow looks like this:

The EC2 instance boots using an EKS-Optimized AMI
Bootstrap config provides kubelet with:
- cluster name
- API endpoint
- cluster CA certificate
kubelet calls the Kubernetes API Server to register the node
EKS performs IAM authentication and identifies the IAM Role from the instance profile
EKS maps IAM identity → Kubernetes identity via aws-auth / Access Entries
If mapping is valid (node is in system:nodes), the node becomes Ready

In short: nodes don’t “join by Kubernetes magic.” They join because:

IAM authentication proves identity + Kubernetes group mapping allows the node role to function.

3.2 What Managed Node Group eliminates compared to Self-managed

With Self-managed nodes, you must build the join path yourself:

Create Launch Template (AMI, instance profile, user data)
Ensure bootstrap via /etc/eks/bootstrap.sh <cluster-name>
Create ASG and subnet placement
Manually update aws-auth to map the node role into:
- system:bootstrappers
- system:nodes

Managed Node Groups remove most of this plumbing.

Step 4 — Verify

This is the moment your EKS cluster finally starts to feel alive.

4.1 Verify with kubectl

→ Open a terminal and run:

kubectl get nodes -o wide

→ Then check system pods:

kubectl get pods -n kube-system

Expected results:

You should see two nodes (based on desired size), in Ready state
coredns, metrics-server, and kube-proxy should transition to Running

4.2 What AWS resources were created behind the scenes?

Now let’s satisfy curiosity and confirm what AWS created inside your account.

(1) Auto Scaling Group

→ Open EKS Service

→ Select EKS cluster demo-eks-cluster

→ Click Compute tab

→ Select node group eks-mng-general

→ In Details, click the Auto Scaling Group

Inside the ASG page, you’ll find:

Desired / Min / Max configuration
EC2 instances in InService
Launch Template reference
Security Groups

(2) Launch Template

From the ASG page:

→ Click the Launch template link.

You’ll see:

AMI ID
Instance type
Security groups attached
User data/bootstrap wiring (partly hidden, but it’s there)

(3) Security Group for worker nodes

From the ASG details page

→ Click the Security group IDs.

Review inbound/outbound rules applied to worker nodes.

Common Pitfalls

1) Node group is Active, but `kubectl get nodes` shows nothing

Likely causes:

The node group is using the wrong IAM role (not EKSNodeRole)
Node IAM role is missing required policies
Wrong subnet selection or private subnet route tables are incorrect

2) Instances keep launching and terminating in the ASG

Likely causes:

Instance type capacity shortage → try a more common type (t3.large, m5.large, etc.)
Subnet/AZ constraints → expand to more AZs/subnets
EC2 quota limits → request quota increase

3) Pods stuck in `Pending`

Likely causes:

Insufficient node resources (CPU/memory) → choose a larger instance type
Taints/labels preventing scheduling → remove taints or adjust selectors

4) `ImagePullBackOff` / `ErrImagePull`

Likely causes:

Private subnets have no NAT gateway, or routes are wrong
DNS resolution is broken → check VPC settings (DNS resolution and DNS hostnames)

Summary

In Part 2, we:

Added production-style worker nodes (private subnets) so workloads finally have somewhere to run
Clearly separated Cluster Role vs Node Role
Covered the IAM → Kubernetes authentication story
Explored what a Managed Node Group creates behind the scenes

Next, in Part 3, we’ll go deeper into EKS networking: VPC CNI, ENIs, Pod IP allocation, and traffic flow debugging.

Amazon EKS From The Ground Up - Part 1: Control Plane & Infrastructure

Phu Hoang — Thu, 25 Dec 2025 10:25:30 +0000

Introduction

As a DevOps engineer, the ability to provision and manage Kubernetes clusters efficiently is essential. Amazon EKS (Elastic Kubernetes Service) makes this significantly easier—you can create an EKS cluster with just a single command or a few clicks in the AWS Console.

While you’re sipping your coffee, however, a lot is happening behind the scenes.

This article is the first part of a deep-dive series that breaks down those behind-the-scenes actions. We will examine the components that make up an Amazon EKS cluster, focusing specifically on the Infrastructure layer and IAM & Security, which form the foundation of everything that comes later.

A Brief Concept of EKS

Amazon EKS is a managed Kubernetes service that allows you to run Kubernetes without having to operate the Control Plane yourself.

In simple terms, EKS handles the two most difficult aspects of running Kubernetes:

Setting up and managing the Control Plane

The Control Plane is the “brain” of Kubernetes. It consists of the API server, the etcd database (which stores cluster state), the scheduler, and the controller manager. AWS ensures that this Control Plane is highly available, secure, and continuously patched.
Deep integration with AWS services

EKS tightly integrates Kubernetes with core AWS services such as VPC networking, IAM-based security, and Elastic Load Balancing.

Building the Foundation – Infrastructure First

A very common misconception among newcomers is the following:

EKS = Kubernetes, and AWS handles everything.

In reality, EKS is split into two distinct responsibility domains:

Component Partition	Components	Management Responsibility
AWS-managed (Control Plane)	API Server, etcd, Scheduler, Controller Manager	AWS (not configurable)
Your AWS Account (Data Plane & Networking)	VPC, Subnets, Security Groups, IAM Roles, EC2 Worker Nodes or Fargate Pods	You (must be designed and maintained)

For this reason, the remainder of this article focuses on the infrastructure that you are responsible for, before the EKS Control Plane is even created.

Step 0 – Preparing the Tools

Before creating the EKS cluster, ensure you have the following ready:

An AWS account with access to the AWS Console
AWS CLI installed and configured
kubectl installed

Although this article is console-first, we will use the CLI to verify and explain what happens under the hood.

Step 1 – Preparing the VPC

The EKS Control Plane itself does not run inside your VPC. However, you still need a VPC for:

EC2 worker nodes
Pod IP address allocation
Security groups to control traffic
Internet or NAT access for outbound communication

In short: without a properly designed VPC, EKS cannot function.

1.1. Actions in the AWS Console

→ Open the Amazon VPC service

→ Click Create VPC

→ Choose VPC and more

Recommended Configuration (Practice / Production-Ready Baseline)

Component	Value	Notes
Name	`eks-demo-vpc`
IPv4 CIDR	`10.0.0.0/16`
Availability Zones	2	High availability
Public subnets	2	Used for NAT Gateways and public load balancers
Private subnets	2	Where worker nodes will run
NAT Gateway	1 per AZ	Required for outbound access
DNS Hostnames	Enabled	Required for nodes to resolve the API server

Step 2 – Adding Tags to Subnets

Amazon EKS does not automatically infer which subnets it should use. Many EKS features—especially the AWS Load Balancer Controller—depend entirely on subnet tags.

2.1. Required Tags

Cluster discovery tag (required on all subnets):

kubernetes.io/cluster/demo-eks-cluster = shared

Public load balancer subnets (public subnets only):
```
kubernetes.io/role/elb=1
```
Internal load balancer subnets (private subnets only):
```
kubernetes.io/role/internal-elb =1
```

Incorrect or missing tags are one of the most common causes of load balancer failures in EKS.

2.2. Actions in the AWS Console

→ Open VPC → Subnets

→ Locate subnets named eks-demo-subnet-*

→ Select eks-demo-subnet-public1

→ Open the Tags tab → Manage tags

→ Add tags:

kubernetes.io/cluster/demo-eks-cluster = shared
kubernetes.io/role/elb = 1

→ Save

Repeat for eks-demo-subnet-public2.

For each private subnets, add tags:

kubernetes.io/cluster/demo-eks-cluster = shared
kubernetes.io/role/internal-elb = 1

Step 3 - Add a dedicated Security Group for the EKS Cluster

In this step, we’ll create a separate Security Group for the EKS cluster. The goal is to establish a clean security boundary early (even if you’re still in the “control plane only” stage).

Inbound: allow internal traffic within the same Security Group so EKS-related components that share this SG can communicate with each other.
Outbound: allow outbound traffic so the cluster and its components can reach required endpoints (e.g., AWS APIs, image registries, etc.).

Note: This is a learning/bootstrapping-friendly baseline. In production, you typically tighten inbound/outbound rules based on actual traffic requirements.

3.1. Actions in the AWS Console

→ Open VPC service

→ Go to Security Groups

→ Configure the Security Group

Security group name: eks-cluster-sg
VPC: eks-demo-vpc

→ Add (or keep) this outbound rule:

Type	Protocol	Port range	Destination
All traffic	All	All	0.0.0.0/0

→ Then click Create security group.

Now we’ll allow “intra-SG” traffic:

→ Select the Security Group eks-cluster-sg

→ Open the Inbound rules tab → click Edit inbound rules

→ Add a new rule:

Type	Protocol	Port range	Source
All traffic	All	All	Custom → Security group: `eks-cluster-sg`

→ Save the rule.

Step 4 – Creating the IAM Role for the EKS Control Plane

Although AWS manages the Control Plane, it still needs permissions to interact with resources in your AWS account, such as:

Creating and managing ENIs
Attaching security groups
Communicating with VPC resources

This is achieved through an IAM Role that the EKS service assumes.

4.1. Actions in the AWS Console

→ Open IAM → Roles

→ Click Create role

→ Trusted entity:

Type: AWS service
Service: EKS
Use case: EKS – Cluster

→ Continue to permissions

AmazonEKSClusterPolicy is attached automatically

→ Name the role: EKSClusterRole

→ Create the role

4.2. Trust Policy Explanation

The role’s trust policy contains the following statement:

{
    "Effect":"Allow",
    "Principal":{
        "Service":"eks.amazonaws.com"
    },
  "Action":"sts:AssumeRole"
}

This means:

“Allow the EKS service to assume this role and call AWS APIs using the permissions defined in AmazonEKSClusterPolicy.”

Granting only this policy follows the Principle of Least Privilege and is sufficient for the Control Plane to operate correctly.

Step 5 – Creating the EKS Cluster

With the infrastructure and IAM role in place, we can now create the Control Plane.

5.1. Actions in the AWS Console

→ Open Amazon EKS

→ Click Create cluster

→ Choose Custom configuration

→ Disable EKS Auto Mode

In Cluster Configuration step:

→ Name: demo-eks-cluster

→ IAM role: EKSClusterRole

→ Kubernetes version: 1.34 (latest stable at the time of writing)

→ Leave other settings as default

In Networking Configuration step:

→ VPC: eks-demo-vpc

→ Subnets: select all 4 subnets

→ Security group: eks-cluster-sg

→ Endpoint access: Public and Private

Public + Private access allows management from your local machine while ensuring worker nodes communicate internally within the VPC.

In Logging Configuration step:

→ Enable the following logs (recommended):

API server
Audit
Authenticator

In Add-ons Configuration step:

→ Keep the AWS-recommended defaults:

kube-proxy
Amazon VPC CNI
Node monitoring agent
CoreDNS
Amazon EKS Pod Identity Agent
External DNS
Metrics Server

→ Click Create and wait for the cluster status to become Healthy.

Behind the scenes, this is equivalent to:

aws eks create-cluster \
  --name demo-eks-cluster \
  --role-arn arn:aws:iam::<account-id>:role/EKSClusterRole \
  --resources-vpc-config subnetIds=<subnet-public1>,<subnet-public2>,<subnet-private1>,<subnet-private2>

Which do you prefer AWS Console or AWS CLI? 😉

Step 6 – Connecting and Verifying the Cluster

Once the cluster is ACTIVE, connect to it from your local machine.

6.1 Fetching the kubeconfig

aws eks update-kubeconfig --name demo-eks-cluster --region us-east-1

This command:

Retrieves the API endpoint
Updates ~/.kube/config
Configures authentication using your current IAM identity

6.2 Verifying the Cluster

kubectl cluster-info
kubectl get namespaces
kubectl get nodes

Expected Results

cluster-info: API server is reachable
get namespaces: default namespaces are listed
get nodes: no nodes returned

This is expected.

The Control Plane is ready, but no worker nodes exist yet, so Kubernetes has no compute capacity to schedule Pods. Core system Pods such as CoreDNS remain in the Pending state.

Conclusion

In this first part of the series, we built the foundation of an Amazon EKS cluster from the ground up:

Designed a production-ready VPC with properly tagged subnets
Created an IAM role for the EKS Control Plane
Provisioned the EKS Control Plane with secure endpoint access
Verified connectivity while intentionally stopping before worker nodes

At this point, we have built the brain of Kubernetes.

It is powered on, networked, and authorized—but it is still waiting for its “hands”.

DEV Community: Phu Hoang

OpenVPN on AWS: Secure Access to Private Infrastructure

Introduction

Section 1 — VPN Fundamentals

1. What Is a VPN?

2. What Problems Does VPN Solve?

Accessing Private Resources from the Internet

Reducing the Attack Surface

Replacing Traditional IP Whitelisting & Protecting Data on Public Networks

3. How Does VPN Work?

4. Full Tunnel vs Split Tunnel

Section 2 — OpenVPN Solution Overview

1. Popular VPN Solutions

2. OpenVPN Community Edition vs Access Server

3. OpenVPN Access Server Architecture

Section 3 — Deploying OpenVPN Access Server on AWS

1. Demo Objective — Hands-On Time

2. AWS Architecture

3. Preparing AWS Infrastructure

4. Installing OpenVPN Access Server

4.1 Creating an OpenVPN Access Server Account

4.2 Initial Setup

4.3 Accessing the Admin UI & Client UI

5. Configuring OpenVPN Client

6. Testing VPN Connectivity

Section 4 — Conclusion

References

Amazon EKS From The Ground Up - Part 2: Worker Nodes with AWS Managed Nodes

Introduction

📝A Quick Primer on Worker Nodes

What is a Worker Node, really?

Worker Node Deployment Models

What AWS does for you in a Managed Node Group

Cluster IAM Role vs Node IAM Role

Cluster IAM Role

Node IAM Role

AWS IAM & Kubernetes Authentication

IAM = Authentication

Kubernetes RBAC = Authorization

Bridging the two worlds: mapping IAM → Kubernetes identity

Hands-on Time

Step 0 — Preparation

Step 1 — Create the IAM Role for Worker Nodes

Step 2 — Create a Managed Node Group

Configure node group

Configure compute & scaling

Configure networking

Step 3 - Join the Cluster - AWS handles it

3.1 Node join flow

3.2 What Managed Node Group eliminates compared to Self-managed

Step 4 — Verify

4.1 Verify with kubectl

4.2 What AWS resources were created behind the scenes?

Common Pitfalls

1) Node group is Active, but kubectl get nodes shows nothing

2) Instances keep launching and terminating in the ASG

3) Pods stuck in Pending

4) ImagePullBackOff / ErrImagePull

Summary

Amazon EKS From The Ground Up - Part 1: Control Plane & Infrastructure

Introduction

A Brief Concept of EKS

Building the Foundation – Infrastructure First

Step 0 – Preparing the Tools

Step 1 – Preparing the VPC

1.1. Actions in the AWS Console

Step 2 – Adding Tags to Subnets

2.1. Required Tags

2.2. Actions in the AWS Console

Step 3 - Add a dedicated Security Group for the EKS Cluster

3.1. Actions in the AWS Console

Step 4 – Creating the IAM Role for the EKS Control Plane

4.1. Actions in the AWS Console

4.2. Trust Policy Explanation

Step 5 – Creating the EKS Cluster

5.1. Actions in the AWS Console

Step 6 – Connecting and Verifying the Cluster

6.1 Fetching the kubeconfig

6.2 Verifying the Cluster

Expected Results

1) Node group is Active, but `kubectl get nodes` shows nothing

3) Pods stuck in `Pending`

4) `ImagePullBackOff` / `ErrImagePull`