Deploy to Amazon EKS

Deploy a containerized app on Amazon EKS using managed nodes and Fargate.

Introduction

30 Second Summary

When your containerized applications need the full power of Kubernetes orchestration, AWS offers a managed service that handles the complex control plane for you. The trade-off? It costs $0.10/hr just to keep the control plane running, so you need to know exactly when it's the right choice.

In this project, you will create an Amazon EKS cluster, deploy a web application on both EC2 managed nodes and serverless Fargate pods, and build the exam-ready understanding of when to choose EKS over ECS.

What You'll Build

By the end, you'll open a public URL in your browser and see a live web app served by your EKS cluster, then run a single kubectl command that shows the same workload running on both EC2 nodes and Fargate micro-VMs side by side.

By the end of this project, you'll have:

A live EKS cluster you can interact with using kubectl commands directly from your browser via AWS CloudShell.
A public LoadBalancer URL serving your nginx web application, provisioned automatically by Kubernetes when you create a Service.
A Fargate profile running the same workload serverlessly in a separate namespace, so you can compare node-based and Fargate pod execution in your terminal output.
Secret Mission: Configure a Horizontal Pod Autoscaler to auto-scale your pods based on CPU utilization.

Are there any prerequisites?

You need an AWS account with admin access and prior experience with ECS and Fargate from Projects 1-2 in this series (IAM roles, VPC networking, container concepts). No local tools are required. All work happens in the AWS Console and CloudShell.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

You already know how to run containers on ECS. In this project, you'll deploy a containerized app on Amazon EKS using both Managed Node Groups and serverless Fargate pods. Understanding when to choose EKS over ECS is a key decision the SAA-C03 exam tests.

Create IAM Roles for EKS

EKS requires two separate IAM roles before you can create anything.

The cluster role lets the Kubernetes control plane call AWS APIs on your behalf. The node role lets EC2 worker nodes register with the cluster and pull container images. Without these roles, cluster creation fails immediately.

In this step, get ready to:

Create the EKS cluster IAM role.
Create the EKS node IAM role.
Understand the EKS IAM role model for the SAA-C03 exam.

Create the EKS cluster IAM role

The cluster role allows the EKS control plane to manage AWS resources like network interfaces, security groups, and load balancers on your behalf.

Navigate to the IAM console by searching for IAM in the AWS Console search bar and selecting it.
In the left navigation pane, choose Roles.
Choose Create role.
Under Trusted entity type, select AWS service.
From the Use cases for other AWS services dropdown list, choose EKS.
Choose EKS - Cluster for your use case.
Choose Next.
On the Add permissions page, AmazonEKSClusterPolicy is pre-selected. Choose Next.
For Role name, enter eksClusterRole.
Choose Create role.

What does this role do?

By selecting the EKS - Cluster use case, the IAM console automatically sets the trust policy to allow eks.amazonaws.com to assume this role.

The AmazonEKSClusterPolicy grants the control plane permission to manage ENIs, security groups, and load balancers. Without this role, the cluster cannot communicate with AWS services.

Create the EKS node IAM role

The node role is for EC2 instances in your node group. It lets nodes register with the cluster, manage pod networking, and pull container images.

In the IAM console, choose Roles in the left navigation pane.
Choose Create role.
Under Trusted entity type, select AWS service.
Under Use case, choose EC2.
Choose Next.
In the Filter policies box, enter AmazonEKSWorkerNodePolicy.
Select the check box to the left of AmazonEKSWorkerNodePolicy in the search results.
Choose Clear filters.

In the Filter policies box, enter AmazonEKS_CNI_Policy.
Select the check box to the left of AmazonEKS_CNI_Policy in the search results.
Choose Clear filters.
In the Filter policies box, enter AmazonEC2ContainerRegistryReadOnly.
Select the check box to the left of AmazonEC2ContainerRegistryReadOnly in the search results.
Choose Next.
For Role name, enter eksNodeRole.
Choose Create role.

What do these three policies do?

AmazonEKSWorkerNodePolicy lets nodes register with the cluster and describe EC2 resources in the VPC.

