Deploying the 2048 Game on AWS EKS: A Complete Walkthrough

A practical guide to containerized workloads, Fargate, ALB Ingress, and everything in between.

Introduction

Amazon Elastic Kubernetes Service (EKS) is one of the most widely adopted managed Kubernetes solutions in production environments today. But reading the documentation only gets you so far — the real learning happens when you deploy something end-to-end.

In this guide, we’ll walk through deploying the classic 2048 game on AWS EKS using Fargate. By the end, you’ll have a publicly accessible application running on a fully managed Kubernetes cluster, with an Application Load Balancer (ALB) routing traffic to it.

This isn’t just about the game. It’s about understanding the full deployment lifecycle: cluster provisioning, networking, IAM, OIDC authentication, and ingress configuration — all the things that matter in real-world cloud-native infrastructure.

What You’ll Build

• An EKS cluster running on AWS Fargate (serverless compute for Kubernetes)
• A properly configured VPC with security groups and an Internet Gateway
• An OIDC identity provider for secure IAM integration
• An AWS Load Balancer Controller (ALB) for managing ingress
• The 2048 game exposed publicly via an ALB Ingress

Prerequisites

Make sure the following tools are installed and configured before you begin:

kubectl — The CLI for interacting with Kubernetes clusters. → Install Guide

eksctl — A CLI that simplifies creating and managing EKS clusters. → Install Guide

AWS CLI — Required for interacting with AWS services and authenticating with EKS. → Install Guide

After installing the AWS CLI, configure it with:

aws configure

You’ll be prompted for your Access Key ID, Secret Access Key, default region, and output format. Use the credentials of an IAM user with sufficient permissions (or an admin user for learning purposes).

Step 1: Setting Up Your AWS Environment

1.1 Create an IAM User

If you haven’t already:

1. Go to the IAM service in the AWS Console
2. Click Users → Add user
3. Select Programmatic access
4. Attach the necessary policies (for this project, AdministratorAccess works for learning; scope it down for production)
5. Save the Access Key ID and Secret Access Key securely.

1.2 Set Up the VPC and Networking

EKS requires a properly configured VPC. When creating your cluster with eksctl, a VPC is provisioned automatically. However, understanding what gets created is important:

• Public and private subnets across multiple availability zones
• An Internet Gateway (IGW) to allow worker nodes to pull container images from external registries
• Route tables updated to route 0.0.0.0/0 traffic through the IGW
• Security groups controlling inbound/outbound traffic to your nodes

For production clusters, you’d configure private subnets for worker nodes and restrict inbound access carefully. For this walkthrough, the auto-generated VPC is sufficient.

1.3 Configure IAM Policies

Your EKS worker nodes (or Fargate pods) need IAM permissions to interact with AWS services — pulling images from ECR, writing logs to CloudWatch, and more. These permissions are granted via IAM roles attached to the node group or Fargate profile.

Step 2: Create the EKS Cluster

With your environment set up, create the cluster using Fargate:

eksctl create cluster --name demo-cluster --region <region-name>--fargate

This single command:

• Provisions the EKS control plane
• Sets up the VPC, subnets, and security groups
• Creates a Fargate profile for the default namespace
• Configures your local kubeconfig to point to the new cluster

Once complete, verify your cluster is accessible:

kubectl get nodes

What to keep in mind: EKS with Fargate means there are no EC2 worker nodes to manage. Each pod runs in its own isolated compute environment. This simplifies operations but means you can’t use DaemonSets or node-level configurations the same way.

Step 3: Configure the OIDC Identity Provider

To allow Kubernetes service accounts to assume IAM roles (required for the ALB controller), you need an OIDC (OpenID Connect) provider associated with your cluster.

First, retrieve your cluster’s OIDC issuer ID:

export cluster_name=demo-cluster

oidc_id=$(aws eks describe-cluster --name $cluster_name \
  --query "cluster.identity.oidc.issuer" \
  --output text | cut -d '/' -f 5)

Check if an OIDC provider is already configured:

aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4

If nothing is returned, associate one:

eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve

Why this matters: Without OIDC, Kubernetes service accounts cannot assume IAM roles. The ALB controller — and many other AWS-integrated tools — depend on this mechanism (called IRSA: IAM Roles for Service Accounts).

Step 4: Install the AWS Load Balancer Controller

The AWS Load Balancer Controller manages ALBs and NLBs for your Kubernetes services and ingresses. Setting it up involves three parts: an IAM policy, an IAM role via a service account, and a Helm deployment.

4.1 Download and Create the 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

4.2 Create the IAM Service Account

eksctl create iamserviceaccount \
  --cluster=<your-cluster-name> \
  --namespace=kube-system \
  --name=aws-load-balancer-controller \
  --role-name AmazonEKSLoadBalancerControllerRole \
  --attach-policy-arn=arn:aws:iam::<your-aws-account-id>:policy/AWSLoadBalancerControllerIAMPolicy \
  --approve

Replace <your-cluster-name> and <your-aws-account-id> with your actual values.

4.3 Deploy via Helm

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

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=<your-cluster-name> \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  --set region=<your-region> \
  --set vpcId=<your-vpc-id>

Verify the controller is running:

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

You should see 2/2 pods ready.

Common pitfall: If the controller fails to start, double-check that the OIDC provider was correctly associated and that the IAM policy ARN in the service account creation command matches exactly.

Step 5: Deploy the 2048 Game

5.1 Create a Fargate Profile for the App

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

This tells EKS to run any pods in the game-2048 namespace on Fargate.

5.2 Deploy the Application

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

This single manifest creates:

• A Deployment — runs the 2048 game container
• A Service — exposes the deployment internally within the cluster
• An Ingress — triggers the ALB controller to provision a public-facing ALB

5.3 Get the Public URL

kubectl get ingress -n game-2048

Look for the ADDRESS field — this is the ALB DNS name. It may take a minute or two to provision. Paste it in your browser and the 2048 game should load.

Key Things to Keep in Mind

Cost awareness: EKS clusters are not free. The control plane costs ~$0.10/hour. Fargate charges per vCPU and memory per second. Always delete your cluster when done with testing:

eksctl delete cluster --name demo-cluster --region <region-name>

IAM is everything: Most issues in EKS deployments come down to IAM — missing permissions, wrong role associations, or OIDC not being set up. When something doesn’t work, check CloudTrail and the pod logs first.

Fargate limitations: Fargate doesn’t support DaemonSets, privileged containers, or host networking. If your workload requires any of these, you’ll need a managed node group instead.

Namespace-Fargate binding: Fargate profiles are tied to namespaces. If you deploy a pod to a namespace without a matching Fargate profile, it will remain in a Pending state indefinitely.

ALB provisioning time: After applying the ingress manifest, the ALB can take 3–5 minutes to fully provision and become reachable. Don’t panic if the URL doesn’t load immediately.

Deployed App

Conclusion

Deploying the 2048 game on EKS might seem like a small project, but it touches nearly every foundational concept in cloud-native infrastructure: cluster provisioning, IAM and OIDC, networking, load balancing, and Kubernetes-native ingress. These are the same building blocks used to deploy real production workloads at scale.

You can view the project files on — Github

(ps: I too am learning rn , so i thought before reaching the self managed kubernetes, i’ll look through AWS managed one. Ngl commands are bit complex as a first time 😭😭😭. But gotta keep learning!!!!)