Kubernetes on Riveroverflow

Building an AWS ALB-Based Gateway API

Mon, 11 May 2026 13:39:22 +0900

AWS Load Balancer Controller lets you manage Elastic Load Balancers in Kubernetes environments.
It supports resource types such as Ingress and LoadBalancer, and on AWS it can provision Application Load Balancers, Network Load Balancers, and Classic Load Balancers.

⚙️ How It Works

For Ingress

Reconciliation Flow

For a single Ingress resource, the controller behaves as follows:

The controller watches Ingress events from the API server.
If the conditions are met, it starts creating AWS resources.
An ALB is created for the new Ingress resource.
It can be either internet-facing or internal.
AWS creates target groups based on the Ingress resource.
Listeners are created for the configured ports. By default, ports 80 or 443 are used.
You can also attach certificates through annotations.
Rules are created from the Ingress definition.
Traffic is then routed to the appropriate Kubernetes Service.

The Load Balancer Controller also performs the following tasks:

Removes related AWS resources when an Ingress is deleted in Kubernetes
Updates AWS resources when an Ingress changes
Reconstructs and reconciles related AWS resources after the controller restarts

Traffic Handling

The Load Balancer Controller supports two traffic modes:

Instance mode (default): The ALB sends traffic to Kubernetes nodes, which then forward it through the Service’s NodePort.
IP mode: The ALB sends traffic directly to Kubernetes pods. Your CNI must support direct access to pod IPs.
- This reduces hops and generally provides better performance.
- Configure it with the alb.ingress.kubernetes.io/target-type: ip annotation.

For Gateway API

The controller follows a reconciliation loop like this:

API Monitoring: The controller continuously monitors Gateway API resources through the API server.
Queueing: Detected resources are added to an internal queue.
Processing: For each queued item:
- It checks whether the referenced GatewayClass is managed by its controller. In other words, it verifies that spec.controllerName in the GatewayClass is either gateway.k8s.aws/alb or gateway.k8s.aws/nlb.
- Gateway API definitions are mapped to AWS resources such as NLB/ALB listeners, rules, target groups, and add-ons.
- The mapped resources are compared against the actual AWS state.
  If the current state differs from the desired state, the controller calls the AWS API to synchronize it.
Status Updates: After reconciliation, the controller updates the status field of the Gateway resource.
This provides real-time feedback such as the load balancer DNS name, ARN, and whether the Gateway has been accepted and programmed.

NOTE: If this is Gateway API, why does it also support NLB?
Gateway API is not limited to L7 routing. It can also replace L4 routing scenarios.
In other words, it can serve as an alternative to type: LoadBalancer.
A single Gateway cannot mix route types from different layers.
For example, HTTPRoute and TCPRoute cannot be used on the same Gateway.

L7 Gateway: HTTPRoute, GRPCRoute

L4 Gateway: TCPRoute, UDPRoute, TLSRoute

Gateway API also supports both Instance mode and IP mode.

🚀 Installing AWS Load Balancer Controller

Installation with Helm

Add the Helm repository with the following command:

1

helm repo add eks https://aws.github.io/eks-charts

1
2
3
4
5
6
7
8
9


helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
 -n kube-system \
 --version 3.33.0 \
 --set clusterName = <cluster_name> \
 --set region = <aws_region> \
 --set vpcId = <vpc_id> \
 --set serviceAccount.create = true \
 --set serviceAccount.name = aws-load-balancer-controller \
 --set controllerConfig.featureGates.ALBGatewayAPI = true # Important: required for ALB Gateway API

Or you can define the Helm values in values.yaml and install from that:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# values.yaml
clusterName: <clutser_name>
region: <aws_region>
vpcId: <vpc_id>

serviceAccount:
 create: true
 name: aws-load-balancer-controller

controllerConfig:
 featureGates:
 ALBGatewayAPI: true

1
2
3
4


helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
 -n kube-system \
 --version 3.33.0 \
 -f values.yaml

Other useful values

In addition to the Helm values above, you may also want to consider the following:

autoscaling: Adds an HPA for the controller. It can be useful if changes happen frequently.
enableWafv2: Enables integration with AWS WAF v2.
enableCertManager: Lets cert-manager manage the TLS certificates used by the admission webhook.

For more details, refer to this README.

📝 Hands-on Example

We will create an ALB-based Gateway API setup to provide L7 rule-based routing.
We will attach ACM for TLS termination, apply WAF ACL rules, and enable S3 access logging.
We will also create a policy that blocks external access to the /metrics path.

Required components

An EKS cluster
AWS Load Balancer Controller (see the installation section above)
- The controller must assume a role through IRSA or Pod Identity with the IAM policy required to access AWS APIs
The installation manifest from the Gateway API CRD

Additional components

Route53 Hosted Zone, ACM Certificate, and External-DNS

These are listed as additional components, but in practice they are almost mandatory.
In real environments, you usually do not expose an ALB by itself. You attach a custom domain.

Below is an example Terraform configuration that creates a Route53 hosted zone and issues an ACM certificate.
If you purchased the domain in the AWS console, the hosted zone may already exist and should then be imported.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


resource "aws_route53_zone" "main" {
 name = var.root_domain_name
}

resource "aws_acm_certificate" "alb" {
 domain_name = var.root_domain_name
 subject_alternative_names = var.certificate_subject_alternative_names
 validation_method = "DNS"

 lifecycle {
 create_before_destroy = true
 }
}

resource "aws_route53_record" "alb_acm_validation" {
 for_each = {
 for dvo in aws_acm_certificate.alb.domain_validation_options :
 dvo.domain_name => {
 name = dvo.resource_record_name
 record = dvo.resource_record_value
 type = dvo.resource_record_type
 }
 }

 allow_overwrite = true
 zone_id = aws_route53_zone.main.zone_id
 name = each.value.name
 type = each.value.type
 ttl = 60
 records = [each.value.record]
}

resource "aws_acm_certificate_validation" "alb" {
 certificate_arn = aws_acm_certificate.alb.arn
 validation_record_fqdns = [for record in aws_route53_record.alb_acm_validation : record.fqdn]
}

## Variables
variable "root_domain_name" {
 description = "Primary public DNS zone managed in Route 53."
 type = string
 default = "example.com"
}

variable "certificate_subject_alternative_names" {
 description = "Additional DNS names to include in the shared ACM certificate."
 type = list(string)
 default = ["*.example.com"]

 validation {
 condition = length(var.certificate_subject_alternative_names) > 0
 error_message = "At least one subject alternative name must be provided."
 }
}

You can install External-DNS from here.

Below is an example Helm values file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


provider:
 name: aws

serviceAccount:
 create: true
 name: external-dns