AmazonEKS_CNI_Policy lets the VPC CNI plugin manage elastic network interfaces for pod networking.

AmazonEC2ContainerRegistryReadOnly lets nodes pull container images from ECR.

Don't see your policies in the search results?

Make sure you choose Clear filters between each policy search. If you search for a second policy without clearing, the filter combines and returns no results.

help me find the right policies for my EKS node role

Understand the IAM role model

Before you move on, take a moment to understand the EKS IAM role model. The SAA-C03 exam tests all three role types.

What are the three EKS IAM roles?

Cluster role (what you just created as eksClusterRole): used by the control plane to manage AWS resources. Trust policy allows eks.amazonaws.com to assume it.
Node role (what you just created as eksNodeRole): used by EC2 worker nodes to register with the cluster and pull images. Trust policy allows ec2.amazonaws.com to assume it.
Pod execution role (created later for Fargate): used by the Fargate infrastructure to run pods. Trust policy allows eks-fargate-pods.amazonaws.com to assume it.

How does this compare to ECS?

ECS uses a similar separation-of-concerns pattern. The Task execution role pulls images and writes logs. The Task role gives the application its own AWS permissions.

EKS mirrors this with more roles because Kubernetes separates the control plane from node compute more explicitly.

Before you continue, what do you think you will see if you click on eksClusterRole in the Roles list? What policy should be attached?

In the IAM console, choose Roles in the left navigation pane.
Search for eksClusterRole and click the role name to open it.
Confirm you see AmazonEKSClusterPolicy listed under Permissions.
Navigate back to the Roles list, search for eksNodeRole, and click the role name.
Confirm you see all three policies: AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy, and AmazonEC2ContainerRegistryReadOnly.

You should see both roles with their correct policies attached. This confirms your IAM foundation is ready for cluster creation.

Your IAM roles are ready. Next up, you will create the EKS cluster itself and see how these roles connect to the managed control plane.

Create the EKS Cluster

Your IAM roles are in place, which means the permissions layer is ready. Now it is time to create the cluster itself.

The EKS cluster is the managed Kubernetes control plane. Unlike ECS where the control plane is free, EKS charges $0.10/hr (about $72/month) for the control plane alone. This cost difference is a major SAA-C03 exam differentiator, and understanding it starts here.

In this step, get ready to:

Create the EKS cluster from the AWS console.
Connect to the cluster via CloudShell and verify kubectl access.

Create the cluster via the EKS console

The cluster creation wizard walks you through several pages. Most settings stay at their defaults since this project uses the default VPC.

Open the Amazon EKS console at:
https://console.aws.amazon.com/eks/home#/clusters
Confirm the AWS Region in the upper-right corner matches the region you want to use.
Choose Create cluster.
On the Configure cluster page, select Custom configuration.
Disable Use EKS Auto Mode.
For Name, enter eks-demo-cluster.
For Cluster Service Role, choose eksClusterRole (the role you created in Step 1).
For Kubernetes version, select 1.36 (the latest available).
Leave the remaining settings at their defaults and choose Next.
On the Specify networking page, leave the defaults (default VPC, pre-selected subnets, public endpoint enabled) and choose Next.
On the Configure observability page, choose Next.
On the Select add-ons page, choose Next.
On the Configure selected add-ons settings page, choose Next.
On the Review and create page, choose Create.

The cluster status shows Creating for 10-15 minutes. Do not continue until the status changes to Active.

What is happening during those 10-15 minutes?

AWS is provisioning the managed control plane in an AWS-owned VPC you never see. This includes the API server, etcd database, and controller manager, all distributed across multiple Availability Zones for high availability.

The IAM principal that created the cluster automatically receives Kubernetes admin access. No other IAM users or roles can call the cluster's API server until you explicitly grant them access.

Understand EKS architecture and cost while waiting

Use the wait time to internalize the exam concepts that differentiate EKS from ECS.

How does EKS pricing compare to ECS?

