Sitemap

Deploying The 2048 Game on EKS Fargate Without the Orphaned Resource Nightmare

8 min readJul 15, 2025

--

Press enter or click to view image in full size

Serverless Saved My AWS Bill (And My Sanity)

After five suspended accounts and $170 in surprise charges, I learned the hard way: orphaned AWS resources are silent budget killers. Without a Free Tier safety net (thanks to Naira card limits), every misstep hurt—until I discovered AWS Fargate.

Why Fargate became my cost-saving hero:

  • Zero idle costs: Pay only for active tasks, not idle EC2 instances.
  • No node management: Forget patching servers or over-provisioning capacity.
  • Built-in scaling: Tasks launch in seconds, perfect for unpredictable workloads.

Today, I’ll walk you through: Deploying 2048 on EKS Fargate (with all the necessary commands), The ALB Ingress trap that wasted 8 hours of my life, The nuclear cleanup guide for when AWS refuses to let go

Prerequisites

Before we begin, ensure you have the following:

  1. Basic understanding of Kubernetes concepts
  2. AWS CLI installed and configured with the appropriate IAM permissions.
  3. eksctl is installed to create and manage the EKS cluster.
  4. kubectl is installed for Kubernetes cluster management.
  5. AWS account with the necessary permissions.

Step 1: Deploying the Cluster and Game

1. Create an EKS Fargate Cluster

eksctl create cluster --name classiq04-cluster --region us-east-1 --fargate
aws eks update-kubeconfig --name classiq04-cluster --region us-east-1
kubectl get nodes  

When you run eksctl create cluster --name classiq04-cluster --region us-east-1 --fargate, it automatically provisions a fully managed EKS cluster with Fargate compute, handling all underlying infrastructure including VPC setup, subnets, IAM roles, and security groups - unlike traditional EC2-based clusters, Fargate eliminates node management since AWS dynamically allocates serverless compute for your pods, then aws eks update-kubeconfig --name classiq04-cluster --region us-east-1 configures local kubectl access by updating your kubeconfig with proper IAM authentication, and finally kubectl get nodes confirming your serverless cluster is operational without any worker nodes to manage. **Dont forget classiq04-cluster is the name of my cluster and my region is us-east-1 so replace with your specific values** Thank you :)

Press enter or click to view image in full size

Part 2: Application Deployment

2.1 Creating a Fargate Profile

Fargate requires explicit pod scheduling rules:

eksctl create fargateprofile \
--cluster classiq04-cluster \
--region us-east-1 \
--name alb-sample-app \
--namespace game-2048

The eksctl create fargateprofile command defines where my Fargate pods can run - in this case, we're creating a profile named 'alb-sample-app' that will automatically deploy any pods in the 'game-2048' namespace onto Fargate infrastructure, with EKS handling all the underlying compute provisioning while maintaining the networking and security rules specified in your cluster configuration.

2.2 Deploying the 2048 Game

Important Considerations for a Successful EKS Deployment

Before creating the EKS cluster, consider the following points to avoid common errors and ensure a smooth deployment:

  1. Fargate Profile and Pod Namespace Consistency: Ensure that the namespace specified in the Fargate profile matches the namespace of the pods you intend to run. Mismatches will prevent the pods from being scheduled.
  2. Multiple Fargate Profiles for Different Applications: You can create multiple Fargate profiles, each associated with different namespaces. This setup allows you to host various applications securely isolated by namespace.
  3. Private Subnet Requirement for Fargate Profile: Fargate profiles require private subnets. Ensure that you have at least one private subnet available in your VPC for Fargate to function correctly.
  4. NAT Gateway for Internet Access: Since Fargate tasks in private subnets do not have direct access to the internet, you must configure a NAT gateway if your applications need to pull images from public repositories. This setup ensures that the pods can access necessary resources without exposing them directly to the internet.
  5. Pod Selector Matching: The pod selector in the Fargate profile and the pod deployment YAML file must match. For example, if your Fargate profile uses selector: service:eks-fargate, ensure your pod deployment includes the same label.

Deploy the application resources:

Option 1: Quick Start (One Command)

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.5.4/docs/examples/2048/2048_full.yaml

Just run this — it sets up everything automatically: the game, networking, and load balancer.

Option 2: Look Before You Leap (for the cautious):

---
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
---
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80

The command creates:

  • A container with the 2048 game (5 replicas for reliability)
  • A load balancer so you can access it online
  • All the necessary wiring to make it work on Fargate

Same result either way — choose your comfort level!”

Press enter or click to view image in full size

Hold up! Before you rage-refresh your browser expecting the game to work: that Ingress we just deployed? It’s currently as useless as a screen door on a submarine. Why? Because AWS needs its special Load Balancer Controller to actually create the ALB. But that’s why I’m here. Walk with me :)

Part 3: Fixing the Load Balancer Dilemma

To Fix It this you’ll need three things:

  1. Special permissions (because AWS loves paperwork)
  2. A controller that actually builds the ALB
  3. A service account to connect them

This is the same crap I had to Google for 3 hours when my first ALB failed. You’re welcome.

3.1 Enable IAM OIDC Provider

eksctl utils associate-iam-oidc-provider --cluster 04-cluster --approve

3.2 Create IAM Policy

curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/install/iam_policy.json
aws iam create-policy \
--policy-name AWSLoadBalancerControllerIAMPolicy \
--policy-document file://iam_policy.json

3.3 Create IAM Service Account

eksctl create iamserviceaccount \
--cluster=04-cluster \
--namespace=kube-system \
--name=aws-load-balancer-controller \
--role-name AmazonEKSLoadBalancerControllerRole \
--attach-policy-arn=arn:aws:iam::680993828841:policy/AWSLoadBalancerControllerIAMPolicy \
--approve