# See the following for available source types:
# https://kubernetes-sigs.github.io/external-dns/latest/docs/sources/about/
sources:
 - gateway-httproute

env:
 - name: AWS_DEFAULT_REGION
 value: ap-northeast-2

domainFilters:
 - example.com

policy: upsert-only

registry: txt
txtOwnerId: my-web

The required IAM policy is shown below.
Attach this policy through IRSA or Pod Identity.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "route53:ChangeResourceRecordSets",
 "route53:ListResourceRecordSets",
 "route53:ListTagsForResources"
 ],
 "Resource": [
 "arn:aws:route53:::hostedzone/*"
 ]
 },
 {
 "Effect": "Allow",
 "Action": [
 "route53:ListHostedZones"
 ],
 "Resource": [
 "*"
 ]
 }
 ]
}

External-DNS works with the following logic:

External-DNS extracts DNS name candidates from HTTPRoute and similar resources
- spec.hostname
- external-dns.alpha.kubernetes.io/hostname
It identifies the parent Gateway from the parents section in the HTTPRoute status
It checks whether the Gateway accepted the route
It matches Gateway listeners with the route information
It checks Gateway.status.addresses[].value to find the load balancer address
It creates the DNS records

WAFv2 regional ACL

You can create a WAFv2 ACL with regional scope and attach it to the ALB.
In this example, you create only the ACL itself, not the association.
The Load Balancer Controller will create the association for the ALB.

S3 for access logging

ALB access logs can be written directly to S3, not to a CloudWatch log group.
The following options are generally recommended:

Lifecycle policy
Block Public Access
KMS encryption when needed

For the ALB to write logs to S3, the following policy must be attached to the S3 bucket:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


{
 "Version":"2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Service": "logdelivery.elasticloadbalancing.amazonaws.com"
 },
 "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix/AWSLogs/123456789012/*"
 }
 ]
}

GatewayClass

You must select gateway.k8s.aws/alb in spec.controllerName.

1
2
3
4
5
6
7


# GatewayClass.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
 name: aws-alb-gateway-class
spec:
 controllerName: gateway.k8s.aws/alb

LoadBalancerConfiguration

LoadBalancerConfiguration is a CRD available after installing AWS Load Balancer Controller, and it lets you configure additional AWS ELB settings.
The Gateway resource contains options that fit the Gateway API specification, while this CRD holds the AWS-specific configuration.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


apiVersion: gateway.k8s.aws/v1beta1
kind: LoadBalancerConfiguration
metadata:
 name: alb-config
 namespace: kube-system
spec:
 # Whether the load balancer should have a public or internal IP
 scheme: internet-facing
 ipAddressType: ipv4
 # Attach certificate information
 listenerConfigurations:
 - protocolPort: HTTPS:443
 defaultCertificate: <ARN of ACM Certificate>
 # For sslPolicy, see: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html
 sslPolicy: ELBSecurityPolicy-TLS13-1-2-2021-06
 # Attach WAF (use the ARN of the regional WAFv2 ACL)
 wafV2:
 webACL: <ARN of wafv2 regional web acl)
 # Configure the load balancer to store access logs in S3
 loadBalancerAttributes:
 - key: access_logs.s3.enabled
 value: "true"
 - key: access_logs.s3.bucket
 value: <s3 bucket name>
 - key: access_logs.s3.prefix
 value: ""
 # Used to control which subnets the load balancer is attached to
 loadBalancerSubnets:
 - identifier: <subnet-id>

If loadBalancerSubnets is left empty, the AWS subnets must have the following tags:

For a public load balancer (internet-facing): "kubernetes.io/role/elb" = "1"
For a private load balancer (internal): "kubernetes.io/role/internal-elb" = "1"

Gateway

The Gateway must reference the name of the GatewayClass.
It can also reference the LoadBalancerConfiguration to use additional load balancer options.
Once the Gateway resource is created, the actual AWS ELB is provisioned and mapped to listeners.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
 name: aws-alb-gateway
 namespace: kube-system
spec:
 # Must reference the GatewayClass name
 gatewayClassName: aws-alb-gateway-class
 # Can reference additional ALB options
 infrastructure:
 parametersRef:
 kind: LoadBalancerConfiguration
 name: alb-config
 group: gateway.k8s.aws
 listeners:
 - name: http
 protocol: HTTP
 port: 80
 hostname: www.example.com
 allowedRoutes:
 namespaces:
 from: Selector
 selector:
 matchLabels:
 # The namespace name must be my-web
 kubernetes.io/metadata.name: my-web
 - name: https
 protocol: HTTPS
 port: 443
 hostname: www.example.com
 allowedRoutes:
 namespaces:
 from: Selector
 selector:
 matchLabels:
 kubernetes.io/metadata.name: my-web

HTTPRoute

HTTPRoute is mapped to actual rules and target groups.
In this example there are two rules. One blocks external requests to /metrics.
This is explained in more detail below.
The second rule forwards traffic for the root path (/) to the web server.
If multiple prefixes match, PathPrefix prefers the more specific path.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
 name: my-web
 namespace: my-web
 labels:
 app: my-web
 app.kubernetes.io/name: my-web
spec:
 # Maps to Gateway listeners
 parentRefs:
 - name: my-alb-gateway # Gateway name
 namespace: kube-system
 sectionName: http # Listener name
 - name: my-alb-gateway
 namespace: kube-system
 sectionName: https
 # Hostname to receive. External-DNS creates records from this hostname.
 hostnames:
 - www.example.com
 rules:
 - matches:
 - path:
 type: PathPrefix
 value: /metrics
 filters:
 - type: ExtensionRef
 extensionRef:
 group: gateway.k8s.aws
 kind: ListenerRuleConfiguration
 name: deny-metrics
 - matches:
 - path:
 type: PathPrefix
 value: /
 # Target service name
 backendRefs:
 - name: my-web
 port: 80

ListenerRuleConfiguration

The following rule is attached to /metrics and returns a fixed 403 response.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: gateway.k8s.aws/v1beta1
kind: ListenerRuleConfiguration
metadata:
 name: deny-metrics
 namespace: my-web
spec:
 actions:
 - type: "fixed-response"
 fixedResponseConfig:
 statusCode: 403
 contentType: "text/plain"
 messageBody: "Forbidden for public access"

TargetGroupConfiguration

The ELB needs health checks for the target group.
So you need to define a health check endpoint.
Also, just as Ingress uses annotations to choose between IP and Instance targets, here you define that with targetType.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


apiVersion: gateway.k8s.aws/v1beta1
kind: TargetGroupConfiguration
metadata:
 name: my-web
 namespace: my-web
spec:
 targetReference:
 group: ""
 kind: Service
 name: my-web
 defaultConfiguration:
 # Route directly to pod IPs
 targetType: ip
 healthCheckConfig:
 healthCheckPath: /helathz/
 healthCheckProtocol: http
 matcher:
 httpCode: 200-399

