Create an Amazon EKS Foundation

Build and tear down a cost-controlled Amazon EKS cluster with managed nodes.

Introduction

30 Second Summary

Sometimes a service answers the door but still has nowhere to do the work behind it. In the cloud, that gap can keep the meter running while nothing useful is happening.

In this project, you will build a short-lived Amazon EKS foundation for OrderFlow. You will prove the gap between its managed Kubernetes control plane and worker capacity with a Pod before auditing a complete teardown.

What You'll Build

You will watch capacity-check stay Pending on an empty cluster before the same workload becomes Running on a Ready managed worker.

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

A reproducible cluster definition in cluster.yaml whose dry run exposes every guardrail before provisioning.
A managed node group that turns the existing capacity-check Pod from Pending to Running on a Ready Amazon EC2 worker.
A teardown audit proving orderflow-foundation is absent from Amazon EKS. The audit also proves its active AWS CloudFormation stack is gone.
Secret Mission: A controlled scale-out of orderflow-workers from one Ready node to two. You will then return safely to the one-node cost baseline.

Are there any prerequisites?

You need administrator access to an AWS account plus a Linux terminal with AWS CLI, kubectl, and eksctl already working. The project creates paid cloud resources that you will delete in the same session.

Before We Start

This checkpoint confirms that your Linux terminal has AWS CLI, kubectl, and eksctl ready under an AWS administrator identity. You are committing to build a short-lived Amazon EKS foundation for worker scheduling, with complete deletion in the same session.

Verify Access and Encode Guardrails

An Amazon EKS build can create chargeable infrastructure within minutes. A wrong account or loose capacity setting can turn a short lab into an expensive leftover.

The safest foundation begins with read-only checks. This step also encodes the cluster limits in YAML before provisioning begins.

In this step, get ready to:

Confirm each command-line client is compatible.
Verify the active AWS identity.
Encode the cluster guardrails in two YAML files.

Check client versions and AWS identity

The AWS CLI identifies the active account. The kubectl client must stay within one minor version of the Kubernetes 1.36 API server.

This guide also pins eksctl to 0.230.0. Matching that release keeps the configuration behavior consistent throughout the project.

Check the three installed clients by running these commands:

aws --version
kubectl version --client
eksctl version

What do these checks prove?

The aws --version command confirms that the AWS CLI can start.
The kubectl version --client command reports the client that communicates with the cluster API.
The eksctl version command checks the tool that creates the cluster from your configuration.

The AWS CLI should print its installed version. kubectl should report client version 1.35, 1.36, or 1.37.

eksctl must report 0.230.0 before you continue.

✔️ kubectl and eksctl are compatible

Your clients match the versions required for this build. You can move on to the account checks.

ⓧ kubectl is outside 1.35 to 1.37

Use the official Amazon EKS kubectl installation guide to install a compatible Linux client.
Choose kubectl version 1.36.2 for the closest match to the control plane.
Return to the version check above after the update.

ⓧ eksctl is not 0.230.0

Follow the official eksctl v0.230.0 Linux installation flow to update the installed binary.
Complete the documented checksum verification before installing the downloaded binary.
Return to the version check above after the update.

Still seeing an incompatible version?

Your shell may still be finding an older binary earlier in its search path. Help me find which kubectl or eksctl binary my Linux shell is using.

Client compatibility only proves that the tools can run. The next read-only checks confirm which AWS account receives every resource created later.

Audit the active identity and the regional EKS inventory by running these commands:

aws sts get-caller-identity
aws eks list-clusters --region us-east-1

What do these commands check?

The identity response shows the active account ID. It also shows the IAM principal used by later commands.
The cluster list checks the us-east-1 region for existing EKS clusters.
Both commands only read AWS state. They do not create chargeable resources.

You should recognize the returned account. The regional cluster list must not contain orderflow-foundation.

Identity or inventory check failed?

Refresh your AWS authentication if the CLI cannot use the configured credentials. Stop here if the account is unfamiliar or orderflow-foundation already exists.