EKS control plane costs $0.10 per hour per cluster (about $72/month). ECS control plane costs $0. This is the single biggest reason the SAA-C03 exam says: do not choose EKS unless Kubernetes is explicitly required.

If you run an older Kubernetes version past its 14-month standard support window, pricing jumps to $0.60 per hour. Always keep your cluster on a supported version.

When should I choose EKS over ECS?

Choose EKS when the team has existing Kubernetes expertise, needs multi-cloud portability (EKS Anywhere, EKS Distro), or requires Kubernetes ecosystem tools like Helm, Argo CD, Istio, or Prometheus.

Choose ECS when you want AWS-native simplicity, lower cost, have no Kubernetes expertise on the team, or are committed to a single-cloud strategy.

Connect to the cluster via CloudShell

Once the cluster status is Active, you can connect using CloudShell directly from the console. No local tools needed.

In the EKS console, click the cluster name eks-demo-cluster to open its details page.
Choose Connect from the top-right action bar.
AWS CloudShell opens with kubectl pre-configured for your cluster.

What is CloudShell doing here?

CloudShell sessions include kubectl, the AWS CLI, and standard utilities. When you choose Connect from the cluster page, it automatically configures a kubeconfig so kubectl can reach the API server. No manual setup required.

Before you run the next command, what do you think you will see if kubectl can successfully reach the cluster's API server?

Verify the connection by running:

kubectl get svc

You should see the kubernetes service listed on port 443/TCP. This confirms kubectl can reach the API server and your cluster is fully operational.

Not seeing the kubernetes service?

Make sure the cluster status is Active (not Creating) before choosing Connect. The API server endpoint is not available until the cluster finishes provisioning.

If you see an authorization error, confirm you are signed in with the same IAM principal that created the cluster. Only the cluster creator has automatic admin access.

Why can't kubectl reach my EKS cluster from CloudShell?

Your cluster is live and responding to kubectl commands. Next, you will add compute capacity with a Managed Node Group so pods have somewhere to run.

Add a Managed Node Group

Your EKS cluster is active, but it has zero compute capacity. If you tried to deploy a pod right now, it would sit in Pending forever because there are no nodes to schedule it on.

A Managed Node Group solves this by letting AWS handle the EC2 instances inside an Auto Scaling Group. AWS launches, patches, and terminates the nodes while you keep control over instance types and scaling limits.

In this step, get ready to:

Create a Managed Node Group with 2 t3.medium instances.
Verify the nodes register to the cluster and reach Ready status.
Understand all three EKS node options for the SAA-C03 exam.

Create the Managed Node Group

The node group tells EKS which EC2 instances to launch and how many to maintain. You configure the instance type, scaling boundaries, and IAM role.

In the EKS console, click the eks-demo-cluster cluster name to open its details page.
Select the Compute tab.
Click Add Node Group.
For Name, enter eks-demo-nodes.
For Node IAM role, choose eksNodeRole.
Click Next.

For Instance types, keep t3.medium selected.
Set Desired size to 2.
Set Minimum size to 2.
Set Maximum size to 3.
Click Next through the Networking page (accept the defaults).
Click Create.

Node group creation takes 3-5 minutes. Wait for the Status to show Active before continuing.

What is a Managed Node Group?

A Managed Node Group is an Auto Scaling Group of EC2 instances that AWS manages on your behalf. AWS handles node provisioning, AMI updates, and graceful draining during updates.

You control the instance type, scaling limits, and IAM role. The nodes automatically register with the EKS cluster and start accepting pod workloads.

Node group stuck in Creating?

If the node group stays in Creating for more than 10 minutes, check that eksNodeRole has all three required policies attached: AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy, and AmazonEC2ContainerRegistryReadOnly.

Also verify the default VPC has at least two subnets in different Availability Zones.

Still stuck? Why is my EKS node group not reaching Active status?

Verify nodes are registered

Once the node group is Active in the console, the EC2 instances should have registered themselves with the Kubernetes API server. Time to confirm that from the kubectl side.

Before you run this command, how many nodes do you expect to see, and what status should they be in?