🌐 Result Example

Below is an example resource map created by the Load Balancer Controller after applying the configuration.

The reason there were no healthy pods in the target group in the screenshot is that I had removed all worker nodes at that time.
When healthy targets do exist, you can see the pod IPs inside each target group.
For convenience during the project, I had also exposed Grafana and ArgoCD publicly.

You can also see that Route53 records were created.

The S3 access logs are also being stored correctly.

References

CKA Review: Preparation Strategy, Exam Experience, and Takeaways (2026 Ver)

Sun, 19 Apr 2026 09:30:00 +0900

작년 말에 프로그래머스에서 얼리버드 할인으로 약 27~8만원에 바우처를 구매했는데, 올해 내로 모두 응시할 계획이고, 우선 CKA를 먼저 준비했다.

ℹ️ Exam Information

CKA(Certified Kubernetes Administrator)

Provider: Linux Foundation
Exam format and scope: A performance-based exam focused on solving problems while working with Kubernetes
- Storage: 10%
- Troubleshooting: 30%
- Workloads & Scheduling: 15%
- Cluster Architecture, Installation & Configuration: 25%
- Services & Networking: 20%
Exam duration: 120 minutes
Kubernetes version: v1.35 (as of April 18, 2026; The exam version is usually updated 1-2 months after a new minor version is released)
Cost: $445
- After purchase, you can schedule the exam within one year
- One retake is included
- It is recommended not to but at full price and instread look for discounts through coupons
Exam environment: Online, using the PSI Secure Browser, with SSH access for each question on an Xfce-based Linux host
- Room and camera requirements:
  - You must take the exam alone in the room
  - No one, including children, adults, or animals, may enter
  - The environment must be quiet and free of disturbances
  - You may not cover your mouth during the exam
  - There must be no printed materials posted on the walls
  - Framed pictures and similar items are allowed
  - If a whiteboard is mounted on the wall, it must be completely blank
  - There must be nothing under the desk
  - Other than the computer required for the exam, all other items must be removed and kept out of reach during the exam
  - Earphones are not allowed
  - You may not wear anything on your wrists
  - Water is allowed only if it is in a transparent, unlabeled bottle
- Exam equipment requirements:
  - Supported operating systems: latest Windows 10 or 11 / macOS / Linux (Ubuntu only)
  - No other processes may be running besides the PSI browser (such as web browsers, note-taking apps, etc.)
  - A microphone and webcam must be available
  - A stable network connection is recommended
  - A personal PC or laptop is recommended rather than a company-issued device
  - A network without restrictions such as firewalls is recommended
  - A monitor of at least 15 inches is recommended
  - Additional monitors are not allowed
- There may be additional restrictions (for detauls, refer to the Linux Foundtation)
Identification:
- The ID must include a photo
- The English name on the ID must match the name used for exam registration
- Passport, international driver’s license, etc.

📖 Exam preparation

My total preparation period was three weeks. I think I spent about 1–2 hours per day on average.
For lectures, I used Udemy - Certified Kubernetes Administrator (CKA) with Practice Tests, and I also solved the KodeKloud practice problems provided alongside the course immediately after finishing each section.
Overall, I was satisfied with the course. The explanations were clear and beginner-friendly, and since it is usually difficult to recreate these environments on your own, it was very convenient to have problem scenarios provided right away for practice.
Also, the course did not only cover topics important for the CKA exam itself, but also explained related background knowledge. That made it a good review for topics I already knew, while helping me easily learn concepts I was unfamiliar with.

Two days before the exam, I worked through the Lightning Labs and Mock Exams provided on KodeKloud in connection with the course.
And the day before the exam, I completed the two mock exams on Killer.sh that were included when I registered for the test.

On the day of the exam, I reread the notes I had made from the questions I had gotten wrong while walking in the morning.

✏️ During the exam

Because the exam conditions are quite strict, I felt it would be realistically difficult to take it at home.
So, like many others in online reviews, I reserved a private room at a study café in advance and took the exam there.
I booked the room from 09:00 to 12:00 and scheduled the exam for 09:30 to 11:30, which turned out to be just right.

You can enter the exam environment 30 minutes before the start time, so if you go in early, you can complete the room check in advance and begin the exam right away.
Once the environment check started, they first verified my ID. In some other reviews, people said that if your photo had already been submitted during exam registration, they skipped the ID check, but in my case they checked it again.
After that, I had to show my surroundings, and I carefully used my laptop webcam to show even the area under the desk.
I also heard that by connecting through a QR code, you can briefly use your smartphone to help show the exam environment.
Finally, I showed myself putting my smartphone away, then showed my wrists and ears by turning them toward the camera, and then the exam began.
When I asked whether a laptop stand and a wireless mouse were allowed, I was told that both were permitted.

After that, I worked through the questions.
The difficulty level was a little harder than KodeKloud, but easier than Killer.sh.
People usually say that if you can pass Killer.sh, you are in a fairly safe range for the real exam.
From what I have seen in the community, quite a few people still pass the actual exam even if they fail Killer.sh.

You can move freely between questions, and if you place a flag on a question, it gets marked in the list so it is easier to review later.
At the top of each question, the system suggests relevant documentation links, and the SSH information you need to connect can be copied and pasted directly.
The body of each question is divided into a context section explaining the scenario and a task section describing what you need to do.
Some questions also include a test command to verify your work, though passing that check does not necessarily mean your answer is fully correct. For example, there could still be a namespace mismatch.

VSCodium is available, although you cannot install plugins.
I personally just used the terminal and Vim, but if you prefer a VS Code–style environment, it seems like a good option.

🚀 Result

24 hours later, the result came out!
I rememvered that I had used the wrong namespace on the exam, so I expected to lose a significant number of points because of it.
Still, since I had already scored above the passing mark on Killer.sh, I was not too worried about whether I would pass. I ended up with a score of 76%, which honestly did not quite meet my own expectations.
That said, what matters most is that I passed, so I decided to put my disappointment behind me.
(And anyway, I have to take it again in two years 😂)

The certificate can be downloaded as a PDF.
You can also claim an Open Badge on Credly.

🍕 Latest informations (April 2026) and tips

If you look at older reviews, many recommend setting up aliases and shell autocompletion yourself, but that is no longer necessary.
From the base host, you move into a different environment for each question via SSH, and alias k=“kubectl” as well as autocompletion are already configured.
Overly customized aliases are not very meaningful, since the environment changes from question to question. For example, something like kgpoy = kubectl get pod -o yaml is hardly useful.
It is best to just use the default setup as provided.

The following are relatively newer topics, so they are quite likely to appear on the exam:

Kustomize
Helm
Gateway API
CustomResourceDefinition (CRD)

There are also several other useful tips for the exam:

It is good to work imperatively when possible and make active use of --dry-run=client -o yaml.
Even when practicing in the KodeKloud environment, try not to rely on lecture materials, notes, or personal memos. Instead, practice using the official documentation just as you would in the real exam.
Since the exam is meant to test your Kubernetes knowledge, other details are usually explained kindly for you.
- For example, it may tell you how an nginx configuration should be modified, or what command should be used inside a sidecar container.
Still, the more commands you know, the better. For example:
- k get no <nodename> -o yaml | grep -A10 "taints": print the 10 lines after the taints section of a node
- journalctl -u kubelet: check kubelet logs
- openssl x509 -noout -text -in <cert-file>: inspect certificate information
- kubeadm token create --print-join-command: create a join token and print the worker node join command
It can also be helpful to become familiar with crictl, yq, and kubectl features such as jsonpath and custom headers.
Read each question carefully and avoid confusion over namespaces. Even a small phrase can be a subtask or an important condition.
Make full use of copy and paste. Copying resource names and similar values can help reduce typos.
- In the browser, use Ctrl + C / Ctrl + V, and in the terminal, use Ctrl + Shift + C / Ctrl + Shift + V.

🛏️ Conclusion

Although I earned the CKA, it is important to remember that this does not mean I have mastered Kubernetes.
I still have a lot of shortcomings, and there is still much more for me to learn.
At most, I have learned how to juggle the ball and dribble on the training ground; what really matters is performing well in an actual match.

Still, it is true that preparing for the exam helped me learn much more about Kubernetes, and significantly improved my fundamental hands-on ability to work with clusters.
I also still have vouchers for CKAD and CKS, so I am planning to take those later this year.

Building Amazon EKS with Custom Terraform Modules

Tue, 14 Apr 2026 23:43:27 +0900

🌯 Introduction

I had used Amazon EKS during the K-DT(Digital Training) program last summer, but I was not responsible for building or operating the cluster myself.
In my current project, I had full ownership of the AWS infrastructure, so I needed to design and provision the EKS cluster on my own.

At First, I considered using terraform-aws-modules/eks/aws module.
However, it felt too abstract for my use case, and the large number of input variables made it harder for me to understnad what was actually being created.
Instead of relying on a highly abstracted module, I decided to build the EKS cluster using my own smaller Terraform modules.
This approach helped me to understand each component more clearly and gave me more control over the infrastructure design.

The diagram below shows the dependencies of modules.

❓ What is Amazon EKS?

Amazon EKS(Elastic Kubernetes Service) is AWS’s managed Kubernetes service.
It allows you to run Kubernetes on AWS without having to manage the control plane yourself.

When running on Kubernetes in a public cloud environment, using a managed service is usually a better choice than building and operating a cluster directly on virtual machines.
A managed service reduces operational burden and provies tighter integration with the cloud platform.

Some of the main benefits are:

managed control plane operations
easier node scaling and lifecycle management
built-in networking integration with VPC, Load Balancer, and CNI
integration with AWS services such as IAM, CloudWatch, and EBS

EKS Standard vs Auto Mode

Amazon EKS has two main approaches:

EKS Standard
- AWS manages the control plane
- You manage more of the cluster components yourself
  - node groups, addons, and others
EKS Auto Mode
- AWS manages more of the operational details automatically
- it comes with additional fees

This post focuses on EKS Standard because I wanted to avoid the extra cost of Auto Mode and keep the infrastructure design explicit.
Since this project was also a learning opportunity, managing the building block myself helped me understand EKS more deeply.

🧀 EKS Cluster

This module creates the core EKS control plane.
It is responsible for provisioning the cluster itself, the IAM role used by EKS, and the network configuration for the cluster API endpoint.
I designed it to keep the cluster behavior explicit, especially around private access, control plane logging, and Auto Mode settings.

`main.tf`

The main part is aws_eks_cluster resource, which defines the EKS control plane.

One design choice here is support for private mode.
When enabled, the Kubernetes API endpoint is exposed privately instead of publicly.
In that case, I also create a dedicated security group and allow HTTPS access(Kubernetes API) from within the VPC so that internal resources, such as a bastion host, can reach the cluster API safely.

In access_config, I set authentication_mode = "API" so that cluster access can be managed through EKS access entries, instead of the legacy aws-auth ConfigMap.

The module also creates an IAM role for the EKS control plane and attaches the required AWS-managed policy.
This role allows EKS to interact with other AWS services as part of cluster operation.

By default, EKS cluster encrypts secrets at rest.
If you want to make secrets to be encrypted with CMK(Customer Managed Key) , you can use encryption_config block.
Visit here for more informations.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78


resource "aws_security_group" "eks_control_plane_access" {
 count = var.private_mode ? 1 : 0

 name = "${var.cluster_name}-eks-control-plane-access"
 description = "Allow bastion to reach EKS private API"
 vpc_id = var.vpc_id
}

resource "aws_vpc_security_group_ingress_rule" "eks_api_from_vpc" {
 count = var.private_mode ? 1 : 0

 security_group_id = aws_security_group.eks_control_plane_access[0].id
 cidr_ipv4 = var.vpc_cidr
 ip_protocol = "tcp"
 from_port = 443
 to_port = 443
}
resource "aws_eks_cluster" "eks" {
 name = var.cluster_name

 access_config {
 authentication_mode = "API"
 }

 role_arn = aws_iam_role.eks.arn
 version = var.kubernetes_version
 bootstrap_self_managed_addons = var.bootstrap_self_managed_addons
 enabled_cluster_log_types = var.enabled_cluster_log_types

 vpc_config {
 subnet_ids = var.subnet_ids
 endpoint_public_access = !var.private_mode
 endpoint_private_access = var.private_mode

 security_group_ids = aws_security_group.eks_control_plane_access[*].id
 }

 # Disable Auto-Mode
 compute_config {
 enabled = false
 }

 control_plane_scaling_config {
 tier = var.cp_scaling_tier
 }

 upgrade_policy {
 support_type = "STANDARD"
 }

 depends_on = [aws_iam_role_policy_attachment.cluster_AmazonEKSClusterPolicy]

}

# IAM Role for Contorl Plane
resource "aws_iam_role" "eks" {
 name = "${var.cluster_name}-role"
 assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
 {
 Action = [
 "sts:AssumeRole",
 "sts:TagSession"
 ]
 Effect = "Allow"
 Principal = {
 Service = "eks.amazonaws.com"
 }
 },
 ]
 })
}

resource "aws_iam_role_policy_attachment" "cluster_AmazonEKSClusterPolicy" {
 policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
 role = aws_iam_role.eks.name
}