Help me diagnose my AWS identity or EKS inventory check.

Encode the cluster guardrails

A declarative infrastructure file records the intended cluster before AWS receives a create request. The same file can later reproduce or delete the environment.

Why a managed node group?

A managed node group keeps worker capacity visible during this project. You can see exactly when an Amazon EC2 node joins the control plane.

Disabling EKS Auto Mode preserves that boundary. The one-node baseline and two-node maximum also place a hard limit on worker capacity.

Create cluster.yaml in ~/Desktop with your terminal editor using this first block:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: orderflow-foundation
  region: us-east-1
  version: "1.36"
  tags:
    Project: orderflow-eks-foundation
    Lifecycle: same-session

upgradePolicy:
  supportType: STANDARD

autoModeConfig:
  enabled: false

What does this configuration establish?

The apiVersion and kind values identify the eksctl cluster configuration schema.
The metadata fixes the cluster name. It also fixes the AWS region and Kubernetes version.
The tags identify the project lifecycle. The Lifecycle: same-session tag records the planned teardown window.
The upgrade policy selects standard Kubernetes support.
The Auto Mode setting keeps managed node groups as the worker-capacity mechanism.

Save cluster.yaml.
Compare the top of the file with the block above.

You should see the cluster identity followed by the support policy. The final line in this first section should be enabled: false.

Does the first section look misaligned?

YAML uses indentation to show which values belong together. Keep each nested level aligned with spaces.

Help me compare the first section of my cluster.yaml file.

Append the networking and worker configuration below enabled: false using this block:

vpc:
  nat:
    gateway: Disable
  clusterEndpoints:
    publicAccess: true
    privateAccess: false

managedNodeGroups:
  - name: orderflow-workers
    amiFamily: AmazonLinux2023
    instanceType: t3.large
    desiredCapacity: 1
    minSize: 1
    maxSize: 2
    volumeSize: 20
    volumeType: gp3
    volumeEncrypted: true
    privateNetworking: false
    ssh:
      allow: false
    labels:
      workload: orderflow
    tags:
      Project: orderflow-eks-foundation
      Lifecycle: same-session

How do these guardrails control cost?

The VPC configuration disables NAT Gateway creation.
The cluster API uses public endpoint access. Private endpoint access stays disabled.
The orderflow-workers group starts with one t3.large node.
The scaling range permits a minimum of one node. It caps the group at two nodes.
Each node receives a 20 GiB encrypted gp3 root volume from Amazon EBS.
Public worker networking provides outbound access without a NAT Gateway. SSH access remains disabled.
The workload label supports later scheduling choices. The tags preserve the project identity and same-session lifecycle.

Save cluster.yaml.
Compare the capacity values with the block above.

You should see a one-node baseline with a two-node ceiling. You should also see encrypted storage and disabled SSH access.

Are any guardrails missing?

Check that managedNodeGroups starts at the left edge. Confirm that every worker setting remains nested under orderflow-workers.

Help me find missing or misplaced guardrails in cluster.yaml.

✔️ Awesome, I've got everything!

Your complete cluster configuration now records the control-plane settings and worker limits. Make sure cluster.yaml is saved.

ⓧ I'd like to double check the full code

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: orderflow-foundation
  region: us-east-1
  version: "1.36"
  tags:
    Project: orderflow-eks-foundation
    Lifecycle: same-session

upgradePolicy:
  supportType: STANDARD

autoModeConfig:
  enabled: false

vpc:
  nat:
    gateway: Disable
  clusterEndpoints:
    publicAccess: true
    privateAccess: false

managedNodeGroups:
  - name: orderflow-workers
    amiFamily: AmazonLinux2023
    instanceType: t3.large
    desiredCapacity: 1
    minSize: 1
    maxSize: 2
    volumeSize: 20
    volumeType: gp3
    volumeEncrypted: true
    privateNetworking: false
    ssh:
      allow: false
    labels:
      workload: orderflow
    tags:
      Project: orderflow-eks-foundation
      Lifecycle: same-session