Return to CloudShell and run this command to list all nodes:

kubectl get nodes

You should see 2 nodes with STATUS Ready. Both are t3.medium instances managed by your node group.

Pick one of the node names from the output and run this to inspect its details:

kubectl describe node <node-name>

What should I see?

In the describe output, look for the Labels section. You'll see labels that confirm this node belongs to your managed group:

eks.amazonaws.com/nodegroup=eks-demo-nodes confirms which node group this instance belongs to.
node.kubernetes.io/instance-type=t3.medium confirms the instance type.

Nodes not showing up?

If kubectl get nodes returns no resources, the node group may still be provisioning. Check its status in the EKS console under the Compute tab.

If nodes appear but show NotReady status, wait another minute. Nodes need time to pull system pods and complete their startup sequence.

Need more help? Why are my EKS nodes not reaching Ready status?

Understand EKS node options (exam concept)

The SAA-C03 exam tests your knowledge of all three ways to provide compute to an EKS cluster. You just used one of them. Here's the full picture.

What are the three EKS node options?

Managed Node Groups (what you just created): AWS manages EC2 instances in an ASG. Automatic AMI updates, draining, and replacement. This is the most common exam scenario.
Self-Managed Nodes: You manage your own EC2 instances and join them to the cluster manually. Full control but more operational burden. Used when you need custom AMIs or GPU instances not yet supported by managed groups.
Fargate Profiles: No nodes at all. AWS runs each pod on its own isolated micro-VM. You pay per pod (vCPU + memory per second). No patching, no capacity planning. You'll create one in the next step.

Exam decision shortcut

If the question mentions "minimize operational overhead for nodes" and Kubernetes is required, the answer is Fargate.

If it mentions "control over instance types" or "GPU workloads", the answer is Managed Node Groups.

Your cluster now has real compute power. Next up, you'll deploy a containerized web application and expose it to the internet through a LoadBalancer.

Deploy a Workload

Your EKS cluster has compute capacity from the managed node group, but no application is running on it yet. Pods have nowhere to come from until you create a workload.

In this step, you will deploy a containerized web server and expose it to the internet. This proves the full EKS pipeline works from container image to public URL.

In this step, get ready to:

Deploy an nginx application with 2 replicas to your cluster.
Expose the deployment through a public LoadBalancer Service.
Examine pod scheduling to see which nodes run your pods.

Deploy an nginx application

A Kubernetes Deployment describes the desired state for your application: which container image to run, how many replicas, and how to update them. The cluster's scheduler places pods onto nodes that have available capacity.

Switch back to your CloudShell session from earlier.
Create the nginx deployment by running this command:

kubectl create deployment nginx-demo --image=nginx:latest --replicas=2

Verify your pods are running by running:

kubectl get pods

You should see 2 pods with STATUS Running. Both are scheduled onto your managed EC2 nodes.

What does this command do?

The kubectl create deployment command tells the cluster to pull the nginx:latest container image and run 2 copies (replicas) of it.

The cluster scheduler automatically picks which nodes have enough CPU and memory to host each pod. You do not need to choose nodes manually.

Pods stuck in Pending?

If your pods show Pending status, the node group may still be provisioning. Run kubectl get nodes to confirm both nodes show Ready. Wait 1-2 minutes and check again.

help me debug pods stuck in Pending status on my EKS cluster

Expose the deployment with a LoadBalancer Service

Your pods are running, but they are only reachable inside the cluster. To access nginx from your browser, you need a Kubernetes Service that provisions an external load balancer.

Create the LoadBalancer Service by running this command:

kubectl expose deployment nginx-demo --type=LoadBalancer --port=80 --target-port=80 --name=nginx-service

What does this command do?

This creates a Kubernetes Service named nginx-service of type LoadBalancer. It maps port 80 on the load balancer to port 80 on your nginx containers.

On EKS, the cloud controller manager (using your cluster role permissions) automatically provisions an Elastic Load Balancer in AWS. This takes 2-3 minutes to get a public DNS name.

Check the service status by running:

kubectl get svc nginx-service

The EXTERNAL-IP column may show <pending> at first. Wait 2-3 minutes while AWS provisions the Classic Load Balancer, then run the command again.

Once the EXTERNAL-IP shows a long DNS name (like a1b2c3-xxxx.us-east-1.elb.amazonaws.com), copy it.
Before you open it, predict: what do you expect to see when you paste this URL into your browser?
Open a new browser tab and paste the EXTERNAL-IP URL.

You see the nginx welcome page. Your containerized application is live on the internet, served through an AWS load balancer that Kubernetes provisioned automatically.

Page not loading?

If the page times out, the load balancer may still be registering your nodes as healthy targets. Wait another 1-2 minutes and refresh.

If you see a connection refused error, confirm the EXTERNAL-IP is fully populated (not <pending>) by running kubectl get svc nginx-service again.

help me troubleshoot my EKS LoadBalancer Service not serving traffic

Examine pod scheduling

Your app is running, but which specific EC2 instances are hosting each pod? This detail matters for understanding how node capacity affects scheduling.

View pod placement details by running:

kubectl get pods -o wide

Notice the NODE column showing which EC2 instance each pod landed on. This confirms your pods are running on the managed node group instances.

Why does pod placement matter for the exam?

Pods are subject to each node's available capacity. If your nodes fill up with pods, new pods go Pending until the Auto Scaling Group scales up and adds more nodes.

This is fundamentally different from Fargate, where each pod gets its own dedicated micro-VM with no shared capacity constraints. You will see this contrast in the next step.

Your nginx application is live and publicly accessible. Next up, you will deploy the same workload on Fargate to see the serverless alternative side by side.

Deploy with a Fargate Profile

Your nginx app is running on EC2 nodes inside the managed node group. That works, but the SAA-C03 exam expects you to understand the serverless alternative.

With a Fargate profile, pods matching a specific namespace run without any nodes at all. Each pod gets its own isolated micro-VM. In this step, you will deploy the same workload on Fargate and see both compute models side by side.

In this step, get ready to:

Create a Pod Execution Role that lets Fargate run pods on your behalf.
Create a Fargate profile that routes pods in a specific namespace to serverless infrastructure.
Deploy nginx to the Fargate namespace and compare node-based vs serverless execution.

Create a Pod Execution Role for Fargate

Fargate needs its own IAM role, separate from the node role you created in Step 1. The Fargate infrastructure (not EC2) runs the kubelet agent for each pod, so it needs a different trust relationship.

Open the IAM console at https://console.aws.amazon.com/iam/.
Choose Roles in the left sidebar, then click Create role.
Under Trusted entity type, select AWS service.
From the Use cases for other AWS services dropdown, choose EKS.
Select EKS - Fargate Pod as your use case, then click Next.
AmazonEKSFargatePodExecutionRolePolicy is pre-selected. Click Next.
For Role name, enter eksFargatePodExecutionRole.
Click Create role.

You should see a success banner confirming the role was created.

Why does Fargate need its own role?

The node role you created earlier uses ec2.amazonaws.com as its trusted service principal because EC2 instances run the kubelet. Fargate uses a completely different infrastructure model. Its trust policy allows eks-fargate-pods.amazonaws.com to assume the role instead.

This is the third IAM role in the EKS security model the exam tests: cluster role (for the control plane), node role (for EC2 workers), and pod execution role (for Fargate). Each has a different trust policy and different permissions.

Don't see EKS - Fargate Pod as a use case?

Make sure you selected EKS from the Use cases for other AWS services dropdown, not just the main service list. The Fargate Pod option only appears under the EKS sub-options.

Help me find the EKS Fargate Pod use case in the IAM role creation wizard.

Create the Fargate profile

The Fargate profile tells EKS which pods should run on Fargate instead of EC2 nodes. It uses a namespace selector, so any pod deployed to a matching namespace automatically routes to Fargate.