3.4 Installing the ALB Controller

helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=04-cluster \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller

Verify installation:

kubectl get deployment -n kube-system aws-load-balancer-controller

Part 4: Verifying the Deployment

Is This Thing Even Working? (Let’s Check)

Get Bankole Samuel’s stories in your inbox

Join Medium for free to get updates from this writer.

Run these two commands and pray to the cloud gods

kubectl get all -n game-2048
kubectl get ingress -n game-2048

If you see:
✅ deployment-2048-xxxx with 5/5 ready pods
✅ An actual URL in the ADDRESS field (not just <pending>)

Congratulations! Your game is now internet-famous.

Press enter or click to view image in full size

Pro Tip: That ALB URL? It’ll look like:
k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.us-east-1.elb.amazonaws.com
Yes, AWS hates pretty URLs. No, you can't change it (unless you want to setup Route53, which is a whole other nightmare).

Part 5: The Inevitable Cleanup

To avoid incurring unnecessary charges, it’s important to delete your EKS cluster and associated resources when they are no longer needed.

Follow these steps to clean up your environment:

  1. Delete the EKS Cluster using eksctl:
  • The easiest way to delete the EKS cluster is by using the eksctl command-line tool.
  • This command will delete the cluster and all associated resources, such as worker nodes and networking components.
eksctl delete cluster --name <cluster-name> --region <region-name>

2. Verify Cluster Deletion:

  • After running the delete command, verify that the cluster has been deleted by checking the status in the AWS Management Console or by using the AWS CLI:
aws eks describe-cluster --name <cluster-name> --region <region-name>
  • If the cluster has been successfully deleted, this command will return a “ResourceNotFoundException”.

3. Delete Associated Resources Manually:

Although eksctl typically cleans up all resources, you should manually verify that there are no lingering resources that could incur charges.

Check and delete the following resources associated with your cluster if necessary:

  • Eks cluster
  • Cloud formation stacks
  • Loadbalancers
  • Network Interfaces
  • Nat Gateway
  • VPC
  • Elastic IPs
  • Security Groups

NB: Make sure you follow this order youll save yourself sometime

4. Delete IAM Roles and Policies:

  • If you created any IAM roles or policies for your cluster (e.g., for the AWS Load Balancer Controller), delete them to avoid unnecessary charges:
aws iam delete-role --role-name <role-name>
aws iam delete-policy --policy-arn arn:aws:iam::<your-aws-account-id>:policy/<policy-name>

Replace <role-name> with the name of the IAM role and <policy-name> with the name of the IAM policy.

By following these steps, you ensure that all components associated with your EKS cluster are deleted, preventing any additional charges from accruing.

Part 6: Challenges Faced and Solutions from a Battle-Tested Vet

After deploying this project four times (yes, four!), I’ve collected all the painful lessons so you don’t have to. Here are the landmines waiting for you and exactly how to defuse them:

1. The “I Already Exist” Errors

Problem:
When recreating clusters, you’ll hit these maddening errors:

Press enter or click to view image in full size

Solution:
Nuclear cleanup before retrying:

# Delete OIDC provider (if exists)
eksctl utils disassociate-iam-oidc-provider --cluster classiq04-cluster --region us-east-1
# Delete service account
eksctl delete iamserviceaccount \
--cluster=classiq04-cluster \
--namespace=kube-system \
--name=aws-load-balancer-controller
# Delete policy (get ARN first)
POLICY_ARNS=$(aws iam list-policies --query 'Policies[?PolicyName==`AWSLoadBalancerControllerIAMPolicy`].Arn' --output text)
for POLICY_ARN in $POLICY_ARNS; do aws iam delete-policy --policy-arn $POLICY_ARN; done

2. The Phantom CloudFormation Stack

Problem:
Your cluster deletion fails halfway, leaving a zombie CloudFormation stack that blocks new deployments with:

Error: Cannot create cluster 'classiq04-cluster' because a cluster with the same name already exists

Solution:

# List all stacks
aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE DELETE_FAILED
# Delete the stuck stack
aws cloudformation delete-stack --stack-name eksctl-classiq04-cluster-cluster
# Wait 10 minutes if it's still deleting, then force cleanup:
aws cloudformation delete-stack --stack-name eksctl-classiq04-cluster-cluster --retain-resources "AWS::EC2::SecurityGroup"

Conclusion: Master EKS Fargate & Avoid Costly Mistakes

Deploying the 2048 game on EKS Fargate is a fantastic way to experience serverless Kubernetes without managing nodes. But as I learned the hard way — through suspended accounts and surprise charges — AWS orphaned resources can silently drain your budget if not cleaned up properly.

Key Takeaways

✅ Fargate eliminates idle costs — Pay only for running tasks, not idle EC2 instances.
✅ ALB Ingress requires the Load Balancer Controller — Don’t waste 8 hours like I did; install it first!
✅ Orphaned resources are silent killers — NAT Gateways ($0.045/hr), ALBs ($0.0225/hr), and Elastic IPs ($0.005/hr) add up fast.
✅ Always verify deletions — Check CloudFormation, VPC, Load Balancers, and NAT Gateways after cluster deletion.

If you enjoyed this, please leave a like and a comment if you can — and don’t forget to subscribe for more valuable AWS tips, tutorials, and cost-saving hacks! See you soon!

--

--

Written by Bankole Samuel

DevOps Engineer | Cloud Cost Warrior |☁️ AWS | 🐧 Linux | 🛳️ Kubernetes | Jenkins