Add the capacity check and validate the plan

The second file defines a small Pod that exposes whether worker capacity exists. Its pause container keeps the workload available for a clear scheduling check.

Create capacity-check.yaml in ~/Desktop with your terminal editor using this block:

apiVersion: v1
kind: Pod
metadata:
  name: capacity-check
  labels:
    app: capacity-check
spec:
  restartPolicy: Never
  containers:
    - name: pause
      image: public.ecr.aws/eks-distro/kubernetes/pause:v1.36.2-eks-1-36-6
      imagePullPolicy: IfNotPresent

What does this manifest define?

The manifest creates one Pod named capacity-check.
The matching app label makes the test workload easy to identify.
The restart policy prevents Kubernetes from restarting a completed container.
The pause image provides a minimal workload for testing scheduling.
The image pull policy reuses a local copy when one already exists.

Save capacity-check.yaml.
Compare the saved manifest with the block above.

You should see one container named pause. Its image should end with v1.36.2-eks-1-36-6.

Does the Pod manifest differ?

Check the indentation beneath containers. Confirm that the image value appears on one uninterrupted line.

Help me compare my capacity-check.yaml manifest.

✔️ Awesome, I've got everything!

Your scheduling test manifest is complete. Make sure capacity-check.yaml is saved beside cluster.yaml.

ⓧ I'd like to double check the full code

apiVersion: v1
kind: Pod
metadata:
  name: capacity-check
  labels:
    app: capacity-check
spec:
  restartPolicy: Never
  containers:
    - name: pause
      image: public.ecr.aws/eks-distro/kubernetes/pause:v1.36.2-eks-1-36-6
      imagePullPolicy: IfNotPresent

A dry run asks eksctl to render the cluster configuration without creating AWS resources. This is your final chance to catch a structural mistake before provisioning.

Before you run the check, do you expect eksctl to preserve every capacity limit from cluster.yaml?

Return your Linux terminal to ~/Desktop using your usual shell navigation.
Validate the configuration without provisioning resources by running this command:

eksctl create cluster --config-file=cluster.yaml --dry-run

What should I see?

The command renders the interpreted configuration without creating the cluster.
The metadata names orderflow-foundation in us-east-1 at Kubernetes version 1.36.
The support policy shows STANDARD.
Auto Mode shows false.
NAT mode shows Disable.
The output contains one managed node group named orderflow-workers.
The node group starts at one node. Its maximum remains two nodes.
The Project tag identifies orderflow-eks-foundation.
The Lifecycle tag identifies same-session.

Did the dry run fail?

A dry-run failure usually points to YAML indentation or a misplaced field. Compare cluster.yaml with the complete reference above.

Help me debug my eksctl dry-run configuration.

You have contained the risky part before creating anything. Next, you will launch the control plane without workers and prove that its Kubernetes API is reachable.

Create the Control Plane Without Workers

Your validated cluster.yaml now captures every guardrail for the foundation. The next goal is to turn that design into a reachable control plane.

Amazon Elastic Kubernetes Service (Amazon EKS) manages the Kubernetes API separately from worker capacity. You will create only that layer so the empty data plane becomes visible.

In this step, get ready to:

Create the EKS control plane without a managed node group.
Configure kubectl to use the new cluster context.
Verify the control plane settings from AWS.
Confirm the Kubernetes node inventory is empty.

Create the control plane only

The control plane is the AWS-managed side of the cluster. It can answer API requests without Amazon EC2 worker nodes.

This starts the paid session

This action starts EKS control-plane billing at $0.10 per cluster per hour. The same-session cleanup removes the environment before you finish.

Provisioning can take several minutes, so a quiet terminal during part of the process is expected.

Keep worker capacity out of this build by running the command below:

eksctl create cluster --config-file=cluster.yaml --without-nodegroup

What does this command create?