`variables.tf`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53


variable "cluster_name" {
 description = "EKS cluster name"
 type = string
}

variable "kubernetes_version" {
 description = "EKS version"
 type = string
}

variable "bootstrap_self_managed_addons" {
 description = "Wheter to Enable VPC CNI and kube-proxy"
 type = bool
 default = true
}

variable "vpc_id" {
 description = "VPC ID"
 type = string
}

variable "vpc_cidr" {
 description = "VPC CIDR Block"
 type = string
}

variable "subnet_ids" {
 description = "Subnet IDs"
 type = list(string)
}

variable "private_mode" {
 description = "Enable EKS private access"
 type = string
}

variable "cp_scaling_tier" {
 description = "Scaling tier for Control Plane"
 type = string
 default = "standard"
}

variable "enabled_cluster_log_types" {
 type = set(string)
 default = []
 validation {
 condition = alltrue([
 for t in var.enabled_cluster_log_types :
 contains(["api", "audit", "authenticator", "controllerManager", "scheduler"], t)
 ])
 error_message = "enabled_cluster_log_types must contain only valid EKS control plane log types."
 }
}

`outputs.tf`

By default, Cluster security group is created by default.
For more informations, see here .

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


output "cluster_name" {
 value = aws_eks_cluster.eks.name
}

output "endpoint" {
 value = aws_eks_cluster.eks.endpoint
}

output "ca_certificate" {
 value = aws_eks_cluster.eks.certificate_authority[0].data
}

output "arn" {
 value = aws_eks_cluster.eks.arn
}

output "cluster_security_group_id" {
 value = aws_eks_cluster.eks.vpc_config[0].cluster_security_group_id
}

🔑 Access Entries

Since this cluster uses authentication_mode = "API", cluster access is managed through EKS access entries instead of the legacy aws-auth ConfigMap.

The difference is where access is managed. With aws-auth, IAM-to-Kubernetes mappings are stored inside the cluster as a Kubernetes ConfigMap.
With access entries, the same kind of access management is defined through AWS-managed EKS resources.
Newer model is preferred because it fits IaC-based infrastructure management much better and keeps cluster access configuration aligned with the AWS control plane.

Granting access through assumed IAM roles rather than IAM users is also recommended.
In practice, this means an engineer first assumes a role and then uses that role to access the cluster.
This is a better fit for operational environments because roles provide temporary credentials, while IAM users are usually tied to long-lived credentials.
From both a security and management perspective, using roles is the more natural approach.
For an IAM user to assume an IAM role, the user needs permission to call sts:AssumeRole on the role, and the role’s trust policy must allow that user.

Another important point is that EKS access scope in access policy association do not replace Kubernetes RBAC.
Access scope is just a simple access-control scope which is managed by AWS, while Kubernetes RBAC still works in cluster itself.
These two layers can work together.
In this module, I can optionally assign kubernetes_groups to the principal so that the access entry can integrate with native Kubernetes RBAC when more fine-grained authorization is needed.
For more information, visit here

This module is built around two main resources:

aws_eks_access_entry, which registers an IAM principal with the cluster
aws_eks_access_policy_association, which attaches one or more EKS access policies to that principal

`main.tf`

The aws_eks_access_entry resource creates the access entry for a single IAM principal.
After that, aws_eks_access_policy_association resources are created from a map variable, which makes it possible to attach multiple policies to the same principal. \

Each policy association also defines its access scope.
Depending on the configuration, access can be granted either at the cluster level or only for specific namespaces. \

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


resource "aws_eks_access_entry" "access" {
 cluster_name = var.cluster_name
 principal_arn = var.principal_arn
 kubernetes_groups = var.kubernetes_groups
}

resource "aws_eks_access_policy_association" "access" {
 for_each = var.eks_access_policy_association

 cluster_name = var.cluster_name
 principal_arn = var.principal_arn
 policy_arn = each.value.policy_arn

 access_scope {
 type = each.value.access_scope_type
 namespaces = each.value.namespaces
 }
}

`variables.tf`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


variable "cluster_name" {
 description = "EKS cluster name"
 type = string
}

variable "principal_arn" {
 description = "IAM role ARN registering access policy"
 type = string
}

variable "kubernetes_groups" {
 description = "List of Kubernetes groups to assign to the principal"
 type = list(string)
 default = []
}

variable "eks_access_policy_association" {
 type = map(object({
 policy_arn = string
 access_scope_type = string
 namespaces = optional(list(string))
 }))
 default = {}
 validation {
 condition = alltrue([
 for t in var.eks_access_policy_association :
 contains(["namespace", "cluster"], t.access_scope_type)
 ])
 error_message = "eks_access_policy_association must contain only 'namespace' or 'cluster'"
 }
}

👪 Node Groups

EKS managed node groups automate the provisioning and lifecycle management of worker nodes.

This module has more input variables than some of the earlier modules because node groups tend to vary a lot depending on workload requirements.
Instance type, capacity model, scaling limits, labels, taints, and disk size can all change depending on how the cluster is intended to be used.

Worker nodes also need a role with the required AWS permissoins.
At minimum, the nodes need policies such as AmazonEKSWorkerNodePolicy and AmazonEC2ContainerRegistryPullOnly so that they can join the cluster and pull container images from Amazon ECR.

`main.tf`

The core resource in this module is aws_eks_node_group, which craetes a managed node group attached to the cluster.

I exposed Kubernetes-specific scheduling options through labels and taints.
These settings are important when different workloads need to be separated across different groups of nodes.
For example, some nodes may be dedicated to system workloads, while others may be reserved for specific applications or cost-optimized Spot workloads.

Another detail is the lifecycle block ignoring changes to desired_size.
I added this because the desired number of nodes may change dynamically during operation, and I did not want Terraform to constantly treat that runtime scaling state as drift.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56


resource "aws_eks_node_group" "ng" {
 cluster_name = var.cluster_name
 node_group_name = var.node_group_name
 node_role_arn = aws_iam_role.ng.arn

 ami_type = var.ami_type
 instance_types = var.instance_types
 subnet_ids = var.subnet_ids
 capacity_type = var.capacity_type
 disk_size = var.disk_size

 scaling_config {
 desired_size = var.scaling.desired_size
 min_size = var.scaling.min_size
 max_size = var.scaling.max_size
 }

 labels = var.labels

 dynamic "taint" {
 for_each = var.taints
 content {
 key = taint.value.key
 value = taint.value.value
 effect = taint.value.effect
 }
 }

 lifecycle {
 ignore_changes = [scaling_config[0].desired_size]
 }

 depends_on = [aws_iam_role_policy_attachment.ng_attachment]
}