Return to the EKS console and select your eks-demo-cluster cluster.
Choose the Compute tab.
Scroll down to the Fargate profiles section and click Add Fargate Profile.
For Name, enter fargate-demo-profile.
For Pod execution role, choose eksFargatePodExecutionRole.
For Subnets, keep the private subnets selected. Deselect any public subnets if they appear.
Click Next.
On the Configure Pod selection page, enter fargate-demo for the Namespace field.
Click Next, then click Create.
Wait for the Fargate profile status to show Active before continuing.

Why only private subnets?

Fargate pods are not assigned public IP addresses. They must run in private subnets that have a NAT gateway for outbound internet access (like pulling container images). This is a hard requirement, not just a best practice.

The namespace selector means any pod deployed to the fargate-demo namespace will automatically run on Fargate. Pods in other namespaces (like your existing nginx-demo in the default namespace) continue running on EC2 nodes.

Don't see eksFargatePodExecutionRole in the dropdown?

If the role does not appear, go back to the IAM console and verify the role was created with the exact name eksFargatePodExecutionRole. Also confirm you selected the EKS - Fargate Pod use case (not EKS - Cluster) during role creation.

Help me troubleshoot why my Fargate pod execution role isn't showing up in the EKS console.

Deploy to the Fargate namespace and compare

Now you will deploy the same nginx image to the Fargate-managed namespace. This proves the same workload runs on fundamentally different infrastructure without any code changes.

Switch back to CloudShell. Create the Fargate namespace by running this command:

kubectl create namespace fargate-demo

You should see a confirmation message that the namespace was created.

Deploy nginx to the new namespace by running:

kubectl create deployment nginx-fargate --image=nginx:latest --replicas=2 -n fargate-demo

What does the -n flag do?

The -n fargate-demo flag targets the fargate-demo namespace. Because your Fargate profile selector matches this namespace, EKS routes these pods to Fargate micro-VMs instead of your EC2 nodes.

Fargate pods take 30-60 seconds to start because AWS provisions a dedicated micro-VM for each one.

Wait about 60 seconds, then check the pod status by running:

kubectl get pods -n fargate-demo

You should see 2 pods with STATUS Running. If they still show Pending, wait another 30 seconds and try again.

Now comes the key comparison. Before you run the next command, think about this: what do you expect the NODE column to show for these Fargate pods compared to your earlier EC2-based pods?

View the full pod details including which node each pod runs on:

kubectl get pods -n fargate-demo -o wide

The NODE column shows names starting with fargate- instead of EC2 instance IDs. This confirms your pods are running on Fargate micro-VMs, not on the managed node group.

Now check the full node list to see both compute types together:

kubectl get nodes

You now see both your 2 EC2 nodes AND the Fargate virtual nodes listed. This is the same cluster running pods on two fundamentally different compute models simultaneously.

What is the key difference between EC2 nodes and Fargate nodes?

EC2 nodes are shared. Multiple pods can run on the same EC2 instance, and you manage capacity by sizing the node group. Fargate nodes are 1:1 with pods. Each pod gets a dedicated micro-VM with isolated compute and memory.

For the exam: if the question mentions "minimize operational overhead for nodes" and Kubernetes is required, the answer is Fargate. If it mentions "control over instance types" or "GPU workloads", the answer is Managed Node Groups.

What about persistent storage on EKS?

The exam also tests Container Storage Interface (CSI) drivers on EKS. These provide persistent storage for pods:

Amazon EBS CSI driver: single-AZ block storage. The pod and volume must be in the same Availability Zone.
Amazon EFS CSI driver: multi-AZ file storage. Works with Fargate and can be shared across pods and AZs.
Amazon FSx for Lustre: high-performance parallel file system for ML/HPC workloads.

Pods stuck in Pending?

If your Fargate pods stay in Pending for more than 2 minutes, verify that your Fargate profile status is Active in the EKS console and that the namespace selector matches exactly: fargate-demo. Also check that you selected private subnets (not public) in the profile.

Help me debug why my Fargate pods are stuck in Pending status.

You now have the same nginx image running on both EC2 managed nodes (in the default namespace) and Fargate micro-VMs (in the fargate-demo namespace). Next up, you will push further with the Secret Mission and configure auto-scaling for your pods.