The --without-nodegroup option omits orderflow-workers from this creation run.
The eksctl command provisions the control plane through AWS CloudFormation.
The command creates a dedicated VPC from the settings in cluster.yaml.
The explicit configuration keeps EKS Auto Mode disabled.
The networking configuration prevents NAT Gateway creation.

Leave the Linux terminal running until the creation process finishes.
Confirm the command finishes without a creation error.

Seeing an Availability Zone error?

AWS can reject an Availability Zone in us-east-1 with UnsupportedAvailabilityZoneException.

Copy the supported Availability Zones listed in the live error.
Retry the same creation command with those suggested zones.

If the retry path is unclear, help me adapt the cluster creation command.

Connect kubectl to the cluster

A Kubernetes context tells kubectl which API endpoint to use. The context lives in your kubeconfig file.

Point kubectl at orderflow-foundation by running this command:

aws eks update-kubeconfig --region us-east-1 --name orderflow-foundation

What does this command change?

The update-kubeconfig subcommand writes the cluster endpoint information to your kubeconfig file.

It sets the new entry as the current context. Future kubectl requests use the same AWS identity that created the cluster.

Confirm the kubeconfig update finishes without an authentication error.

Could not update kubeconfig?

Return to the AWS identity check from the previous step.
Confirm the active credentials still belong to the intended AWS account.
Rerun the kubeconfig command after restoring your authenticated session.

If access still fails, help me debug the EKS kubeconfig update.

Verify the empty control plane

AWS reports the control plane lifecycle plus its configuration. Kubernetes reports the machines available for scheduling.

Inspect the EKS control-plane record by running this command:

aws eks describe-cluster --name orderflow-foundation --region us-east-1

What should the cluster record show?

The cluster status is ACTIVE.
The Kubernetes version is 1.36.
The support type is STANDARD.
The compute configuration does not show EKS Auto Mode as enabled.

Cluster status is not active?

Wait for the creation process in the earlier terminal output to finish.
Rerun the cluster description command after the provisioning activity settles.

If the status still does not become active, help me diagnose the EKS control plane.

Before you ask Kubernetes, what do you expect its node inventory to contain when the control plane has no worker capacity?

Reveal the current node inventory by running this command:

kubectl get nodes

What should you see?

The kubectl request reaches the live Kubernetes API. The node inventory contains no worker entries.

That empty inventory proves worker capacity has not joined the cluster. Your local cluster.yaml remains unchanged.

Your local capacity-check.yaml also remains unchanged.

Cannot reach the API?

Return to the kubeconfig update command from the previous substep.
Rerun that command with your authenticated AWS session.
Check that the cluster description still reports an active control plane.

If kubectl still cannot connect, help me debug access to the empty EKS cluster.

You now have a live control plane that responds while its data plane remains empty. Next, you will submit the workload that exposes what this missing capacity means.

Expose the Missing Capacity

Your Amazon EKS control plane now answers through the Kubernetes API. The node inventory remains empty.

A reachable control plane can store a Pod definition. Scheduling needs a data plane with worker capacity. This step turns that gap into visible evidence.

In this step, get ready to:

Submit the existing capacity-check.yaml manifest to the cluster.
Observe the scheduler's response with no nodes available.
Compare the test workload with cluster-wide system workloads.

Test the empty cluster

The existing capacity-check.yaml manifest defines a minimal workload. Submitting it tests what the control plane does when no worker capacity exists.

Submit the test Pod by running this command:

kubectl apply -f capacity-check.yaml

What does this command do?

The kubectl client sends the manifest to the current cluster context.
The -f option selects capacity-check.yaml as the resource definition.
The Kubernetes API stores the Pod definition before scheduling begins.

The terminal shows that the Kubernetes API accepted the capacity-check Pod resource.

Pod submission failed?

Confirm that capacity-check.yaml remains in your current directory.
Check that your current Kubernetes context points to orderflow-foundation.
Use help me diagnose why kubectl could not apply my Pod manifest.