resource "aws_iam_role" "ng" {
 name = "${var.node_group_name}-role"

 assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
 Action = "sts:AssumeRole"
 Effect = "Allow"
 Principal = {
 Service = "ec2.amazonaws.com"
 }
 }]
 })
}

resource "aws_iam_role_policy_attachment" "ng_attachment" {
 for_each = var.role_policy_attachment

 policy_arn = each.value
 role = aws_iam_role.ng.name
}

`variables.tf`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91


variable "cluster_name" {
 description = "Name of EKS Cluster"
 type = string
}

variable "node_group_name" {
 description = "Name of node group"
 type = string
}

variable "subnet_ids" {
 description = "ID list of subnet"
 type = list(string)
}

variable "ami_type" {
 description = "Type of AMI"
 type = string
 validation {
 condition = contains([
 "AL2_x86_64", "AL2_x86_64_GPU", "AL2_ARM_64", "CUSTOM",
 "BOTTLEROCKET_ARM_64", "BOTTLEROCKET_x86_64",
 "BOTTLEROCKET_ARM_64_FIPS", "BOTTLEROCKET_x86_64_FIPS",
 "BOTTLEROCKET_ARM_64_NVIDIA", "BOTTLEROCKET_x86_64_NVIDIA",
 "BOTTLEROCKET_ARM_64_NVIDIA_FIPS", "BOTTLEROCKET_x86_64_NVIDIA_FIPS",
 "WINDOWS_CORE_2019_x86_64", "WINDOWS_FULL_2019_x86_64",
 "WINDOWS_CORE_2022_x86_64", "WINDOWS_FULL_2022_x86_64",
 "WINDOWS_CORE_2025_x86_64", "WINDOWS_FULL_2025_x86_64",
 "AL2023_x86_64_STANDARD", "AL2023_ARM_64_STANDARD",
 "AL2023_x86_64_NEURON", "AL2023_x86_64_NVIDIA", "AL2023_ARM_64_NVIDIA"
 ], var.ami_type)
 error_message = "amiType does not match. check: https://docs.aws.amazon.com/eks/latest/APIReference/API_Nodegroup.html#AmazonEKS-Type-Nodegroup-amiType"
 }
}

variable "instance_types" {
 description = "List of instance type"
 type = list(string)
}

variable "capacity_type" {
 description = "Node Capacity Type"
 type = string
 validation {
 condition = contains(["ON_DEMAND", "SPOT"], var.capacity_type)
 error_message = "Valid value: <ON_DEMAND | SPOT>"
 }
}

variable "disk_size" {
 description = "Disk size for each worker node"
 type = number
 default = 20
}

variable "scaling" {
 description = "Scaling Capacity"
 type = object({
 desired_size = number
 min_size = number
 max_size = number
 })
}

variable "labels" {
 description = "Node labels"
 type = map(string)
}

variable "taints" {
 description = "Taints for rule"
 type = map(object({
 key = string
 value = optional(string)
 effect = string
 }))

 validation {
 condition = alltrue([
 for _, v in var.taints :
 contains(["NO_SCHEDULE", "NO_EXECUTE", "PREFER_NO_SCHEDULE"], v.effect)
 ])
 error_message = "Valid effect: <NO_SCHEDULE | NO_EXECUTE | PREFER_NO_SCHEDULE>"
 }
}

variable "role_policy_attachment" {
 description = "Role policies to attach nodes"
 type = set(string)
 default = []
}

📲 Addons

Compared to the other parts of this EKS setup, add-ons are relatively simple.
In Terraform, an EKS add-on can be created with a single aws_eks_addon resource, so this is one of the few cases where creating a separate module is optional.

I still separated it into its own module for consistency. \ Since the rest of the cluster is also organized into small building blocks, keeping add-ons in a dedicated module made the overall structure easier to understand and extend later.

`main.tf`

1
2
3
4


resource "aws_eks_addon" "addon" {
 cluster_name = var.cluster_name
 addon_name = var.addon_name
}

`variables.tf`

1
2
3
4
5
6
7
8
9


variable "cluster_name" {
 description = "Name of EKS Cluster"
 type = string
}

variable "addon_name" {
 description = "Name of Addon"
 type = string
}

⛓️ Pod Identity Associations

EKS Pod Identity allows pods to access AWS services using IAM roles, without storing AWS credentials inside containers.
The idea is similar to how an EC2 instance profile provides credentials to an EC2 instance, but in this case the identity is assigned to a Kuberentes workload.

Instead of distributing static AWS credentials to applications or reusing the worker node’s IAM role, I associate a dedicated IAM role with a Kubernetes service account.
Pods that use that service account can then access AWS resources with only the permessions they actually need.

This is useful because it keeps AWS permission scoped at the workload level rather than the node level.
In other words, different applications in the same cluster can use different IAM roles depending on their responsiblities.

`main.tf`

First, this module creates IAM role that can be assumed by EKS pods.
Then it attaches the IAM policy that defines what the workload is allowed to do in AWS.
Finally, it creates the pod identity association that connects the IAM role to a specific Kubernetes service account in a specific namespace.
Pod identity agent is deployed by daemonset, providing pods to get its credentials from IAM role.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


resource "aws_iam_role" "pod" {
 name = var.role_name

 assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
 {
 Effect = "Allow"
 Principal = {
 Service = "pods.eks.amazonaws.com"
 }
 Action = [
 "sts:AssumeRole",
 "sts:TagSession"
 ]
 }
 ]
 })
}

resource "aws_iam_role_policy_attachment" "pod" {
 role = aws_iam_role.pod.name
 policy_arn = var.policy_arn
}

resource "aws_eks_pod_identity_association" "association" {
 cluster_name = var.cluster_name
 namespace = var.namespace
 service_account = var.service_account
 role_arn = aws_iam_role.pod.arn
}

`variables.tf`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


variable "cluster_name" {
 description = "Name of EKS Cluster"
 type = string
}

variable "role_name" {
 description = "IAM role name to assign pod"
 type = string
}

variable "policy_arn" {
 description = "IAM policy arn"
 type = string
}

variable "namespace" {
 description = "Kubernetes namespace"
 type = string
}

variable "service_account" {
 description = "Name of serviceAccount"
 type = string
}

🚪 (Optional) Bastion Host

When the EKS cluster runs in private API mode, the Kubernetes API endpoint is not exposed to the public internet.
That means cluster administration has to be performed from somewhere inside the VPC or from a connected network.

A bastion host is one way to solve that problem, but it is not the only option.
Other approaches, such as Client VPC or Site-to-Site VPN, can also provide private connectivity to the cluster.
In this project, however, I chose a bastino host combined with AWS Systems Manager Session Manager.
Because VPN services are too expensive and increase operational overheads.

`main.tf`