Secret mission

Configure Horizontal Pod Autoscaler (HPA)

Your pods run at a fixed replica count, but real production workloads need to scale with demand. Can you configure Kubernetes to automatically add and remove pods based on CPU utilization? This is a core exam concept that mirrors ECS Service Auto Scaling.

Clean Up Your Resources

Decide whether to keep your resources running or delete them entirely. This project uses paid AWS resources that accumulate costs 24/7 if left running.

Cost warning

Your EKS cluster charges $0.10/hr for the control plane alone. Combined with 2x t3.medium EC2 instances (~$0.042/hr each), an Elastic Load Balancer (~$0.025/hr), and Fargate pod costs, the total is approximately $2-3 per hour.

If you are done with this project, delete all resources immediately. You cannot pause an EKS cluster.

Resources you used:

EKS Cluster: eks-demo-cluster ($0.10/hr control plane).
Managed Node Group: eks-demo-nodes (2x t3.medium EC2 instances).
Fargate Profile: fargate-demo-profile (billed per pod vCPU/memory per second).
Elastic Load Balancer (provisioned by the nginx-service LoadBalancer Service).
IAM Roles: eksClusterRole, eksNodeRole, eksFargatePodExecutionRole.

Keep everything running

No action needed. Choose this only if you are actively continuing work on this cluster right now.

Your EKS cluster, node group, Fargate profile, and Load Balancer will continue to incur charges.
At approximately $2-3 per hour, leaving resources running overnight would cost $24-36.
Return to delete resources as soon as you finish exploring.

Pause - I'll come back to this later

You cannot pause an EKS cluster. There is no hibernate or stop option for the control plane, node group, or Fargate profile.

If you want to stop paying, you must delete all resources using the Delete tab instructions.
You can always recreate the cluster later by following the project steps again.

Delete - I don't want to use this again

Remove all project resources to stop all charges. Follow this exact order to avoid dependency errors.

Delete the Fargate profile:

Open the EKS console and select eks-demo-cluster.
Choose the Compute tab.
Under Fargate profiles, select fargate-demo-profile.
Choose Delete. Confirm the deletion.

Delete the node group:

On the same Compute tab, under Node groups, select eks-demo-nodes.
Choose Delete. Confirm the deletion.
Wait for both the Fargate profile and node group deletions to complete before continuing.

Delete the cluster:

Return to the EKS clusters list.
Select eks-demo-cluster and choose Delete.
Type the cluster name to confirm deletion.

Delete the Load Balancer:

Open the EC2 console and select Load Balancers from the left sidebar.
Find the Load Balancer tagged with your cluster name.
Select it, choose Actions, then Delete load balancer. Confirm.

Delete the IAM roles:

Open the IAM console and select Roles.
Search for eksClusterRole. Select it, detach all policies, then delete the role.
Repeat for eksNodeRole and eksFargatePodExecutionRole.

What about the Kubernetes resources?

The Kubernetes Deployments, Services, Metrics Server, HPA, and namespaces are all deleted automatically when the cluster is removed. No separate cleanup is needed for those.

Nice Work!

You just deployed a fully functional Amazon EKS cluster running containerized workloads on both EC2 nodes and serverless Fargate pods. You can now confidently answer SAA-C03 questions about EKS architecture, node options, IAM roles, and when to choose EKS over ECS.

You've learned how to:

Created an EKS cluster with the correct IAM role model (cluster role, node role, and pod execution role) and understood the $0.10/hr control plane cost vs ECS's free control plane.
Deployed a containerized application using kubectl from CloudShell and exposed it to the internet through a LoadBalancer Service that automatically provisioned an Elastic Load Balancer.
Created a Fargate profile to run the same workload serverlessly, proving that pods can execute on dedicated micro-VMs without managing any nodes.
Secret Mission: Configured a Horizontal Pod Autoscaler to auto-scale pods between 2 and 10 replicas based on CPU utilization.

Ready to quiz yourself?