Reveal the scheduling gap

The control plane has accepted the workload. The scheduler must now look for a node that can run it.

Before you check, predict the Pod state that an empty node inventory will produce.

Inspect the Pod's scheduling state by running this command:

kubectl get pods -o wide

What does wide output show?

The command lists Pods in the default namespace.
The wide output includes extra scheduling information such as the assigned node.

You will see capacity-check in Pending state. Its node assignment remains empty.

That Pending state is the intended obstacle. The control plane accepted the resource, but the scheduler has nowhere to place it.

Pod missing or already assigned?

Return to the previous apply command if capacity-check is missing from the list.
Recheck the empty node inventory if the Pod already has a node assignment.
Use help me diagnose an unexpected capacity-check Pod state.

Compare cluster-wide workloads

A cluster-wide view reveals whether system workloads face the same capacity gap. CoreDNS may also be unscheduled or degraded while the cluster has no nodes.

List Pods across every namespace by running this command:

kubectl get pods -A -o wide

What does the cluster-wide view add?

The -A option includes workloads from every namespace.
The output lets you compare the test Pod with networking, proxy, and DNS workloads.

You may see system workloads waiting for capacity alongside capacity-check. CoreDNS may appear unscheduled or degraded until worker capacity joins.

Cluster-wide list unavailable?

Confirm that your Linux terminal still has network access to the cluster API.
Verify that your AWS authentication remains active.
Use help me restore kubectl access to my EKS cluster.

Before the final check, predict whether the Pod has found a node on its own.

Verify the designed obstacle by running this command again:

kubectl get pods -o wide

What does this final check prove?

The command checks the test Pod in the default namespace again.
The node assignment shows whether any worker capacity has joined since the first check.

You will still see capacity-check in Pending state. Its node assignment remains empty because no worker capacity has joined the cluster.

You have the proof: the control plane accepts work but cannot schedule it without a data plane. The next step adds tightly bounded managed worker capacity so this same Pod can run.

Add Managed Worker Capacity

Your Amazon EKS control plane is reachable. The Pending Pod proved that the cluster cannot run workloads without a data plane.

This step adds the managed node group defined in cluster.yaml. One bounded Amazon EC2 worker joins the cluster so the existing Pod can run.

In this step, get ready to:

Create orderflow-workers from cluster.yaml.
Verify that one t3.large worker joins in the Ready state.
Confirm that the existing capacity-check Pod runs after system workloads recover.

Create the managed node group

The worker configuration already lives in cluster.yaml. Using that file keeps the deployed capacity aligned with the limits you validated earlier.

Starting the node group activates chargeable EC2 storage and compute resources. The one-node baseline keeps the worker layer inside the declared capacity bound.

Expect this command to take several minutes while AWS provisions the worker resources. Keep the terminal open during the wait.

Use the unchanged cluster.yaml as the source of truth by running:

eksctl create nodegroup --config-file=cluster.yaml

What does this command do?

The eksctl command reads the managedNodeGroups section in cluster.yaml.
AWS CloudFormation provisions the resources for orderflow-workers.
Amazon EC2 launches one t3.large worker using AmazonLinux2023.
Amazon EBS provides a 20 GiB encrypted gp3 root volume.
SSH remains disabled. The node receives the workload label with the value orderflow.

Wait for the command to return to your shell prompt.

A successful return means the managed node group resources finished provisioning without a reported stack failure.

Node Group Creation Failed?

Confirm that your current AWS session still has administrator permissions.
Review the final failure lines for permission problems.
Check whether the failure mentions subnet connectivity or unavailable EC2 capacity.

If the cause is unclear, help me diagnose the managed node group creation failure.

Verify the worker joins the cluster

The node group view confirms the AWS-managed capacity settings. The node view confirms whether the EC2 instance has registered with Kubernetes.

Inspect the new node group's capacity settings by running:

eksctl get nodegroup --cluster=orderflow-foundation --name=orderflow-workers