This module creates a small EC2 instance that acts as an administrative entry point into the private network.
The instance itself is intentionally simple: it uses a minimal security group, an IAM instance profile for Systems Manager access, and a small amount of bootstrap configuration through user_data.

One design choice I like here is avoiding traditional SSH-based bastion access.
Instead of opening inbound SSH, the instance is managed through SSM Session Manager.
This keeps inbound access closed while still allowing interactive administration when needed.
In practice, that reduces operational overhead compared to managing SSH keys and security group ingress rules.

I also attached a small custom IAM policy that allows the bastion to call eks:DescribeCluster.
This is useful because tools such as aws eks update-kubeconfig rely on EKS cluster metadata in order to build client configuration for kubectl.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114


data "aws_ami" "ubuntu" {
 most_recent = true

 filter {
 name = "name"
 values = ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-arm64-server-*"]
 }

 filter {
 name = "virtualization-type"
 values = ["hvm"]
 }

 owners = ["099720109477"] # Canonical
}

resource "aws_security_group" "bastion" {
 name = "bastion_ssm"
 description = "Deny inbound traffic and allow outbound traffic"
 vpc_id = var.vpc_id
}

resource "aws_vpc_security_group_egress_rule" "bastion_internet" {
 security_group_id = aws_security_group.bastion.id

 cidr_ipv4 = "0.0.0.0/0"
 from_port = 443
 ip_protocol = "tcp"
 to_port = 443
}

resource "aws_iam_instance_profile" "ssm" {
 name = "${var.name}-profile"
 role = aws_iam_role.bastion.id
}

resource "aws_instance" "bastion" {
 ami = data.aws_ami.ubuntu.id
 instance_type = var.instance_type

 subnet_id = var.subnet_id
 vpc_security_group_ids = [aws_security_group.bastion.id]
 associate_public_ip_address = var.associate_public_ip_address

 iam_instance_profile = aws_iam_instance_profile.ssm.name

 metadata_options {
 http_tokens = "required"
 }

 root_block_device {
 encrypted = true
 volume_type = "gp3"
 }

 user_data = file("${path.module}/user_data.sh")
 user_data_replace_on_change = true

 tags = {
 Name = var.name
 }
}

resource "aws_iam_role" "bastion" {
 name = var.name
 path = "/"
 assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
 {
 Sid = "AllowEC2SSM"
 Effect = "Allow"
 Action = [
 "sts:AssumeRole"
 ]
 Principal = {
 Service = "ec2.amazonaws.com"
 }
 }
 ]
 })

 tags = {
 Purpose = "Bastion"
 }
}

resource "aws_iam_role_policy_attachment" "bastion_ssm" {
 role = aws_iam_role.bastion.name
 policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

data "aws_iam_policy_document" "bastion_access_eks" {
 statement {
 sid = "AllowEKStoBastion"
 actions = [
 "eks:DescribeCluster"
 ]
 resources = [
 var.eks_arn
 ]
 }
}

resource "aws_iam_policy" "bastion_access_eks" {
 name = "${var.name}-access-eks"
 path = "/"
 policy = data.aws_iam_policy_document.bastion_access_eks.json
}

resource "aws_iam_role_policy_attachment" "bastion_access_eks" {
 role = aws_iam_role.bastion.name
 policy_arn = aws_iam_policy.bastion_access_eks.arn
}

`user_data.sh`

It installs useful infra tools, and adds small shell configurations.
This script makes the bastion host to prepared workstation inside the VPC.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


#!/usr/bin/env bash
set -euo pipefail

export DEBIAN_FRONTEND=noninteractive

apt-get update
apt-get upgrade -y

apt-get install -y apt-transport-https ca-certificates curl gnupg unzip

# kubectl
mkdir -p /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key |
 gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /' \
 >/etc/apt/sources.list.d/kubernetes.list
apt-get update
apt-get install -y kubectl

# OpenTofu
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://get.opentofu.org/opentofu.gpg | tee /etc/apt/keyrings/opentofu.gpg >/dev/null
curl -fsSL https://packages.opentofu.org/opentofu/tofu/gpgkey | gpg --dearmor -o /etc/apt/keyrings/opentofu-repo.gpg
chmod a+r /etc/apt/keyrings/opentofu.gpg /etc/apt/keyrings/opentofu-repo.gpg

cat >/etc/apt/sources.list.d/opentofu.list <<'EOF'
deb [signed-by=/etc/apt/keyrings/opentofu.gpg,/etc/apt/keyrings/opentofu-repo.gpg] https://packages.opentofu.org/opentofu/tofu/any/ any main
deb-src [signed-by=/etc/apt/keyrings/opentofu.gpg,/etc/apt/keyrings/opentofu-repo.gpg] https://packages.opentofu.org/opentofu/tofu/any/ any main
EOF

apt-get update
apt-get install -y tofu

ARCH="$(uname -m)"

case "$ARCH" in
x86_64)
 AWSCLI_URL="https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip"
 ;;
aarch64 | arm64)
 AWSCLI_URL="https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip"
 ;;
*)
 echo "Unsupported architecture: $ARCH"
 exit 1
 ;;
esac

curl -fsSL "$AWSCLI_URL" -o "awscliv2.zip"
unzip -o awscliv2.zip
./aws/install

# SSM Agent
snap install amazon-ssm-agent --classic || true
systemctl enable snap.amazon-ssm-agent.amazon-ssm-agent.service || true
systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent.service || true

# Shell
curl -fsSL https://starship.rs/install.sh | sh -s -- -y

cat <<'EOF' >>/home/ubuntu/.bashrc
eval "$(starship init bash)"
alias k='kubectl'
EOF

chown ubuntu:ubuntu /home/ubuntu/.bashrc

`variables.tf`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


variable "name" {
 description = "Name of the instance"
 type = string
}

variable "vpc_id" {
 description = "VPC ID"
 type = string
}

variable "subnet_id" {
 description = "Subnet ID"
 type = string
}

variable "instance_type" {
 description = "EC2 Instance Type"
 type = string
 default = "t4g.nano"
}

variable "eks_arn" {
 description = "EKS Arn"
 type = string
}

variable "associate_public_ip_address" {
 description = "Associate public IP address"
 type = bool
}

`outputs.tf`

1
2
3
4
5
6
7


output "bastion_id" {
 value = aws_instance.bastion.id
}

output "bastion_role_arn" {
 value = aws_iam_role.bastion.arn
}

🚀 Using Modules

This is the example of using modules.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167


##########
# locals #
##########
locals {
 vpc_cidr = "10.0.0.0/16"

 # Enable/disable EKS private access
 eks_private_mode = true

 # EKS Addon list
 eks_addons = toset([
 "coredns",
 "kube-proxy",
 "vpc-cni",
 "aws-ebs-csi-driver",
 "eks-pod-identity-agent",
 ])

 # Pod identity associations
 pod_identity_associations = {
 vpc_cni = {
 role_name = "${var.cluster_name}-vpc-cni"
 policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
 namespace = "kube-system"
 service_account = "aws-node"
 }
 ebs_csi = {
 role_name = "${var.cluster_name}-ebs-sci"
 policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy"
 namespace = "kube-system"
 service_account = "ebs-csi-controller-sa"
 }
 }
}

########################################################
# EKS - Cluster #
# #
# NOTE: #
# By default, EKS secrets are protected with enveloped #
# encryption in EKS version 1.28 or higher #
########################################################
module "eks_cluster" {
 source = "../../../modules/eks-cluster"

 cluster_name = var.cluster_name
 kubernetes_version = "1.35"
 vpc_id = module.vpc.vpc_id
 vpc_cidr = local.vpc_cidr
 subnet_ids = module.vpc.private_subnet_ids
 private_mode = local.eks_private_mode

 enabled_cluster_log_types = []
 cp_scaling_tier = "standard"
}

######################
# EKS - Access Entry #
######################
module "eks_access_entry_private" {
 count = local.eks_private_mode ? 1 : 0
 source = "../../../modules/eks-access-entry"

 # Use module output instead of var.cluter_name because of the dependency implication.
 cluster_name = module.eks_cluster.cluster_name
 principal_arn = module.bastion[0].bastion_role_arn

 eks_access_policy_association = {
 clusteradmin = {
 policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
 access_scope_type = "cluster"
 }
 }
}

module "eks_access_entry_public" {
 count = local.eks_private_mode ? 0 : 1
 source = "../../../modules/eks-access-entry"

 cluster_name = module.eks_cluster.cluster_name
 principal_arn = data.terraform_remote_state.shared.outputs.eks_fullaccess_role_arn

 eks_access_policy_association = {
 clusteradmin = {
 policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
 access_scope_type = "cluster"
 }
 }
}

#####################################
# EKS - Node Group #
# Desired Node group size is ignored #
# when comparing the state #
#####################################
module "eks_node_group" {
 source = "../../../modules/eks-node-group"

 cluster_name = module.eks_cluster.cluster_name
 node_group_name = "${var.cluster_name}-ng"

 ami_type = "AL2023_ARM_64_STANDARD"
 subnet_ids = module.vpc.private_subnet_ids
 instance_types = ["t4g.large"]

 capacity_type = "ON_DEMAND"
 disk_size = 20

 scaling = {
 desired_size = 2
 min_size = 2
 max_size = 4
 }

 labels = {
 NodeGroupName = "default"
 }

 taints = {}

 # Role policy Attachment
 role_policy_attachment = [
 "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy",
 "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly"
 ]
}

################
# EKS - Addons #
################
module "eks-addons" {
 source = "../../../modules/eks-addons"
 for_each = local.eks_addons

 cluster_name = module.eks_cluster.cluster_name
 addon_name = each.value
}


###################################
# EKS - Pod identity associations #
###################################
module "pod_identity_association" {
 source = "../../../modules/eks-pod-identity-association"
 for_each = local.pod_identity_associations

 cluster_name = module.eks_cluster.cluster_name
 role_name = each.value.role_name
 policy_arn = each.value.policy_arn
 namespace = each.value.namespace
 service_account = each.value.service_account
}

################
# Bastion Host #
################
module "bastion" {
 count = local.eks_private_mode ? 1 : 0
 source = "../../../modules/ec2-ssm-bastion"

 name = "bastion-prod"
 vpc_id = module.vpc.vpc_id
 subnet_id = module.vpc.private_subnet_ids[0]
 instance_type = "t4g.nano"
 eks_arn = module.eks_cluster.arn
 associate_public_ip_address = false
}

🪪 Accessing EKS Cluster

If the EKS cluster exposes a public API endpoint, you can access it directly from your local environment by updating your kubeconfig.

1
2


# Add --role-arn <role-arn> if you need to assume a role
aws eks update-kubeconfig --region <region> --name <cluster-name>

If the cluster runs in private mode, you need to access it from inside the VPC or through a connected private network first.
In my setup, that means starting a session on the bastion host through AWS Systems Manager Session Manager.

1

aws ssm start-session --target <instance-id>

From there, you can run aws eks update-kubeconfig and use kubectl against the private cluster endpoint.

➡️ What Comes Next

Provisioning the EKS cluster itself is only the beginning.
In the standard EKS model, there are still several operational components that often need to be installed separately depending on the environment and workload requirements.

Some common examples are:

ArgoCD for GitOps-based deployment
cert-manager for TLS certificate management
AWS Load Balancer Controller for integrating Kubernetes services with AWS load balancers
Karpenter for node autoscaling
Gateway API CRD for newer north-south traffic control management
Observability Stack
and so on

You can also consider AWS EKS Capabilities.

Kubernetes on Riveroverflow

Building an AWS ALB-Based Gateway API

⚙️ How It Works

For Ingress

Reconciliation Flow

Traffic Handling

For Gateway API

🚀 Installing AWS Load Balancer Controller

Installation with Helm

Other useful values

📝 Hands-on Example

Required components

Additional components

Route53 Hosted Zone, ACM Certificate, and External-DNS

WAFv2 regional ACL

S3 for access logging

GatewayClass

LoadBalancerConfiguration

Gateway

HTTPRoute

ListenerRuleConfiguration

TargetGroupConfiguration

🌐 Result Example

References

CKA Review: Preparation Strategy, Exam Experience, and Takeaways (2026 Ver)

ℹ️ Exam Information

📖 Exam preparation

✏️ During the exam

🚀 Result

🍕 Latest informations (April 2026) and tips

🛏️ Conclusion

Building Amazon EKS with Custom Terraform Modules

🌯 Introduction

❓ What is Amazon EKS?

EKS Standard vs Auto Mode

🧀 EKS Cluster

main.tf

variables.tf

outputs.tf

🔑 Access Entries

main.tf

variables.tf

👪 Node Groups

main.tf

variables.tf

📲 Addons

main.tf

variables.tf

⛓️ Pod Identity Associations

main.tf

variables.tf

🚪 (Optional) Bastion Host

main.tf

user_data.sh

variables.tf

outputs.tf

🚀 Using Modules

🪪 Accessing EKS Cluster

➡️ What Comes Next

📚 References

`main.tf`

`variables.tf`

`outputs.tf`

`main.tf`

`variables.tf`

`main.tf`

`variables.tf`

`main.tf`

`variables.tf`

`main.tf`

`variables.tf`

`main.tf`

`user_data.sh`

`variables.tf`

`outputs.tf`