What Should the Node Group Report?

The result should identify orderflow-workers as the cluster's managed node group.
The desired capacity should be 1.
The minimum capacity should be 1.
The maximum capacity should be 2.
The instance type should be t3.large.

Check whether the worker has registered with Kubernetes by running:

kubectl get nodes -o wide

What Does Ready Mean?

A node in the Ready state has registered with the control plane. Kubernetes can now consider it when scheduling eligible Pods.

The wide view shows the worker's network addresses and runtime details. Public worker networking gives this node a public IPv4 address.

You should see exactly one node in the Ready state. Its wide output should include a public address.

Worker Missing or Not Ready?

Check the preceding node group output for a creation state that is still progressing.
Allow the worker time to register if the node group has only just finished provisioning.
Confirm that public worker networking remains enabled in the unchanged cluster.yaml file.

If the node still does not join, help me diagnose why my EKS managed node is not Ready.

Confirm scheduling and system health

The new worker gives the scheduler somewhere to place the existing capacity-check Pod. Cluster networking, proxy, and CoreDNS workloads can also begin running on the node.

Check workloads across every namespace by running:

kubectl get pods -A -o wide

What Does This Check Show?

The -A option includes system workloads from every namespace.
The -o wide option includes each Pod's assigned node.
Networking, proxy, and DNS workloads should be Running or progressing normally.

Repeat the same check until the default networking, proxy, and DNS workloads have settled into the Running state.

System Pods Still Progressing?

Allow progressing Pods time to pull their images.
Confirm that the worker still reports the Ready state if system Pods remain unscheduled.

If a system workload remains stuck, help me diagnose the EKS system Pod state.

Before you run the final check, consider whether the existing Pod remains Pending or starts Running now that a worker has joined.

Run the final node and Pod checks with these commands:

kubectl get nodes -o wide
kubectl get pods -o wide

How Do These Checks Prove Scheduling Works?

The first command proves that one worker is available in the Ready state.
The second command proves that the existing capacity-check Pod moved from Pending to Running without a manifest change.
The assigned worker confirms that the control plane can now schedule workloads onto the data plane.

You should see one Ready node. You should also see capacity-check in the Running state with that worker assigned.

That is the capacity gap closed. Your control plane now has a bounded worker layer that can run Kubernetes workloads.

Capacity Check Still Pending?

Confirm that the worker still reports the Ready state.
Repeat the all-namespaces check to confirm that networking and DNS workloads are progressing.
Check whether the Pod output still lacks an assigned worker.

If the Pod remains unscheduled, help me diagnose why capacity-check is still Pending.

Secret mission

Scale Out and Return to the Cost Baseline

Briefly scale the managed node group from one worker to two workers. Verify the added capacity before safely returning the cluster to its one-node cost baseline.

Clean Up Your Resources

Your live Amazon Elastic Kubernetes Service (Amazon EKS) foundation continues to incur costs. Decide whether to keep it running, pause its worker capacity, or delete it entirely.

Cost warning

The live Amazon EKS control plane costs $0.10 per cluster per hour.

The Ready worker adds Amazon EC2 usage. Its Amazon EBS storage charge continues. Its public IPv4 charge also continues.

Complete deletion is the selected path for this project.

Resources you used:

The orderflow-foundation Amazon EKS 1.36 STANDARD control plane.
The orderflow-workers managed node group with one active AmazonLinux2023 t3.large worker.
The worker's 20 GiB encrypted gp3 root volume and public IPv4 address.
The eksctl-managed VPC with public subnets, private subnets, route tables, an internet gateway, and security groups.
The Kubernetes system add-ons, IAM roles, and AWS CloudFormation stacks created by eksctl.
The local cluster.yaml and capacity-check.yaml files.

Keep everything running

No action is needed. Choose this if you plan to continue building on this cluster immediately.

Keep the orderflow-foundation control plane active.
Keep the orderflow-workers node group at its one-node baseline.
Expect ongoing control-plane, worker, storage, public IPv4, and possible data-transfer charges.
Retain cluster.yaml and capacity-check.yaml as the reproducible definitions for this foundation.

Pause - I'll come back to this later

Pause the worker layer to stop its active instance charge. The Amazon EKS control plane remains active at $0.10 per cluster per hour.

Repeat the eksctl node group scaling method from the Secret Mission with desired capacity 0.
Set the minimum capacity to 0 in the same scale operation.
Keep the maximum capacity at 2 in the same scale operation.
Wait for the scaling operation to finish.
Confirm the worker inventory is empty using the same kubectl node check from earlier.
Keep both local YAML files so you can restore the one-node baseline later.

Delete - I don't want to use this again

Deletion is permanent. The commands below wait for AWS to finish so you can verify the result before leaving.

Reconfirm the active AWS identity by running this command:

aws sts get-caller-identity

What does this command confirm?

The response identifies the active role or user. It also shows the AWS account that receives the deletion request.

Confirm the response shows the intended AWS account.
Audit the cluster for external entry points by running these commands:

kubectl get svc --all-namespaces
kubectl get ingress --all-namespaces

What does this audit check?

The first command lists Services across every namespace.
The second command lists Ingress resources across every namespace.

You should find no project-created external load balancer. You should also find no Ingress resources.

Delete the complete cluster foundation by running this command:

eksctl delete cluster --config-file=cluster.yaml --disable-nodegroup-eviction --wait

How does this deletion stay reliable?

The --disable-nodegroup-eviction flag bypasses disruption checks that can block removal of a one-node cluster.

The --wait flag keeps the terminal attached until deletion finishes. This surfaces AWS CloudFormation failures before you leave.

Did the deletion stop?

Reauthenticate with the AWS method you already use if your credentials expired.
Repeat the identity check after reauthentication.
Rerun the same cluster deletion command after the intended account is confirmed.
Help me troubleshoot an interrupted eksctl cluster deletion..

Verify the EKS inventory after deletion by running this command:

aws eks list-clusters --region us-east-1

What does this inventory prove?

This command lists the EKS clusters that remain in us-east-1.

You should no longer see orderflow-foundation in the cluster list. That confirms the paid EKS control plane is gone.

The final cloud audit intentionally queries the deleted cluster stack. A missing stack provides the expected proof of cleanup.

Audit the former cluster stack by running this command:

aws cloudformation describe-stacks --stack-name eksctl-orderflow-foundation-cluster --region us-east-1

What should this audit return?

AWS CloudFormation returns ValidationError when the named active stack no longer exists.

You should see ValidationError for eksctl-orderflow-foundation-cluster. That confirms the active cluster stack is gone.

Return to the directory that contains cluster.yaml and capacity-check.yaml.
Delete both local project files by running this command:

rm cluster.yaml capacity-check.yaml

What does this command remove?

The command removes the two local YAML definitions. It does not contact AWS because the cloud deletion is already complete.

That completes the cleanup. Your paid EKS environment and its active CloudFormation stack are now gone.

Nice Work!

Mission complete! You built a cost-controlled Amazon EKS foundation that makes the boundary between the control plane and worker capacity visible.

You've learned how to:

Define a reusable Amazon EKS foundation in cluster.yaml for Kubernetes 1.36. The cost guardrails disable Auto Mode compute. They disable NAT Gateway creation. They cap orderflow-workers at two t3.large nodes.
Demonstrate the control plane and data plane boundary with the capacity-check Pod. Its shift from Pending to Running proves that worker capacity unlocks scheduling.
Connect kubectl through the correct Kubernetes context. Delete the paid environment through the guarded teardown flow. Audit Amazon EKS for active leftovers. Audit AWS CloudFormation for active leftovers.
Complete the optional Secret Mission by scaling orderflow-workers from one Ready node to two. Return the group to the one-node cost baseline with its declared bounds intact.

Ready to quiz yourself?