DEV Community: Omar Fathy

AWS VPC Lattice: Simplifying Application Networking 🚀

Omar Fathy — Wed, 24 Dec 2025 17:42:22 +0000

The Networking Challenge We've All Faced 😤

Let's be honest networking in AWS has never been the most friendly experience for anyone. When you're trying to connect microservices across different VPCs, you quickly find yourself dealing with VPC peering configurations, complex route tables, and security groups that seem to multiply overnight. And that's before you even taking about cross-account service discovery nightmare.

Remember when you had to manually configure every single connection between your services? When you had to remember which VPC CIDR blocks were available and pray you didn't have overlapping ranges? When you had to babysit your service mesh configuration like it was a newborn that couldn't sleep through the night?

those were the good old days.

challings: The Pain Points

Let's talk about real challings :

VPC Peering Complexity: Setting up peering connections between multiple VPCs is like playing a big puzzel game.
Service Discovery Headache: Your services can't find each other because they're across different VPCs.
Security Group Management: Managing security groups across VPCs quickly turns into a headache, too many rules, too many places to update them, and every change feels like it breaks something else.
Load Balancing Overhead: Every service needs its own load balancer, and before you know it, your AWS bill goes skyhigh.
Cross-Account Complexity: When your services live in different AWS accounts.
Overlapping CIDR Ranges: Most of us uses 10.0.0.0/16 we all thought it was a great idea
IPv4/IPv6 Migration Headaches: that maybe one of the logest task you can get to try to migrate services one by one without breaking everything

Enter VPC Lattice: The Solution We've Been Waiting For And then magic happens.

AWS VPC Lattice is essentially AWS saying, "Hey, we know you're tired of this networking nonsense. Let us handle it for you." It's like having a networking expert with your team.

VPC Lattice is a fully managed service mesh that lets you connect, secure, and monitor communication between your applications across multiple VPCs and AWS accounts. Think of it as the universal translator for your microservices except instead of translating between Klingon and English, it's translating between different VPCs, accounts, and even IPv4/IPv6 protocols.

How VPC Lattice Works: The Four Building Blocks

VPC Lattice has four main components:

1. Services: Your Applications in Disguise

A service in VPC Lattice is a logical abstraction of your application. Instead of dealing with IP addresses and ports, you get a friendly DNS name like billing.app.com.

The service consists of:

Listeners: The protocol and port (HTTP, HTTPS, or gRPC)
Rules: Traffic routing decisions based on path, headers, or HTTP methods
Target Groups: Your actual backend services (EC2, ECS, Lambda, or ALB)

The beauty of this approach is that you will be able to give weight to your targets your traffic routing 90% of that could be sent to Target group one and another 10% could trigger a Lambda function in Target group that is very useful because it helps you with your blue-green deployments. Your clients never know the difference because they're still hitting the same service name.

2. Service Networks: The Club for Your Services

Service networks are like exclusive clubs where your services hang out. You create one, put your services in it, and then associate it with your consumer VPCs.

But here's the important part: just because services are in the same network doesn't mean they can talk to each other. You still need to explicitly allow that through authorization policies.

3. Authorization Policies: The Bouncer at the Door

This is where VPC Lattice gets really clever. authorization policies can be applied on both levels service network level (coarse-grained) and individual service level (fine-grained) It's like having a two checking point

The policies are IAM resource policies (similar to S3 bucket policies), so if you're already familiar with AWS IAM, you're golden. You can specify who can access what based on:

The caller's identity
Source VPC
Service network
HTTP headers, query strings, or methods

Here's an example of a service network authorization policy:

{
  "Sid": "AllowMyPrincipals",
  "Effect": "Allow",
  "Principal": "*",
  "Action": "vpc-lattice-svcs:Invoke",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalOrgId": "o-example"
    }
  }
}

4. Service Directory: The Phone Book for Your Services 📞

This is your one-stop shop to see all the services you have access to. Developers can come here to get service names, and administrators can audit what services their account can reach. Simple but effective.

The Real Magic: How Traffic Actually Flows

Here's where it gets interesting. When your inventory app in VPC1 wants to talk to your billing app in VPC3:

DNS Resolution: Your app looks up billing.app.com
Route 53 Response: Returns a link-local IP address (169.254.x.x for IPv4, fc00::/7 for IPv6)
VPC Lattice Proxy: Traffic hits the VPC Lattice proxy (which handles all the NAT magic)
Authorization Check: Service network and service policies are evaluated
Traffic Management: Rules are applied, and traffic is routed to the appropriate target
Target Delivery: Traffic reaches your actual service from another link-local IP

The genius of this approach is that your source (10.0.0.7) and destination (also 10.0.0.7) can have overlapping IP ranges, and VPC Lattice handles all the translation. No more CIDR conflicts!

Why VPC Lattice is a Game-Changer

VPC Lattice eliminates the need for manual networking configuration. You can forget about setting up VPC peering, managing route tables, or configuring security groups - AWS handles all of that complexity behind the scenes.

Load balancing becomes automatic with VPC Lattice. Each service gets load balancing capabilities without requiring separate ALBs or NLBs. It's built right into the service definition.

Cross-account communication becomes seamless. Your services can communicate across different AWS accounts without complex setup or configuration overhead.

The observability features are comprehensive. You get metrics, logs, and traces out of the box, giving you full visibility into service communication patterns.

Security is integrated from the start. IAM-based authentication and authorization are built into the service, so security isn't an afterthought.

IPv4/IPv6 migration becomes much simpler. You can migrate services independently without breaking existing connections or disrupting your infrastructure.

Every request carries rich metadata about the caller, source VPC, and routing information. This detailed context is incredibly valuable for debugging, monitoring, and understanding your service interactions.

When to Use VPC Lattice

VPC Lattice works best in specific scenarios. If you're dealing with microservices spread across multiple VPCs, this service can significantly simplify your networking setup.

Multi-account environments benefit greatly from VPC Lattice. When your infrastructure spans multiple AWS accounts, the service handles the complexity of cross-account communication automatically.

For teams exploring service mesh technologies, VPC Lattice provides AWS's native approach to service mesh functionality without the complexity of third-party solutions.

The service is particularly useful during IPv6 migrations. You can migrate services gradually without disrupting your entire infrastructure.

Overlapping CIDR ranges become manageable with VPC Lattice. This is a common problem that many organizations face, and VPC Lattice handles it elegantly.

However, for simple single-VPC applications with just a few services, VPC Lattice might be unnecessary complexity. Sometimes the simplest solution is the right one.

The Catch

As with any technology, there are trade-offs to consider with VPC Lattice.

Pricing is the first consideration. You'll pay for data processing and requests, so you'll want to factor this into your cost analysis when planning your implementation.

There's a learning curve involved. If your team is deeply familiar with traditional VPC networking, they'll need time to understand the service mesh paradigm and how VPC Lattice differs from conventional approaches.

Vendor lock-in is another factor. Since this is AWS-specific, if you're planning a multi-cloud strategy, you'll need to consider alternative approaches for other cloud providers.

Network association has some limitations. Each consumer VPC can only be associated with one service network, though individual services can participate in multiple networks.

That said, when you factor in the time savings and reduced operational overhead, the benefits typically outweigh these considerations. Your engineering time is valuable, and VPC Lattice can save significant amounts of it.

Getting Started: The Practical Stuff 🛠️

Want to try this out? Here's how:

Create a Service Network: Start with the foundation
Define Your Services: Register your applications
Set Up Authorization: Configure who can access what
Associate VPCs: Connect your consumer VPCs
Test and Iterate: Start small, then scale

AWS has an online guided workshop that takes you through multiple labs. It's highly recommended if you want to see this in action:

Wrapping everything Up

So there you have it AWS VPC Lattice in all its glory. It's not perfect, but it's pretty close to what we've all been wishing for.

If you're tired of managing complex VPC peering configurations, if you're sick of manually configuring load balancers for every service, if you're ready to stop babysitting your service discovery setup—give VPC Lattice a shot.

It might just be the networking solution that finally lets you focus on building features instead of fighting with infrastructure. And honestly? That's what we all really want, isn't it?

Now go forth and build something awesome. Your services will thank you. ✨

Resources

Getting Started

Documentation & Whitepapers

Building Scalable, Secure Multi-VPC Network Infrastructure

AWS Blog Posts

AWS S3 Vectors: Finally, Cloud Scalable Vector Storage 🚀

Omar Fathy — Tue, 16 Dec 2025 00:40:07 +0000

Been building AI applications lately? You've probably felt the pain of vector embedding storage. Vector databases are powerful, yeah but expensive and a hassle to work with. Surprise. AWS just launched something that can save you up to 90% on vector storage.

Let me introduce you to Amazon S3 Vectors.

What Are We Discussing Here?

Let's get our feet wet in the fundamentals before jumping into S3 Vectors. In case you already store vectors in Pinecone, Weaviate, or have your own vector database, you're already aware that vectors are numeric encodings of your data text, images, audio, etc. They encode semantic meaning so you can retrieve similar things, drive RAG applications, or grant your AI agents some memory.

The problem? Traditional vector databases are:

💸 Expensive at scale (especially when you're storing millions or billions of vectors)
🔧 Complex to maintain and provision
📊 Often overkill if you're not querying constantly

Say hello to S3 Vectors the first cloud object store with native vector support. It's similar to Amazon S3, but optimized for vectors. You get the legendary reliability and scalability of S3, with the capability to actually query your vectors in sub-second performance.

Why Should You Care? 🤔

Let's be realistic: we don't all need millisecond query times for all vectors in our system. Sure, your recommendation engine has to be super fast, but what about:

📚 Long-term conversation history for your AI agents
🗂️ Archive data that you query occasionally
📈 Training datasets that grow over time
🔍 Semantic search across millions of documents that don't need real time response

This is where S3 Vectors shines. Pay only for what you use, no infrastructure to provision whatsoever, and scale from thousands to billions of vectors without breaking a sweat (or your bank).

The Architecture: How It Actually Works

S3 Vectors introduces three core concepts:

1. Vector Buckets 🪣

A new type of S3 bucket specifically designed for vector data. Not your regular S3 bucket this one is designed for vectors from ground up.

2. Vector Indexes 📑

Inside each vector bucket, you create indexes to hold and organize your vectors. Each bucket supports up to 10,000 indexes and each index can hold tens of millions of vectors. Indexes are groups that bunch related vectors together.

3. Vectors (Clearly) ⚡

Your actual vector embeddings live here. And the best news? You can attach metadata as key-value pairs to each vector. Need to filter on date, category, user preference, or genre? No problem. S3 Vectors will automatically optimize your data as it evolves no manual fiddling required.

Strong Consistency FTW

Here's the key bit: writes are strongly consistent. When you add or update a vector, it's immediately available for queries. No eventual consistency angst.

Let's Get Practical: Code That Actually Works 💻

I know you're itching to see some code, so let's walk through a real example. Say you're building a movie recommendation system (because every tutorial needs movies, right? 🎬).

Step 1: Generate Embeddings with Amazon Bedrock

import boto3 
import json 

# Set up Bedrock client
bedrock = boto3.client("bedrock-runtime", region_name="us-west-2") 

# Your movie descriptions
texts = [
    "Star Wars: A farm boy joins rebels to fight an evil empire in space", 
    "Jurassic Park: Scientists create dinosaurs in a theme park that goes wrong",
    "Finding Nemo: A father fish searches the ocean to find his lost son"
]

embeddings = []

# Getting embeddings for each movie
for text in texts:
    body = json.dumps({"inputText": text})

    response = bedrock.invoke_model(
        modelId='amazon.titan-embed-text-v2:0',
        body=body
    )

    response_body = json.loads(response['body'].read())
    embedding = response_body['embedding']
    embeddings.append(embedding)

Step 2: Store Vectors in S3 Vectors

# Create S3 Vectors client
s3vectors = boto3.client('s3vectors', region_name='us-west-2')

# Insert your vectors with metadata
s3vectors.put_vectors(
    vectorBucketName="my-movie-vectors",
    indexName="movie-embeddings", 
    vectors=[
        {
            "key": "v1", 
            "data": {"float32": embeddings[0]}, 
            "metadata": {
                "id": "key1", 
                "source_text": texts[0], 
                "genre": "scifi"
            }
        },
        {
            "key": "v2", 
            "data": {"float32": embeddings[1]}, 
            "metadata": {
                "id": "key2", 
                "source_text": texts[1], 
                "genre": "scifi"
            }
        },
        {
            "key": "v3", 
            "data": {"float32": embeddings[2]}, 
            "metadata": {
                "id": "key3", 
                "source_text": texts[2], 
                "genre": "family"
            }
        }
    ]
)

Step 3: Query Your Vectors

# User asks: "List movies about adventures in space"
input_text = "List the movies about adventures in space"

# Create embedding for the query
request = json.dumps({"inputText": input_text})
response = bedrock.invoke_model(
    modelId="amazon.titan-embed-text-v2:0", 
    body=request
)

model_response = json.loads(response["body"].read())
query_embedding = model_response["embedding"]

# Do similarity search with metadata filtering
query = s3vectors.query_vectors(
    vectorBucketName="my-movie-vectors",
    indexName="movie-embeddings",
    queryVector={"float32": query_embedding},
    topK=3, 
    filter={"genre": "scifi"},  # Only search sci-fi movies
    returnDistance=True,
    returnMetadata=True
)

results = query["vectors"]
print(results)  # Star Wars will be your top match!

The Integration Story: Playing Nice with Others 🔗

S3 Vectors is not an isolated island. AWS made sure it plays nice with other tools you may already have on board:

Amazon Bedrock Knowledge Bases 🧠

Create knowledge bases for RAG applications natively with S3 Vectors as your storage layer. Cut costs without sacrificing functionality.

Amazon OpenSearch Service 🔍

And now things get interesting: use a tiered storage approach. Store your low-frequency, long-term vectors in S3 Vectors (cheap), and scale up to OpenSearch for high-priority vectors when you need that high-QPS, low-latency performance.

Picture it like this:

S3 Vectors: Your budget-savior data warehouse for vectors
OpenSearch: Your high-performance query engine

You can even export S3 vector index snapshots directly to OpenSearch Serverless collections from the console. Best of both worlds.

Amazon SageMaker Unified Studio 🎨

Build and prototype your generative AI workloads with native access to Bedrock and S3 Vectors in one integrated studio.

When Should You Actually Use This? 🎯

Use S3 Vectors if:

✅ You need to persist large vector datasets (millions to billions)
✅ Query rate is not thousands of QPS
✅ Cost is a primary concern
✅ You need sub-second query latency (not microsecond)
✅ You don't want to worry about infrastructure
✅ You need strong consistency guarantees

Stick with traditional vector databases if:

❌ You need ultra-low latency (single-digit milliseconds)
❌ You're servicing high-QPS real-time applications
❌ You need advanced features like hybrid search or complex aggregations
❌ Your vectors are frequently updated and queried simultaneously

The Nitty-Gritty Details 🔧

Some important specs to keep in mind:

Supported distance metrics: Cosine and Euclidean
Metadata types: String, number, boolean, and lists
Metadata filtering: All metadata is filterable out of the box
Encryption: SSE-S3 by default, or bring your own KMS keys
Access control: Default IAM policies (with a separate s3vectors namespace)
Block Public Access: Always enabled (can't be disabled)
Currently available in: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), and Asia Pacific (Sydney)

Getting Started (It's Easier Than You Think) ⚡

Via Console:

Navigate to S3 → Vector Buckets
Click "Create vector bucket"
Create a vector index (specify dimensionality and distance metric)
Start inserting vectors via SDK, CLI, or API

Via Code:
Just use the boto3 S3 Vectors client as shown in the examples above—it's that straightforward.

Pro tip: Check out the S3 Vectors Embed CLI on GitHub. It lets you create embeddings and store them in S3 Vectors with single commands. Super handy for testing and quick prototypes.

Resources & Further Reading 📚

Kubernetes Auto-Scaling with Karpenter: The Smart Way to Scale on AWS EKS 🚀

Omar Fathy — Tue, 09 Dec 2025 00:55:20 +0000

We've all been there. You've got your Kubernetes app humming along nicely on EKS, and then it happens. A sudden traffic surge leaves your pods hanging in Pending because you're out of nodes. Or maybe it's the opposite, and you're staring at your AWS bill wondering why you're paying for a ghost town of idle instances.

You might be using the usual suspects HPA and the Cluster Autoscaler. They're okay, I guess. But HPA is obsessed with just CPU and memory, which is like trying to drive a car by only looking at the speedometer. And the Cluster Autoscaler? It moves at a glacial pace and doesn't give you much say in the new machines it spins up. As for scaling by hand... let's not even go there.

What if I told you there's a better way to handle this? A way to let your cluster manage itself, intelligently. That's where two amazing tools, KEDA and Karpenter, come into the picture.

Why Traditional Auto Scaling Doesn't Work

Think about it: what happens when scaling isn't about CPU, but about something real? Like a mountain of messages piling up in your SQS queue, or a sudden flood of API calls? Your standard tools just shrug. They weren't built for that kind of real-world event.

Meet KEDA: Your Application's New Best Friend

KEDA is all about making your applications scale based on events. It connects to all sorts of things—Kafka, RabbitMQ, AWS SQS, you name it—and watches for signs of work piling up.

So how does it work? You create a simple resource called a ScaledObject in Kubernetes. This little YAML file tells KEDA a few things: which app (Deployment) to watch, and what Trigger to look for. That trigger could be "scale up if my SQS queue has more than 10 messages." Behind the scenes, KEDA's operator does the math and feeds these custom metrics to the normal Kubernetes HPA, telling it when to add or remove pods. It's a super clever way to make your scaling truly reflect your application's needs, not just its resource usage.

KEDA is a champ at scaling your pods up and down. But that's only half the battle. What if KEDA wants to spin up a bunch of pods, but you're out of nodes? All those new pods just get stuck in that dreaded Pending state. That's the exact gap Karpenter fills.

Karpenter, an open-source autoscaler from AWS, is all about getting you the right nodes at the right time. It watches for those stranded pods and jumps in to provision or decommission EC2 instances based on what your cluster actually needs, right now.

Key Features That Make Karpenter Awesome

Speed, for one. It bypasses a lot of the usual Kubernetes layers and talks straight to the AWS EC2 API, which means it can have a new node ready for you in the time it takes to grab a coffee. But it's not just fast; it's clever. It looks at the pods that are waiting and plays a game of Tetris to find the most cost effective EC2 instance that fits them perfectly. No more paying for oversized nodes!

And when the traffic dies down, Karpenter turns into a neat freak. It'll gracefully shuffle your pods onto fewer nodes and get rid of the empty ones, which is a beautiful thing for your cloud bill. Since it’s an AWS native tool, all the IAM stuff just works without a headache. You just tell it the rules of the playground what instance types are fair game, which zones to play in using a NodePool, and its controller takes care of everything else.

The Dream Team: KEDA + Karpenter

This KEDA and Karpenter combo is the real dream team. Think of KEDA as the brains of the operation the lookout in the crow's nest who spots the approaching wave of work and yells, "More hands on deck!" Then you've got Karpenter as the muscle, the one who instantly builds out the extra deck space (the new nodes) just in time for the new crew (the pods) to get to work. It’s this beautiful, symbiotic relationship that creates a truly elastic infrastructure. Your cluster just expands and contracts exactly when it needs to, without you lifting a finger.

Ready to Give it a Shot?

Getting KEDA and Karpenter set up on your EKS cluster does take a little bit of work upfront, but believe me, the time you'll save later is massive. The official docs are your best friend here, since they'll always have the latest and greatest steps.

Installing Karpenter on AWS EKS

Follow these steps to install Karpenter as outlined in the official guide:

Installing KEDA on AWS EKS

Follow these steps to install KEDA on AWS EKS using the official guide:

Installing Redis

Install Redis using Helm:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

helm install redis bitnami/redis --namespace redis --create-namespace \
  --set auth.enabled=false

This puts Redis in the redis namespace without authentication, perfect for testing.

Creating Your First Auto Scaling Workload

Let's build a sample workload that demonstrates KEDA and Karpenter working together.

Deploying a Worker Application

Create a file called scaledobject.yaml:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: redisconsumer
spec:
  scaleTargetRef:
    name: worker
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: redis
      metadata:
        address: redis-master.default.svc.cluster.local:6379
        listName: jobs
        listLength: "5"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: worker
spec:
  replicas: 0
  selector:
    matchLabels:
      app: worker
  template:
    metadata:
      labels:
        app: worker
    spec:
      containers:
        - name: worker
          image: busybox
          command: ["sh", "-c", "while true; do sleep 10; done"]
          resources:
            requests:
              memory: "250Mi"
              cpu: "1000m"
            limits:
              memory: "250Mi"
              cpu: "1000m"

Apply this configuration:

kubectl apply -f scaledobject.yaml

This setup creates a deployment named worker and a ScaledObject that monitors a Redis list called jobs. KEDA will automatically scale the worker pods based on the length of this list.

Testing Your Auto Scaling Setup

Now it's time to see your auto scaling infrastructure in action.

Step 1: Connect to Redis

First, connect to your Redis instance:

kubectl exec -it -n redis $(kubectl get pod -n redis -l app.kubernetes.io/name=redis -o jsonpath="{.items[0].metadata.name}") -- redis-cli

Step 2: Add Workload

Push some messages to the Redis list to simulate workload:

LPUSH jobs "task-1"
LPUSH jobs "task-2"
LPUSH jobs "task-3"
LPUSH jobs "task-4"
LPUSH jobs "task-5"
LPUSH jobs "task-6"

Step 3: Watch the Magic Happen

Monitor your pods scaling up:

kubectl get pods -l app=worker -w

(demo video)

So, what just happened behind the scenes? It started the moment you pushed items to the Redis list. KEDA's trigger saw the list growing and knew it needed more pods to handle the work. It told the Kubernetes HPA to scale up the worker deployment, which created new pod replicas. But with no room to run, those pods were just sitting there in Pending. That's when Karpenter stepped in. It saw the stranded pods, figured out exactly what kind of node they needed, and launched a new EC2 instance to join the cluster. Once the node was ready, Kubernetes scheduled the pods, and they got to work. A perfect, automated chain reaction.

A Few Tips for Going Live

When you're ready to take this into production, just keep a couple of things in mind. For KEDA, make sure you set sane min and max replica counts so your app doesn't disappear when idle or scale to the moon. And don't be afraid to combine a few different triggers to create some really smart scaling rules. On the Karpenter side of things, give it a good variety of instance types to choose from—flexibility is its superpower. Definitely turn on consolidation to let it clean up underused nodes and save you some cash. And why not let it use Spot instances for workloads that can handle interruptions? It's a great way to slash your EC2 bill.

The Benefits You'll Get

So, what do you get out of all this? For your operations team, it means less babysitting. You're not manually managing nodes or tweaking replica counts anymore. This leads to a more reliable system, because your apps can handle sudden traffic spikes without falling over. From a cost perspective, you're only paying for what you use. Karpenter's ability to consolidate nodes and use spot instances means you're not over-provisioning for worst-case scenarios. And finally, the performance boost is real. Your apps respond faster to actual business needs, not just CPU load, leading to a much better experience for your users.

Resources

Getting Started

AWS ECS Managed Instances: The Middle Ground We've Been Waiting For

Omar Fathy — Thu, 27 Nov 2025 12:13:20 +0000

AWS ECS Managed Instances: The Middle Ground We've Been Waiting For

If you've been operating containerized workloads on AWS, you've probably grappled with a known trade-off. Use Fargate and enjoy hands-off simplicity, but it costs more and you give up control of your compute. Or manage your own EC2 fleet on ECS, enjoy complete hardware control and better costs, but now you're patching instances, configuring auto-scaling groups, and managing launch templates.

It's a problem that has baffled engineers for decades. But AWS just came out with something that might finally bridge the gap: ECS Managed Instances.

The Container Management Balancing Act

Let's be practical here with container orchestration. Not many teams wake up excited about managing infrastructure. They'd rather deploy features, not troubleshoot why a node consumed all its disk space at 2 AM or why their auto-scaling group went and spawned instances in the wrong availability zone.

Fargate cut out all of this by being serverless. You define your work, you deploy, and AWS handles all the rest behind the scenes. No instances to manage, no capacity planning, no patching cycles. It's untainted.

There's always a catch, however.

What if you use GPUs for machine learning inference as part of your workload? What if processing the data requires high-throughput networking? What happens if you have a database workload that requires quick access to local NVMe storage? Fargate is unable to assist with those. Now that you're working with EC2 instances independently once more, you're also handling all of their accessories.

Additionally, the expense can be high even if you don't require specialized hardware. Fargate charges more for that convenience, and the math becomes less appealing when you're managing hundreds or even thousands of containers around the clock. You can divide the cost across workloads by bin-packing several containers onto a single instance using EC2-backed clusters. That efficiency builds up.

Enter ECS Managed Instances 🚀

ECS Managed Instances is in the center of that serverless spectrum. Imagine AWS saying, "All right, we'll take care of your EC2 fleet, but you still get to pick the hardware."

In actuality, it appears like this:

You still specify instance requirements. Do you require GPU acceleration? Do you require specific CPU architectures like Graviton? Do you require specific instance families for network performance? You can specify those characteristics, and ECS will select among compatible instance types. Or you can let AWS automatically select the most cost-effective ones.

AWS does everything operationally for you. Provisioning, scaling, security updates, instance refreshes—it's all handled. No more needing to keep launch templates current or deciding on auto-scaling policies. AWS patches instances automatically every 14 days or so, and if you have to avoid interruptions during busy times of day, you can use EC2 event windows to plan maintenance.

The provisioned compute? It's the same old EC2 instances within your cluster. That means you can have multiple containers per instance, use daemon tasks for collecting logs and other such things, and privilege containers where needed. All of the things Fargate doesn't enable.

What Makes This Different

Let's step through why this matters:

Operational Simplicity Without Compromise

You're not giving up control to get convenience. You can still specify GPU instances for ML workloads, choose Graviton processors for ARM workloads, or choose instance types with local low-latency storage. AWS just handles the drudgery of the operational specifics.

Cost Efficiency That Scales

There's an additional management fee on top of EC2 prices—roughly 3% overhead—but you're still coming out ahead of Fargate in most scenarios. More importantly, your existing EC2 savings plans and reserved instances carry over to the underlying compute. For organizations already invested in those, that's a huge win.

And because ECS is able to bin-pack more than one task into a single instance, you're using resources more efficiently. The service also maximizes placement constantly, combining workloads and auto-shutting down idle instances.

Security by Default

Managed Instances are powered by Bottlerocket, AWS's container-native operating system. It's lightweight, hardened, and container-optimized. Coupled with automated patching every 14 days, you have a security posture that's easier to handle than rolling your own.

Seamless AWS Integration

It's not an afterthought add-on service tacked on to ECS. It's a first-class launch type that integrates with the rest of your AWS stack. VPCs, security groups, IAM roles, CloudWatch metrics—everything just works the way you'd expect.

When Should You Use This? 💡

Let's talk about real-world examples.

You require specialized hardware. Running GPU-accelerated workloads for rendering or ML? Processing high-bandwidth streams of data? ECS Managed Instances enables you to obtain the specialized hardware without ops overhead.

You're optimizing for cost at scale. If you've got a big container workload and Fargate prices are eating away at your budget, Managed Instances can reduce that expense without diminishing ease of operation. That you're able to leverage current EC2 savings plans makes it all the more compelling.

You need daemon tasks or privileged containers. Fargate doesn't support them. If your design relies on background work that runs on every host, or you need privileged permissions for certain operations, you'll need EC2-backed clusters. Managed Instances gives you that without the management burden.

You want to reduce management overhead. If you're already using self-managed EC2 instances in ECS and fed up with patching, capacity planning, and instance lifecycle management, this is an obvious upgrade path. You retain your flexibility but pass on the operational effort.

The Tradeoffs You Should Know

There is no free lunch, so let's be realistic about the tradeoffs.

The management fee is not free. It's a small percentage, but it's always billed at on-demand rates, even though the underlying EC2 instances get to benefit from savings plans. For some workloads, that might tip the economics in support of self-managed infrastructure.

You also don't get quite the same "fire and forget" as Fargate. AWS certainly does a lot of the heavy lifting, but you're still setting instance attributes and being aware of the compute underneath. It's less work than doing EC2 straight out, but it's not no brain.

And right now, it's not available in many places. It's offered in US East, US West, Europe (Ireland), Africa (Cape Town), and select Asia Pacific regions. If you're in Frankfurt or elsewhere, you'll be waiting.

Getting Started

If you've already got ECS set up and running, it's simple to experiment with this. In setting up a new cluster, there will be "Managed Instances" as an option to accompany Fargate and EC2. You can choose "Use ECS default" to let AWS pick up-to-date instance types, or use "Use custom – advanced" to specify particular properties like CPU architecture, memory, or GPU requirements.

You can do this behind the scenes as well with CloudFormation, CDK, or the AWS CLI. Infrastructure-as-code support came out of the box on day one, which is wonderful.

The Bigger Picture ✨

ECS Managed Instances appears to be AWS acknowledging that there indeed was a gap in their container product offerings. Fargate is great at what it does, but it's not the fix for every workload. EC2 offers control, but with operational overhead as the cost. This new option gives a middle ground that many teams will find genuinely useful.

It's also within a broader trend. AWS is moving towards more managed experiences in general—EKS Auto Mode, managed node groups, services that handle the undifferentiated heavy lifting for you but give you the knobs that you actually care about. ECS Managed Instances fits squarely into that trend.

If you've been running containers with ECS, this is something you might want to consider. Whether it's valuable depends on your own workload, cost structure, and way of working. But for those who desire the elasticity of EC2 without the management burden, this could be the answer you've been waiting for.

Ready to give it a try? Take a look at the official documentation and launch a test cluster. The best way to determine if it meets your requirements is to deploy your actual workloads and observe how it runs.

Pod Identity: The Authentication Revolution Kubernetes Needed 🔐

Omar Fathy — Sun, 12 Oct 2025 23:18:26 +0000

🤔 What About it?

So AWS just dropped Pod Identity for EKS, and honestly? It's about damn time. 💯 We've been dealing with authentication headaches in Kubernetes for years - hardcoded secrets, complex OIDC setups, and the constant battle between security and simplicity.

Pod Identity is basically AWS saying "enough is enough" and giving us a way to handle authentication that actually makes sense. No more fighting with OIDC providers or managing a million different service accounts. Just clean, simple, secure authentication that works.

😤 The Problems Pod Identity Actually Solves

Let's be real - the old ways of handling authentication in Kubernetes were a mess. We've all been there:

The Hardcoded Credentials Mess 🔑

Remember when we used to put AWS credentials in environment variables or config files? Yeah, that was a security nightmare waiting to happen. One leaked credential and your entire infrastructure is toast.

The Kubernetes Secrets Problem 🤹‍♂️

Kubernetes secrets seemed like a good idea at first, but they're just base64 encoded. It looks secure but anyone can get in. Plus, managing them across multiple clusters is a pain.

The IRSA Complexity Overload 🧠

IAM Roles for Service Accounts (IRSA) was supposed to be the solution, but it came with its own baggage:

OIDC providers for every cluster (because apparently we needed more complexity)
Trust policies that look like they were written by a lawyer
Cross-cluster management that makes your head spin

✨ How Pod Identity Changes Everything

Here's where things get interesting. 🤯 Instead of the old approach where every cluster needs its own OIDC setup, Pod Identity uses a single IAM principal (pods.eks.amazonaws.com) that works across all your clusters.

🎭 The Magic Behind the Scenes

So here's how this actually works:

You create an IAM role → Give it the permissions your pods need ⚡
You map it to a service account → Tell EKS "this role belongs to this service account" 🎯
You deploy your pod → Use that service account, and magic happens ✨
AWS handles the rest → The Pod Identity Agent gives your pod temporary credentials automatically 🔄

It's basically AWS doing all the heavy lifting for you. No more messing around with OIDC providers or trying to figure out complex trust relationships.

🆚 Pod Identity vs IRSA: The Real Talk

Look, IRSA isn't going anywhere - AWS isn't going to break existing stuff. But Pod Identity is definitely the future, and here's why:

What Pod Identity Does Better ✅

No OIDC providers - One less thing to manage and screw up
Cross-cluster reusability - Same IAM role works everywhere
Simpler trust policies - Just pods.eks.amazonaws.com, that's it
Better performance - Agent-based credential distribution instead of per-pod assumption
Cleaner separation of duties - EKS handles the identity stuff, IAM handles the permissions

When You Might Still Want IRSA 🤷‍♂️

Legacy applications - If it works, don't touch it
Complex OIDC requirements - Some enterprises have existing OIDC setups they can't change
Cross-account scenarios - Pod Identity is still catching up here

🛠️ How the Pod Identity Agent Actually Works

This is the cool part. The Pod Identity Agent runs on every node in your cluster and handles all the credential distribution. Here's what happens when you deploy a pod:

The Pod Gets Mutated 🧬

When EKS starts a pod that uses Pod Identity, it automatically adds these environment variables:

env:
- name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
  value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
- name: AWS_CONTAINER_CREDENTIALS_FULL_URI
  value: "http://169.254.170.23/v1/credentials"

Plus it mounts a volume with the authentication token. AWS handles all of this automatically - you don't have to do anything.

The Agent Does the Heavy Lifting 💪

The Pod Identity Agent on each node:

Sees the pod → Recognizes it needs credentials
Calls the EKS Auth API → Uses AssumeRoleForPodIdentity to get temporary credentials
Serves the credentials → Makes them available to the AWS SDK via HTTP
Handles rotation → Automatically refreshes credentials before they expire

The beauty is that your application code doesn't change at all. The AWS SDK just works with the default credential chain.

🔧 Hands-On: Actually Setting This Up

Alright, enough talking. Let's actually build something that works. 💪

Step 1: Enable Pod Identity (The Easy Part) 🎉

First, you need to install the Pod Identity Agent add-on. This is actually the easiest part:

Via AWS Console:

Go to your EKS cluster
Click on "Add-ons"
Find "EKS Pod Identity Agent" in the list
Click "Add" and wait for it to install

Via AWS CLI:

aws eks create-addon \
  --cluster-name your-cluster-name \
  --addon-name eks-pod-identity-agent \
  --region your-region

That's pretty much it. No complicated configuration, no OIDC setup, no headaches.

Step 2: Create an IAM Role (The Trust Policy Part) 🎯

This is where things get interesting. You create an IAM role with a trust policy that looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "eks:cluster-name": "your-cluster-name",
          "eks:namespace": "your-namespace",
          "eks:serviceaccount-name": "your-service-account"
        }
      }
    }
  ]
}

Notice how clean that looks? No OIDC provider ARN, no complex conditions, just straightforward "this role can be assumed by pods in this cluster/namespace/service account."

Step 3: Create the Association (The Magic Part) ✨

Now you tell EKS "this IAM role belongs to this service account":

Via AWS Console:

Go to your EKS cluster
Click on "Access" tab
Scroll down to "Pod Identity associations"
Click "Create Pod Identity association"
Select your IAM role, namespace, and service account

Via AWS CLI:

aws eks create-pod-identity-association \
  --cluster-name your-cluster-name \
  --namespace your-namespace \
  --service-account your-service-account \
  --role-arn arn:aws:iam::123456789012:role/your-pod-identity-role \
  --region your-region

Step 4: Deploy Your Test Pod

Now let's test this it. Create a simple pod that uses the service account:

apiVersion: v1
kind: Namespace
metadata:
  name: test-namespace
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-service-account
  namespace: test-namespace
---
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: test-namespace
spec:
  containers:
  - name: aws-cli
    image: amazon/aws-cli:latest
    command: ['sleep', '36000']
  serviceAccountName: test-service-account

Deploy it and test:

kubectl apply -f pod.yaml
kubectl exec -it test-pod -n test-namespace -- aws s3 ls

2025-07-06 20:39:47 test.txt
2025-07-06 20:40:08 README.md

If you see your S3 buckets, voilà! Pod Identity is working. 🎉

🤷‍♂️ The Reality Check (Because Nothing's Perfect)

Look, Pod Identity is great, but it's not perfect. It only works on EKS with Linux nodes (sorry Windows and Fargate users), and you're limited to 5,000 associations per cluster. Changes can take a few seconds to propagate, and you need network access to the Pod Identity Agent.

But honestly? These limitations are pretty minor compared to the benefits. The cross-cluster reusability alone is worth the trade-offs for most use cases.

🎯 Who Should Actually Use This?

If you're building new EKS clusters or dealing with authentication headaches in existing ones, Pod Identity is definitely worth a look. It's perfect for multi-cluster setups where you want the same IAM roles everywhere, and for teams that are tired of fighting with OIDC providers.

Existing IRSA setups can keep doing their thing - no need to break what's working. And if you're on Fargate, you'll have to wait a bit longer for support.

🚚 Migration Reality

Good news: Pod Identity works alongside IRSA, so you can migrate gradually 😅

Bad news: No automatic migration tool (because AWS loves manual work) 😞

The migration path is actually pretty straightforward:

Create Pod Identity associations for your service accounts
Test thoroughly - Make sure everything still works
Remove IRSA configurations - Clean up the old OIDC stuff
Monitor and celebrate - You're now using the future

🔒 Security Stuff That Actually Matters

Network Security 🌐

The Pod Identity Agent runs on port 80 and 2703 on the link-local address (169.254.170.23). You need to make sure your security groups allow this traffic.

Credential Isolation 🔐

Each pod only gets credentials for its associated IAM role. No more sharing credentials between pods.

Audit Trail 📝

It's a security best practice to always know who's assuming roles and what they're doing. So All Pod Identity operations are logged in CloudTrail, so you can see who's assuming what roles.

Least Privilege 🛡️

Since each service account gets its own IAM role, you can scope permissions down to exactly what each application needs.

🌍 Regional Availability

Pod Identity works in all AWS regions where EKS is supported. Multi-region setups work great too - each region needs its own EKS cluster and Pod Identity Agent, but you can share the same IAM roles across regions.

The only real limitation is that Fargate, Outposts, and EKS Anywhere aren't supported yet. But for standard EKS clusters, you're good to go.

🤷‍♂️ So, Should You Actually Use This?

Look, Pod Identity isn't some magic bullet that solves all your Kubernetes authentication problems. But it's definitely a step in the right direction.

If you're starting a new EKS cluster or dealing with authentication headaches in existing ones, Pod Identity is worth looking into. It's simpler, more secure, and easier to maintain than the alternatives.

The migration path is manageable, and the benefits are real. Plus, it's the direction AWS is heading, so you might as well get on board now.

🔗 Resources That Actually Help

Essential Documentation

Community Resources

AWS Blog: EKS Pod Identity Introduction
YouTube Tutorials
GitHub Examples

Amazon Aurora DSQL: The distributed Serverless Database

Omar Fathy — Wed, 20 Aug 2025 00:51:36 +0000

What's All the Hype About? 🤔

So AWS just dropped something that's got the database world talking Aurora DSQL. And honestly? The hype is real. We're talking about a database that "defies physics" according to some folks, and after digging into it, that's not just Vegas conference talk.

The Problem Aurora DSQL Solves

Let's be real traditional databases have this annoying habit of hitting walls. You know the drill: more connections come in, things start locking up, performance goes down the drain, and suddenly your app is crawling. It's like trying to funnel a river through a garden hose.

Software developers are expensive (and rightfully so), but they're spending way too much time dealing with:

Integration nightmares during deployment
Database scaling headaches
Infrastructure management that nobody actually wants to do
Picking the "right" database architecture upfront

How Aurora DSQL Changes Everything

Here's where it gets wild. Instead of the old-school approach where everyone fights for database resources, Aurora DSQL creates a micro VM for every single transaction. We're talking about VMs that use maybe 1/100th of a CPU basically Lambda-level efficiency.

The Magic Behind the Scenes 🪄

Each transaction gets its own isolated playground:

Your transaction starts → Gets its own mini database engine in a VM
You do your work → Completely isolated, no idea other transactions exist
Time to commit → The "adjudicator" checks if anyone else modified the same data
Success or retry → Either your changes go through, or you retry with exponential backoff

It's like having your own personal database for every operation. No locks, no waiting, no drama.

The Trade-offs (Because Nothing's Perfect)

The Good Stuff ✅

Actually unlimited scale for connections (not just marketing speak)
Zero infrastructure management - AWS handles literally everything
PostgreSQL compatible - use the same code you already have
99.99% availability (single region) / 99.999% (multi-region)
Active-active multi-region writes out of the box

The Reality Check ⚠️

5-minute transaction timeout - hard limit, no exceptions
No foreign keys - your app needs to handle referential integrity
No stored procedures - logic moves to your application layer
Optimistic locking - more failed transactions, more retry logic needed
Limited PostgreSQL features (for now) - no JSON, no PG Vector yet

Who Should Actually Use This Thing?

Look, I've been around enough database launches to know that not every shiny new thing is right for everyone. But after digging into Aurora DSQL, there are some obvious sweet spots:

🎮 Gaming Stuff

You know those leaderboards that everyone's constantly updating? Or when 50,000 players are all trying to claim the same daily reward? Yeah, that's where this shines. No more "sorry, database is locked" messages during peak hours.

🏦 Banking (Where Money Actually Matters)

If you're doing account transfers and transactions, this could be a game changer. Each transaction usually touches different accounts anyway, so the optimistic locking thing actually works in your favor. Just make sure you can handle those retry scenarios properly.

🛒 E-commerce When Things Get Crazy

Black Friday sales, flash deals, thousands of people hitting "buy now" at the same time? Traditional databases cry. Aurora DSQL just keeps going. Shopping carts, order processing, inventory updates it's all fair game.

📱 Social Apps (The Attention Economy)

Posts, likes, comments, user sessions basically anything where you've got tons of people doing small, quick operations. If your app has that "everyone's always online" vibe, this might save your sanity.

What Makes This Different from Google Spanner?

While Spanner and CockroachDB have done distributed SQL before, Aurora DSQL's approach with individual micro VMs is fundamentally different. It's designed to handle way more concurrent connections without the traditional bottlenecks.

Plus, it's got that new AWS time service that's supposedly the most accurate clock ever built for computing. When you're doing global, active-active writes, every millisecond matters.

The Migration Reality 🚚

Good news:

No magic one-click migration from regular Aurora
If you're already doing clean application design, the transition isn't horrible

You'll need to:

Audit your longest-running queries (remember that 5-minute limit)
Move foreign key logic to your application
Add retry logic with exponential backoff
Test, test, test your failure scenarios

Getting Started 🚀

Aurora DSQL is in preview, so expect:

Limited features initially (classic AWS MVP approach)
Rapid feature additions based on real customer feedback
No CloudFormation/Terraform support yet (shocking, right?)
PostgreSQL compatibility that's growing over time

🌍 Regional Availability

Aurora DSQL is currently available in a growing number of AWS regions, but there are some important considerations for where you can deploy your clusters.

Supported Regions

United States:

US East (N. Virginia) - us-east-1
US East (Ohio) - us-east-2
US West (Oregon) - us-west-2

Europe:

Europe (Ireland) - eu-west-1
Europe (London) - eu-west-2
Europe (Paris) - eu-west-3

Asia Pacific:

Asia Pacific (Tokyo) - ap-northeast-1
Asia Pacific (Osaka) - ap-northeast-3

The Multi-Region Catch (There's Always a Catch)

Okay, so here's where things get a bit annoying. You want that fancy multi-region setup with 99.999% availability? Well, you better like American geography because right now it only works between these three US regions:

US East (N. Virginia)
US East (Ohio)
US West (Oregon)

I know, I know. Your European customers are probably not thrilled about this. But hey, it's preview tech what did you expect?

What This Actually Means for Real Projects

Building something global? You're stuck deploying in US regions for now. Slap CloudFront in front of it and pray the latency isn't too bad for your London users. Not ideal, but it works.

Just need something regional? Lucky you! Pick whatever region is closest to your users from the list above. Single-region clusters work just fine everywhere.

Got compliance headaches? If you absolutely must keep data in Europe or Asia, you can still use Aurora DSQL there. You just won't get the multi-region magic. Sometimes that's life in enterprise land.

AWS is likely to expand multi-region support as the service matures, but for now, that's the reality of working with preview technology.

Hands-On: Loading Data with Aurora DSQL Loader

Want to actually try this thing out? AWS has created a handy data loading tool that makes it easy to bulk load data into Aurora DSQL using the high-performance COPY protocol.

This Loader Tool Actually Doesn't Suck

So AWS made this Python script called aurora-dsql-loader, and honestly? I was expecting another half-baked sample tool, but it's actually pretty decent for getting data into Aurora DSQL.

Why it doesn't make you want to cry:

Uses the COPY protocol instead of individual INSERTs (thank god)
Actually handles threading properly for once
Lets you tweak batch sizes (1,000 rows seems to be the sweet spot if you have indexes)
Has retry logic that actually works instead of just failing immediately
Doesn't freak out about weird delimiters or column order

Quick Demo: Loading Sample Data

Let's get our hands dirty and actually set up an Aurora DSQL cluster and throw some data at it. 💪

Step 1: The Fun Part Create Your First Cluster

First, navigate to the Aurora DSQL service in your AWS console.

Fill in the basics: 📝

complate the multi-region setup:

Confirm the cluster peering:

Wait for it to spin up: ⏳
This usually takes a few minutes. Go grab a coffee ☕️ . When it's ready, you'll see your cluster endpoint copy that, you'll need it soon.

Good to GO now 🟢

Now that we've got a cluster running, let's actually put some data in it. AWS has created a handy data loading tool that makes it easy to bulk load data using the high-performance COPY protocol.

Here's how to use it (based on a real demo loading 999,000 records):

Prerequisites: ⚙️

# You'll need:
# - Python 3.8+
# - psycopg3 installed
# - AWS CLI configured
# - Your Aurora DSQL cluster running

1. Clone the loader tool: 📥

git clone https://github.com/aws-samples/aurora-dsql-loader.git
cd aurora-dsql-loader
chmod +x aurora-dsql-loader.py

2. Create your schema and table:🗃️

-- Connect to your cluster first
CREATE TABLE users (
    name    text,
    email   text,
    age     int
);

NOTE: If you want to use the generated token from AWS console you should export it in the environment variable PGPASSWORD=<generated-token> to be able to connect to the database

(Optional) you can generate records using the following script aurora-dsql-loader.py

import random
from faker import Faker

faker = Faker()
output_file = "seed_users.sql"

with open(output_file, "w") as f:
    f.write("BEGIN;\n")
    for i in range(1, 10001):
        name = faker.name().replace("'", "''")
        email = f"user{i}@example.com"
        age = random.randint(18, 80)
        f.write(f"INSERT INTO users (name, email, age) VALUES ('{name}', '{email}', {age});\n")
    f.write("COMMIT;\n")

print(f"Generated file: {output_file}")

3. Run the loader:

PGUSER=admin \
PGHOST=your-cluster-endpoint.dsql.us-east-1.on.aws \
PGPASSWORD="$(aws dsql generate-db-connect-admin-auth-token --hostname $PGHOST --region us-east-1)" \
PGDATABASE=postgres \
PGSSLMODE=require \
./aurora-dsql-loader.py \
  --filename your-data-file.txt \
  --tablename users \
  --threads 10 \

What happens:

The tool loads data in batches of 1,000 rows
Uses 10 threads for parallel processing
Shows progress feedback as it runs
Creates a log file for monitoring
Handles Aurora DSQL's specific requirements automatically

Pro tip 😉: If you have a multi-region cluster, the data automatically replicates to your second region. You can immediately query from either endpoint and see the same data!

Real-World Performance

In practice, developers are seeing:

Load times of under 10 minutes for millions of rows
Automatic handling of Aurora DSQL's optimistic concurrency
Built-in retry logic for handling transaction conflicts
Clean progress monitoring and error handling

This tool is especially useful when migrating from other databases or doing initial data loads for new applications.

So, Should You Actually Use This? 🤔🤷‍♂️

Look, Aurora DSQL isn't some miracle cure for all your database problems. AWS isn't stupid - they know there are already plenty of databases out there. What they're trying to solve is that specific nightmare scenario where you have thousands of concurrent connections all fighting over the same database resources.

If you're building something that needs to handle crazy amounts of concurrent users think social apps, gaming backends, or financial platforms that can't afford to be down then yeah, this could save you a lot of headaches. No more 3am phone calls because your database fell over during peak traffic. 📞😴

Is it perfect? Hell no. 🤦‍♂️ The 5-minute timeout thing alone is going to bite some people. And if your app is built around foreign keys and stored procedures, you're looking at a decent amount of refactoring.

But here's the thing if you're already building clean, stateless applications (which you should be anyway), the migration path isn't as scary as it sounds. You just need to get comfortable with retry logic. Lots and lots of retry logic.

AI Integration Bonus

Oh, and here's a cool part Aurora DSQL comes with a Model Context Protocol (MCP) server built-in. Your AI models can chat with your database in natural language, making development cycles faster and reducing the need for deep SQL expertise.

Because apparently, even databases are getting the AI treatment now.😅

📚 Resources

Essential Documentation

Getting Started Guide - Your first stop for setup
PostgreSQL Compatibility - What works and what doesn't
Concurrency Control Deep Dive - Understanding optimistic locking

Hands-On Tools

Aurora DSQL Console - Create your first cluster here
Aurora DSQL Loader Tool - Bulk data loading utility
Programming Examples - SDK code samples

Technical Details

Quotas and Limits - Know before you hit the walls
AWS Database Blog - Technical deep dive from AWS

Amazon EKS Model Context Protocol (MCP): Revolutionizing Kubernetes Development with AI-Powered Context Awareness

Omar Fathy — Mon, 07 Jul 2025 22:01:54 +0000

Abstract

They say a picture is worth a thousand prompts but in the fast-paced world of cloud-native development, the Amazon EKS Model Context Protocol (MCP) says even more. Since its release, MCP has quickly distinguished itself as a breakthrough innovation, a clear example of how purposeful design can redefine best practices and significantly accelerate application development on Amazon EKS.

The Amazon EKS Model Context Protocol (MCP) Server represents a paradigm shift in cloud-native development, introducing AI-powered assistance directly into Kubernetes workflows. This open-source protocol bridges the gap between Large Language Models (LLMs) and EKS cluster management, enabling developers to interact with complex Kubernetes operations through natural language interfaces while maintaining enterprise-grade security and operational excellence.

Introduction
What is Amazon EKS Model Context Protocol?
Core Features and Capabilities
Comparison With Traditional Approaches
Use Cases and Real-World Examples
How to Use MCP in EKS
Architecture and Visual Overview
Security and Governance
Future Potential and AWS Vision
Conclusion
References

Introduction

Containerized applications have become the cornerstone of modern cloud deployments, offering consistent environments, streamlined dependency management, and seamless scaling capabilities. However, the journey from application development to production deployment remains fraught with manual, time-consuming processes that require deep expertise in Kubernetes operations, AWS services, and infrastructure management.

AWS has recently announced the launch of the open-source Amazon EKS Model Context Protocol (MCP) Server, alongside the Amazon ECS MCP Server, marking a significant advancement in AI-assisted cloud-native development. This revolutionary tool brings artificial intelligence directly into the Kubernetes development workflow, transforming how developers interact with EKS clusters.

The Challenge

Traditional Kubernetes and EKS management requires developers to:

Master complex kubectl commands and YAML manifests
Navigate intricate AWS service integrations (IAM, VPC, EBS)
Manually troubleshoot cluster issues using multiple tools and documentation sources
Context-switch between various interfaces for cluster management, monitoring, and debugging

The Solution

The EKS MCP Server addresses these challenges by:

Simplifying cluster setup with automated prerequisite creation and best practice application
Streamlining application deployment through high-level workflows and automated code generation
Accelerating troubleshooting via intelligent debugging tools and integrated knowledge base access
Enabling natural language interactions for complex Kubernetes operations

What is Amazon EKS Model Context Protocol?

The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you're building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.

Why MCP Servers?

MCP servers enhance the capabilities of foundation models (FMs) in several key ways:

Improved Output Quality: By providing relevant information directly in the model's context, MCP servers significantly improve model responses for specialized domains like AWS services. This approach reduces hallucinations, provides more accurate technical details, enables more precise code generation, and ensures recommendations align with current AWS best practices and service capabilities.
Access to Latest Documentation: FMs may not have knowledge of recent releases, APIs, or SDKs. MCP servers bridge this gap by pulling in up-to-date documentation, ensuring your AI assistant always works with the latest AWS capabilities.
Workflow Automation: MCP servers convert common workflows into tools that foundation models can use directly. Whether it's CDK, Terraform, or other AWS-specific workflows, these tools enable AI assistants to perform complex tasks with greater accuracy and efficiency.
Specialized Domain Knowledge: MCP servers provide deep, contextual knowledge about AWS services that might not be fully represented in foundation models' training data, enabling more accurate and helpful responses for cloud development tasks.

In the context of Amazon EKS, Integrating the EKS MCP server into AI code assistants enhances development workflow across all phases, from simplifying initial cluster setup with automated prerequisite creation and application of best practices. Further, it streamlines application deployment with high-level workflows and automated code generation. Finally, it accelerates troubleshooting through intelligent debugging tools and knowledge base access. All of this simplifies complex operations through natural language interactions in AI code assistants.

MCP in the EKS Ecosystem

A Model Context Protocol (MCP) server for Amazon EKS that enables generative AI models to create and manage Kubernetes clusters on AWS through MCP tools specifically addresses the complexity of Kubernetes cluster management by

Context-Aware Operations: Understanding the current state of your EKS clusters and providing relevant suggestions
EKS Cluster Management: Create and manage EKS clusters with dedicated VPCs, proper networking, and CloudFormation templates for reliable, repeatable deployments
Kubernetes Resource Management: Create, read, update, delete, and list Kubernetes resources with support for applying YAML manifests
Application Deployment: Generate and deploy Kubernetes manifests with customizable parameters for containerized applications
Operational Support: Access pod logs, Kubernetes events, and monitor cluster resources
CloudWatch Integration: Retrieve logs and metrics from CloudWatch for comprehensive monitoring
Integrated Troubleshooting: Accessing AWS's internal EKS troubleshooting knowledge base
Security-First Design: Configurable read-only mode, sensitive data access controls, and IAM integration for proper permissions management

Core Features and Capabilities

1. Kubernetes Resource Management

The EKS MCP Server provides comprehensive resource management capabilities without requiring deep kubectl expertise:

# Traditional approach - manual YAML creation
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: nginx:1.21
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

With MCP: Natural language request like "Deploy a web application with 3 replicas using nginx 1.21 in the production namespace" automatically generates and applies the appropriate resources.

2. EKS Auto Mode Cluster Management

Automated Cluster Creation

# Traditional eksctl approach
eksctl create cluster \
  --name my-cluster \
  --version 1.29 \
  --region us-west-2 \
  --vpc-private-subnets subnet-xxx,subnet-yyy \
  --vpc-public-subnets subnet-aaa,subnet-bbb \
  --with-oidc \
  --managed

MCP Enhancement: Request "Create an EKS cluster with Auto Mode in us-west-2" triggers automated CloudFormation stack deployment including:

Dedicated VPC with appropriate subnets
Security groups with least-privilege access
OIDC provider configuration
Auto Mode node pools with optimal instance selection

3. Intelligent Troubleshooting Engine

The MCP server includes direct access to AWS's internal EKS troubleshooting guide through the search_eks_troubleshoot_guide function:

// Example MCP function call
{
  "method": "search_eks_troubleshoot_guide",
  "params": {
    "query": "pod scheduling issues",
    "cluster_context": {
      "version": "1.29",
      "node_groups": ["managed", "fargate"]
    }
  }
}

4. Security-Centric Design

Default Read-Only Operation

# Starting MCP server in secure mode (default)
mcp-server-eks --region us-west-2

# Enabling write operations (explicit flag required)
mcp-server-eks --region us-west-2 --allow-write

Comparison With Traditional Approaches

The Reality Check: Before and After MCP

Let's be honest - working with Kubernetes has never been easy. Even experienced developers find themselves drowning in YAML files, debugging cryptic error messages, and spending hours on tasks that should take minutes. The traditional EKS experience often feels like this:

A Day in the Life: Traditional EKS Development

Picture this: You're a developer who just wants to deploy a simple Python web application. Here's what your day typically looks like:

Morning Coffee & kubectl Confusion ☕

   # You start with the basics, but even this requires research
   kubectl create namespace my-app
   kubectl create deployment my-app --image=my-python-app:latest
   # Wait, what's the right syntax for resource limits again?

Afternoon YAML Wrestling 🤼‍♂️

   # After hours of Stack Overflow and documentation diving
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-python-app
     namespace: my-app
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: my-python-app
     template:
       metadata:
         labels:
           app: my-python-app
       spec:
         containers:
         - name: app
           image: my-python-app:latest
           ports:
           - containerPort: 8080
           resources:
             requests:
               memory: "64Mi"
               cpu: "250m"
             limits:
               memory: "128Mi"
               cpu: "500m"

Evening Troubleshooting Sessions 🌙

   # Your pods are failing, but why?
   kubectl describe pod my-python-app-xyz
   kubectl logs my-python-app-xyz
   kubectl get events --namespace my-app
   # 3 hours later, you realize it was a simple port mismatch

Enter MCP: The Game Changer

Now, imagine the same scenario with the EKS MCP Server. Here's how that same day transforms:

A Day in the Life: MCP-Enhanced Development

Morning Simplicity ☀️

   You: "I have a Python app in my ECR repo at 123456789.dkr.ecr.eu-west-1.amazonaws.com/my-python-app:latest. 
        Can you deploy it to an EKS cluster called 'my-test-cluster'?"

   AI: "I'll help you deploy this! Let me check if the cluster exists and create the necessary resources."

Automatic Infrastructure Creation 🏗️
Behind the scenes, MCP intelligently:
- Checks if my-test-cluster exists
- Creates a CloudFormation stack with VPC, subnets, and security groups
- Generates appropriate Kubernetes manifests
- Deploys your application with best practices built-in
Intelligent Problem Resolution 🧠
When issues arise:

   You: "My pods seem to be failing. Can you investigate?"

   AI: "I found the issue! Your image architecture (ARM64) doesn't match your node group (AMD64). 
        I'll recreate the deployment with the correct node selector."

Real-World Impact: The Numbers Don't Lie

Based on real developer experiences and our analysis:

Task	Traditional Time	MCP-Enhanced Time	Improvement
New Cluster Setup	45-90 minutes	5-10 minutes	85% faster
Application Deployment	30-60 minutes	3-5 minutes	90% faster
Troubleshooting Issues	2-8 hours	15-45 minutes	80% faster
Learning Basic Operations	2-6 months	1-3 weeks	75% faster

Use Cases and Real-World Examples

The "Vibe Coding" Revolution🎧💻

The EKS MCP Server isn't just about automation - it's about enabling what AWS engineers call "vibe coding." This means you can go from a rough idea to a deployed, production-ready application through natural conversation with your AI assistant.

Use Case 1: The Startup Sprint - Multi-Tenant SaaS Deployment

The Scenario: Meet Alex, a startup founder who needs to deploy a multi-tenant SaaS platform for their new customer management tool. They have limited DevOps experience but big ambitions.

The Traditional Nightmare 😰

# Alex would typically spend days on this:
# 1. Research namespace isolation patterns
# 2. Manually create network policies
# 3. Set up resource quotas for each tenant
# 4. Configure monitoring and logging
# 5. Debug inevitable security and networking issues

kubectl create namespace tenant-companya
kubectl create namespace tenant-companyb
# ... followed by dozens of YAML files and kubectl commands

The MCP Magic ✨

Alex: "I need to set up a multi-tenant environment for my SaaS app. I have tenants 'TechCorp' and 'StartupInc', 
      each should be isolated with 2GB RAM limits and auto-scaling between 2-10 pods based on demand."

AI Assistant: "Perfect! I'll create isolated environments for both tenants with proper security boundaries. 
             Let me set this up with network policies and resource quotas."

What Happens Behind the Scenes:

# Auto-generated with security best practices
apiVersion: v1
kind: Namespace
metadata:
  name: tenant-techcorp
  labels:
    tenant: techcorp
    isolation: enabled
    created-by: mcp-server
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-isolation-techcorp
  namespace: tenant-techcorp
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          tenant: techcorp
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          tenant: techcorp
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota-techcorp
  namespace: tenant-techcorp
spec:
  hard:
    requests.memory: "2Gi"
    limits.memory: "2Gi"
    pods: "10"
    services: "5"
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: saas-app-hpa-techcorp
  namespace: tenant-techcorp
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: saas-app-techcorp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

The Result: Alex goes from concept to secure, multi-tenant environment in under 10 minutes instead of 3-4 days of research and implementation.

Use Case 2: The "Oh No!" Moment - Production Troubleshooting

The Scenario: Jamie, a DevOps engineer, gets paged at 2 AM. The company's main application is down, customers are complaining, and the CEO is asking for updates every 15 minutes.

The Traditional Detective Work 🕵️‍♀️

# Jamie's typical 2 AM troubleshooting journey:
kubectl get pods --all-namespaces | grep -i CrashLoopBackOff
kubectl describe pod failing-pod-xyz
kubectl logs failing-pod-xyz --previous
kubectl get events --sort-by=.metadata.creationTimestamp
aws logs start-query --log-group-name /aws/eks/cluster-name/cluster
# 2 hours later, still searching through logs and documentation...

The MCP Superhero Moment 🦸‍♀️

Jamie: "The payment service pods in production are failing. Can you investigate what's happening?"

AI Assistant: "I'm analyzing the issue now. Let me check the pod status, events, and recent logs."

[MCP automatically invokes multiple tools:]
- Checks pod health across namespaces
- Retrieves recent events and error patterns  
- Pulls CloudWatch logs with error filtering
- Accesses EKS troubleshooting knowledge base

AI Assistant: "Found the issue! The payment service is failing due to insufficient IAM permissions 
             for accessing the RDS database. The IAM role is missing the 'rds:DescribeDBInstances' 
             permission. I can fix this by updating the service account's IAM policy."

Jamie: "Yes, please fix it."

AI Assistant: "Done! I've updated the IAM policy and restarted the affected pods. 
             The service should be healthy in about 2 minutes."

The Magic Behind the Scenes:
The MCP server automatically:

Used list_k8s_resources to identify failing pods
Called get_k8s_events to gather error context
Invoked get_cloudwatch_logs with error filtering
Searched the eks_troubleshoot_guide for IAM-related issues
Used add_inline_policy to fix the permissions
Applied the fix with manage_k8s_resource

The Result: Jamie resolves a critical production issue in 5 minutes instead of 2-3 hours, becoming the office hero.

How to Use MCP in EKS

Prerequisites: Getting Your Environment Ready For magic 🪄

Before we dive into the magic, let's make sure you have everything you need. Think of this as preparing your workspace before starting a project:

Essential Tools (The Must-Haves):

Python 3.10+ - The foundation for running MCP servers
uv package manager - For fast Python package management
AWS CLI with credentials - Your gateway to AWS services

Optional But Recommended (The Nice-to-Haves):

eksctl - For advanced cluster management
kubectl - For direct Kubernetes interaction when needed ### 🔐 Are You Authorized to Use MCP?

Before you can use the EKS MCP server to manage your Kubernetes resources, it's essential to ensure that your IAM role or user has the proper permissions. Without these, actions like querying cluster metadata, generating manifests, or deploying infrastructure will fail with authorization errors.

Let's walk through what permissions you need and why they matter.

🕵️‍♂️ Read-Only Permissions (For Observability and Safe Exploration)

If you're only querying information—such as cluster status, resource metrics, or IAM roles—grant your IAM principal the following read-only policy. This enables the MCP server to gather cluster insights, CloudWatch metrics, and IAM configurations without making changes:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:DescribeCluster",
        "cloudformation:DescribeStacks",
        "cloudwatch:GetMetricData",
        "logs:StartQuery",
        "logs:GetQueryResults",
        "iam:GetRole",
        "iam:GetRolePolicy",
        "iam:ListRolePolicies",
        "iam:ListAttachedRolePolicies",
        "iam:GetPolicy",
        "iam:GetPolicyVersion",
        "eks-mcpserver:QueryKnowledgeBase"
      ],
      "Resource": "*"
    }
  ]
}

✅ Tip: Start with read-only mode for safer exploration, especially in production environments.

✍️ Write Permissions (For Cluster Creation and Resource Deployment)

To fully leverage MCP's deployment automation—such as provisioning EKS clusters, creating networking resources, or applying manifests—you'll need broader permissions. We recommend attaching the following managed policies to your IAM role or user:

IAMFullAccess
Grants the ability to create and manage IAM roles and policies needed by your EKS workloads.
AmazonVPCFullAccess
Allows provisioning of VPCs, subnets, route tables, NAT gateways, and other essential networking components.
AWSCloudFormationFullAccess
Required to deploy the CloudFormation stack located at:
/awslabs/eks_mcp_server/templates/eks-templates/eks-with-vpc.yaml
Custom EKS Full Access Policy (needed for full cluster and node group operations):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "eks:*",
      "Resource": "*"
    }
  ]
}

🔄 Accessing the Kubernetes API: What You Should Know

Even with the correct IAM permissions, Kubernetes API access in EKS has a few additional rules. For your user or role to successfully interact with the Kubernetes API via MCP, one of the following conditions must be true:

The IAM principal created the EKS cluster originally, and thus has automatic API access.
An EKS Access Entry has been manually configured to grant access to your IAM principal.

If you encounter Unauthorized or Forbidden errors while performing Kubernetes actions, it's likely due to a missing access entry. Review the EKS documentation on Access Entries for instructions on granting permissions explicitly.

Setting Up Your AI Copilot

The beauty of the EKS MCP Server is that it works with multiple AI assistants. Here's how to set it up with the most popular options:

Option 1: Cursor IDE Setup (Recommended for Developers)

Cursor IDE has become the go-to choice for developers who want AI assistance integrated directly into their coding workflow.

Step 1: Basic Configuration

Open Cursor and click the gear icon (⚙️) in the top-right corner
Navigate to MCP → Add new global MCP server
Paste this configuration:

For Mac/Linux:

{
  "mcpServers": {
    "awslabs.eks-mcp-server": {
      "autoApprove": [],
      "disabled": false,
      "command": "uvx",
      "args": [
        "awslabs.eks-mcp-server@latest",
        "--allow-write"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR",
        "AWS_PROFILE": "your-profile",
        "AWS_REGION": "us-west-2"
      },
      "transportType": "stdio"
    }
  }
}

For Windows:

{
  "mcpServers": {
    "awslabs.eks-mcp-server": {
      "autoApprove": [],
      "disabled": false,
      "command": "uvx",
      "args": [
        "--from",
        "awslabs.eks-mcp-server@latest",
        "awslabs.eks-mcp-server.exe",
        "--allow-write"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR",
        "AWS_PROFILE": "your-profile",
        "AWS_REGION": "us-west-2"
      },
      "transportType": "stdio"
    }
  }
}

After a few minutes, you should see a green indicator if your MCP server definition is valid.

Step 2: Test Your Setup
Open a chat panel in Cursor (Ctrl/⌘ + L) and try:

"Create a new EKS cluster named 'my-test-cluster' in the 'us-west-2' region using Kubernetes version 1.31."

Option 2: Amazon Q Developer CLI Setup

Step 1: Install Q Developer CLI

Set up the Amazon Q Developer CLI
1. Install the Amazon Q Developer CLI .
2. The Q Developer CLI supports MCP servers for tools and prompts out-of-the-box. Edit your Q developer CLI's MCP configuration file named mcp.json following these instructions. For example:
Verify Setup

  # Check available tools
  q tools

Step 2: Configure MCP
Edit your mcp.json file:

For Mac/Linux:

  {
    "mcpServers": {
      "awslabs.eks-mcp-server": {
        "command": "uvx",
        "args": ["awslabs.eks-mcp-server@latest"],
        "env": {
          "FASTMCP_LOG_LEVEL": "ERROR"
        },
        "autoApprove": [],
        "disabled": false
      }
    }
  }

For Windows:

  {
    "mcpServers": {
      "awslabs.eks-mcp-server": {
        "command": "uvx",
        "args": ["--from", "awslabs.eks-mcp-server@latest", "awslabs.eks-mcp-server.exe"],
        "env": {
          "FASTMCP_LOG_LEVEL": "ERROR"
        },
        "autoApprove": [],
        "disabled": false
      }
    }
  }

Verify your setup by running the /tools command in the Q Developer CLI to see the available EKS MCP tools.

Understanding Security Flags and Configurations 🔒

The EKS MCP Server comes with built-in configurable arguments and environment variables as safety switches:

The args field in your MCP server definition allows you to customize how the EKS MCP server runs by passing specific command-line arguments. These flags control permissions, security behavior, and how the server interacts with Kubernetes and AWS resources.

You can fine-tune the behavior of the EKS MCP server using environment variables defined under the env field. These variables control everything from logging verbosity to AWS authentication settings.

🔧 Common Command Arguments

`--allow-write` Flag

When the --allow-write flag is enabled, the EKS MCP Server can create missing IAM permissions for EKS resources through the add_inline_policy tool. This tool enables the following:

Only creates new inline policies; it never modifies existing policies.
Is useful for automatically fixing common permissions issues with EKS clusters.
Should be used with caution and with properly scoped IAM roles.
What it does: Enables creation, modification, and deletion of resources
When to use: Development environments, trusted automation
When NOT to use: Production clusters without proper review processes

// Conservative approach (read-only)
"args": ["awslabs.eks-mcp-server@latest"]

// Development approach (with write access)
"args": ["awslabs.eks-mcp-server@latest", "--allow-write"]

`--allow-sensitive-data-access` Flag

Enables access to sensitive data such as logs, events, and Kubernetes Secrets.

Default: false (Access to sensitive data is restricted by default)
What it does: Allows access to logs, events, and secrets
When to use: Troubleshooting, monitoring, development
When NOT to use: Shared environments or when logs contain sensitive data

// Full access (use carefully)
"args": [
  "awslabs.eks-mcp-server@latest",
  "--allow-write",
  "--allow-sensitive-data-access"
]

Important Security Note: Users should exercise caution when --allow-write and --allow-sensitive-data-access modes are enabled with these broad permissions, as this combination grants significant privileges to the MCP server. Only enable these flags when necessary and in trusted environments. For production use, consider creating more restrictive custom policies.

⚙️ Common Environment variables

Here's a sample configuration snippet:

{
  "mcpServers": {
    "awslabs.eks-mcp-server": {
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR",
        "AWS_PROFILE": "my-profile",
        "AWS_REGION": "us-west-2"
      }
    }
  }
}

🔊 `FASTMCP_LOG_LEVEL` (optional)

Controls the verbosity of logs produced by the MCP server.

Accepted values: "DEBUG", "INFO", "WARNING", "ERROR", "CRITICAL"
Default: "WARNING"
Use case: Set to "ERROR" in production to reduce noise; use "DEBUG" when troubleshooting.

📌 Example:

"FASTMCP_LOG_LEVEL": "ERROR"

🔐 `AWS_PROFILE` (optional)

Specifies which named AWS CLI profile to use when authenticating with AWS services.

Default: If not set, the server falls back to the default credentials provider chain (e.g., environment, EC2 metadata).
Use case: Ideal when running the server locally with multiple profiles configured.

📌 Example:

"AWS_PROFILE": "my-profile"

🌍 `AWS_REGION` (optional)

Defines the target AWS region where EKS clusters are located. All MCP operations will use this region context.

Default: If not provided, AWS SDK default behavior will apply (which may vary based on environment).
Use case: Ensure MCP commands and deployments run in the intended region, especially when managing clusters across multiple environments.

📌 Example:

"AWS_REGION": "us-west-2"

Best Practices for Safe MCP Usage

The "Production Safety" Checklist ✅

[ ] Start Read-Only: Always begin with read-only mode for evaluation
[ ] Environment Separation: Use different configurations for dev/staging/prod
[ ] Access Control: Apply least-privilege IAM policies
[ ] Audit Everything: Enable comprehensive logging
[ ] Regular Updates: Keep MCP server updated with security patches

The "Developer Happiness" Checklist 😊

[ ] Enable Write Mode: For development environments, enable --allow-write
[ ] Sensitive Data Access: Enable for troubleshooting capabilities
[ ] Auto-Approve: Consider enabling for trusted, repeated operations
[ ] Multiple MCP Servers: Combine EKS with other AWS MCP servers as needed
[ ] Custom Regions: Set appropriate AWS regions for your infrastructure ### Quick Troubleshooting Guide

"It's Not Working!" - Common Issues and Solutions

Issue: MCP server shows as disconnected

# Check AWS credentials
aws sts get-caller-identity

# Verify Python and uv installation
python --version
uv --version

# Check MCP server logs
# (Look in your AI assistant's debug/log output)

Issue: Permission denied errors

# Verify IAM permissions
aws iam simulate-principal-policy \
  --policy-source-arn $(aws sts get-caller-identity --query Arn --output text) \
  --action-names eks:DescribeCluster \
  --resource-arns "*"

Issue: Cluster connection problems

# Update kubeconfig
aws eks update-kubeconfig --region us-west-2 --name my-cluster

# Test connectivity
kubectl cluster-info

Architecture and Visual Overview

How Everything Connects: The Big Picture

Imagine the EKS MCP Server as a universal translator that sits between your natural language requests and the complex world of AWS and Kubernetes APIs. Here's how the magic happens:

AI Assistant (e.g., Cursor) at the top
MCP Protocol layer
EKS MCP Server in the middle
AWS Services (EKS, IAM, CloudWatch, VPC) at the bottom
Bidirectional data flow arrows
Security boundaries and encryption indicators]

The Intelligence Behind the Simplicity

What you see: Simple conversation with your AI assistant
What's actually happening: A sophisticated orchestration of AWS services

Your Input: "Deploy my Python app to EKS"
    ↓
AI Processing: Understanding intent and context
    ↓
MCP Translation: Converting to specific tool calls
    ↓
AWS API Calls: Executing infrastructure operations
    ↓
Kubernetes Operations: Managing application deployments
    ↓
Real-time Feedback: Monitoring and reporting status
    ↓
Human-friendly Response: "Your app is deployed and healthy!"

The Tools Under the Hood

The EKS MCP Server comes packed with an impressive array of tools. Think of them as specialized functions that handle different aspects of cluster management to automate and simplify management of your Amazon EKS clusters and Kubernetes resources. Each tool performs a targeted operation and can be invoked as part of your workflow for provisioning, managing, observing, and troubleshooting infrastructure.

Cluster Management Tools 🏗️

manage_eks_stacks - Your cluster lifecycle manager. Automates lifecycle management of EKS CloudFormation stacks. Features:
- Generate CloudFormation templates for EKS clusters.
- Deploy clusters with all necessary components (VPCs, subnets, IAM roles, etc.).
- Describe stack metadata, status, outputs.
- Delete stacks and clean up associated resources.
- Operates only on stacks originally created by this tool.

Parameters:

operation: generate, deploy, describe, or delete
template_file: required for generate/deploy
cluster_name: required for all operations
- search_eks_troubleshoot_guide - Your troubleshooting expert Searches AWS EKS Troubleshoot Guide for relevant issue resolutions.

Features:

Provides solutions for common EKS issues (bootstrap, node autoscaling, etc.)
Suggests short-term fixes and long-term resolutions

Parameters:

query

Kubernetes Resource Tools ⚙️

manage_k8s_resource - Your Swiss Army knife for Kubernetes objects Manages any Kubernetes resource directly.

Features:

Supports create, replace, patch, delete, and read
Works with both namespaced and non-namespaced resources

Parameters:

operation, cluster_name, kind, api_version, name
namespace (optional), body (for create/replace/patch)
- list_k8s_resources - Your resource discovery tool Lists resources by type in a Kubernetes cluster.

Features:

Filters by namespace, label, or field selectors
Outputs metadata for matched resources

Parameters:

cluster_name, kind, api_version
namespace, label_selector, field_selector (all optional)
- apply_yaml - Your manifest deployment specialist Applies multi-resource YAML manifests to a cluster.

Features:

Accepts multi-document YAML files
Applies all resources within a specified namespace
Can force updates to existing resources

Parameters:

yaml_path, cluster_name, namespace, force
- list_api_versions your Kubernetes objects refrence Lists all API versions available in a Kubernetes cluster. Features:
- Includes both core (v1) and grouped (apps/v1, etc.) APIs
- Useful for compatibility checks and YAML generation
Parameters:
- cluster_name

Application Support Tools 🚀

generate_app_manifest - Your deployment template generator Generates basic Kubernetes manifests for your application.

Features:

Produces Deployment and Service YAML files
Configurable replicas, resources, load balancer, etc.

Parameters:

app_name, image_uri, output_dir
Optional: port, replicas, cpu, memory, namespace, load_balancer_scheme
- get_pod_logs - Your application debugger Retrieves logs from a specific pod.

Features:

Filter by time window, line count, or byte size
Supports logs from specific containers
Requires --allow-sensitive-data-access

Parameters:

cluster_name, pod_name, namespace
Optional: container_name, since_seconds, tail_lines, limit_bytes
- get_k8s_events - Your event investigator Fetches Kubernetes events for a resource.

Features:

Returns detailed info: timestamps, reasons, component, and type
Supports both namespaced and cluster-wide resources
Requires --allow-sensitive-data-access

Parameters:

cluster_name, kind, name
Optional: namespace

CloudWatch Integration Tools 📊

get_cloudwatch_logs - Your centralized logging assistant Fetches CloudWatch logs for specific EKS resources.

Features:

Query logs by time, resource type, name, filter patterns
Supports both infrastructure and application logs
Requires --allow-sensitive-data-access

Parameters:

cluster_name, log_type, resource_type
Optional: resource_name, minutes, start_time, end_time, limit, filter_pattern, fields
- get_cloudwatch_metrics - Your performance monitoring tool Fetches CloudWatch metrics for your workloads.

Features:

Query by metric name, namespace, dimensions
Configure range, granularity, and statistic
Supports custom dimensions

Parameters:

cluster_name, metric_name, namespace, dimensions
Optional: minutes, start_time, end_time, limit, stat, period
- get_eks_metrics_guidance Lists recommended metrics and dimensions for various EKS resource types.

Features:

Covers supported types: cluster, node, pod, namespace, service
Outputs available metrics, descriptions, and dimension mappings

Parameters:

resource_type

Implementation Note:
Generated from AWS Container Insights metrics using:

  uv pip install bs4
  python /scripts/update_eks_cloudwatch_metrics_guidance.py

IAM Integration 🔐

get_policies_for_role Retrieves policy details for an IAM role.

Features:

Includes assume role policy, managed policies, and inline policies

Parameters:

role_name
- add_inline_policy

Attaches a new inline policy to an IAM role.

Features:

Prevents accidental overwrite of existing policies
Accepts JSON policy document or list of statements
Requires --allow-write

Parameters:

role_name, policy_name, permissions

The Smart Design Philosophy

Why Unified Tools Instead of Separate Functions?

Traditional approaches would create individual tools for every Kubernetes resource type (pods, services, deployments, etc.). This would quickly overwhelm the AI's context window. Instead, the EKS MCP Server uses a clever approach:

Instead of:
- create_pod_tool
- create_service_tool  
- create_deployment_tool
- update_pod_tool
- update_service_tool
- ... (50+ tools)

We have:
- manage_k8s_resource (handles all CRUD operations)
- list_k8s_resources (handles all resource discovery)
- apply_yaml (handles manifest deployment)

This design keeps the context window manageable while providing comprehensive functionality.

Security and Governance: Balancing Power with Control

Understanding the Security Paradigm

When we talk about granting AI agents permissions to manage your cloud infrastructure, it's natural to have concerns. The AWS team has designed EKS MCP with a fundamental security principle in mind: MCP servers only have access to what you already have access to. They cannot magically access secrets from other accounts or perform actions beyond your existing permissions.

Think of it this way: the MCP server operates with the same level of access that you, as a developer, would have. It's essentially acting as an intelligent extension of your existing credentials, not as a privileged escalation tool.

Critical Security Considerations in Production

The Reality of AI-Powered Operations

During AWS's internal discussions, the team emphasized a crucial point: these tools are incredibly powerful, and that power requires responsibility,and as any Spider-Man fan knows: with great power comes great responsibility." 🕷️💻 As one AWS engineer put it during their live demo: "We are in some ways making it more powerful for them, making it easier for them to deploy... but again, make sure you check, please, Vibe coding and AI tools can take you far—but if you’re flying blind, you might also crash hard."

Production Environment Safeguards

The Golden Rule: When running MCP servers on production clusters, ⚠️🛑 always turn off auto-approvals for write operations. Here's why this matters:

In live demonstrations, AWS engineers showed scenarios where:

An incorrect API endpoint was automatically corrected ✅ (helpful)
But in another case, when an endpoint was wrong, the system also changed the container image saying "maybe use another image" and patched the deployment ❌ (potentially dangerous)

Recommendation: Approve write operations one by one in production environments to maintain control over what gets deployed.

Data Protection and Privacy

Redacting Sensitive Information

One of the most significant security features being implemented is automatic redaction of PII and sensitive data. This includes:

Passwords and secret keys
API tokens and credentials
Personal identifiable information
Sensitive configuration data

This data is redacted from both logs and AI model outputs, addressing concerns about secure data being passed to LLMs.

IAM Integration and Best Practices

Principle of Least Privilege in Practice

The MCP server follows AWS security best practices through:

Dedicated IAM roles designed specifically for MCP operations with minimal required permissions
Separate roles for read-only versus write operations
Resource tagging strategies to limit actions to MCP-managed resources
Regular permission audits using IAM Access Analyzer to identify and remove unused permissions

Kubernetes RBAC: Your Safety Net

Remember that even with proper IAM permissions, Kubernetes API access must be correctly configured. The MCP server operates within the same RBAC constraints that govern your manual kubectl operations.

Operational Security: The Human Element

The Importance of Vigilance

As AWS's product manager candidly shared: "I'm not an engineer by trade... I'm not exactly sure all of the guidelines that I need to make sure that I check. Since I'm not an engineer, I don't know what I don't know."

This honest admission highlights a critical point: monitoring and vigilance are essential. Whether you're a pro or new to Kubernetes world, always:

Review what's being deployed to your account
Understand the changes before approving them
Set up proper monitoring and alerting
Implement resource limits and quotas

Guardrails and Control Mechanisms

The MCP server includes several built-in safety features:

Resource validation before deploying infrastructure
Template verification to prevent arbitrary stack deletion
Allowlists and denylists for specific resources
Consent requirements for sensitive operations

Future Potential and AWS Vision: The Evolution of AI-Driven Infrastructure

Where We Are Today vs. Tomorrow

Currently, we're in in a "supervised state" with AI integrations, as AWS call it. As one AWS engineer noted: "We're not quite there yet for unsupervised agents just monitoring your clusters and making actions. It'll be some time before we fully trust agents."

But the trend is evident and the opportunities are vast.

Near-Term Evolution

Improved Remote Features

Obstacle: Some AI tooling doesn't work too well with remote MCP hosts.

Solution: The tendency in the industry is:
- Improved remote MCP server design

Pre-defined best practise templates
Automatic updating and maintenance
Enhanced reliability for distributed deployments

Agent to agent communication

One of the more promising ones is agent communication. Imagine agents that can:

Communicate with one another without direct user action
Partner with Delivery for complicated deployment scenarios – Discuss ideas and help others troubleshoot issues - Keep audit trails of all inter-agent operations

The Problem: What guidelines should you put in place so that agents are responsive while you still end up seeing the final results?

Addressing the Context Window Problem

The Current Limitation

As of now there is a restriction on addition of no of MCP tools IDE can work at a time. This poses a problem when you have to use the right tools for the job.

The Future Solution

AWS is exploring:

Dynamic tool, switch: It selects the correct MCP server depending on the current context Automatically generates tool switching, the default workflow tool selects the correct MCP server depending on the current context spinning up a dev environment outside an IDE, where you can directly modify project files.
Smart tool routing: Selection of the most appropriate tool based on context
-Standardised interfaces: MCP servers are easier to be interchanged and's more reliable.

Final Thoughts: The Pull of the Long-Term ValueError — The path from Supervised to Autonomous

Today: AI Help That’s Monitored

AI suggests actions
Humans review and approve
Clear audit trails
Safety nets and guardrails

Tomorrow: Smart Autonomous Operations

Proactive monitoring of the cluster health
Self-healing infrastructure
Predictive issue resolution
Oversight over humans with exception intervention

The Big Idea: Trust via Transparency

The journey to autonomy is not one of eliminating human overseers, but of designing AI systems so trustworthy, transparent and predictable that these overseers become strategic rather than simply tactical.

Benefiting Industry: Best Practices, Accelerated Innovation

The Feedback Loop Effect

Early feedback to AWS has revealed that supervisedcustomers are executing better practices when setting up MCP. This forms a positive feedback cycle:

AI advises the right moves → Better practice.rewire.
Improved applications → Better applications
Reliability of systems rise → More reliance on AI supporting us
More confidence- Greater acceptance of automation

Innovation Acceleration

Developers spend more time on: Here is how you spend your time more on the following and less on the previous section: Infrastructure complexity.
- Business logic and functionality
- User experience enhancements

Crafty problem-solver
Quick prototyping & iteration

Difficulties and Self-Reflection

Challenge of Summarization

As AWS engineers said while testing: ``When the LLM is trying to diagnose the problem it is asking multiple things and trying to summarize the result. Sometimes the summarization isn’t a match of what we intended to do.” *

Example: And in an EKS Auto Mode investigation, where the AI correctly figured out which policies were needed, it thought they should be added to the node role first, not the cluster role. On the second proofing, it fixed this.

The Challenge Ahead: Getting the balance on data for AI models right – enough for the right troubleshooting without clogging up the context window.

Problem Of Consistent Installation

Current problem: Not all MCP servers install the same, even on the same server config. The industry is heading toward standardization to try to make these interactions more predictable and reliable.

The Bigger Picture: Democratizing Cloud Expertise

The ultimate vision extends beyond just making Kubernetes easier. It's about:

Democratizing cloud expertise: Making advanced cloud capabilities accessible to developers regardless of their infrastructure background
Reducing the expertise gap: Helping junior developers learn through AI-guided practice
Improving security posture: Making security best practices the default, not the exception
Accelerating innovation: Removing infrastructure complexity as a barrier to creativity

The convergence of AI and cloud infrastructure management represents one of the most significant shifts in how we build and operate systems. Amazon EKS MCP is positioned at the forefront of this transformation, providing both the power to accelerate development and the guardrails to do so safely.

Conclusion

The Amazon EKS Model Context Protocol represents a transformative advancement in cloud-native development, fundamentally changing how developers interact with Kubernetes infrastructure. By bridging the gap between natural language and complex cluster operations, MCP democratizes access to enterprise-grade container orchestration while maintaining the security and operational excellence that AWS customers demand.

Key Benefits Realized

Accelerated Development Cycles: Reducing deployment times from hours to minutes
Lowered Barrier to Entry: Making Kubernetes accessible to developers of all skill levels
Enhanced Operational Excellence: Integrating best practices into every interaction
Improved Security Posture: Implementing security-by-default with granular controls
Cost Optimization: Intelligent resource management reducing unnecessary expenses

Strategic Implications

The introduction of MCP signals AWS's commitment to AI-driven infrastructure management, positioning the platform for the next generation of cloud-native applications. Organizations adopting MCP early will gain competitive advantages through:

Faster Time-to-Market: Reduced complexity in deployment pipelines
Improved Developer Satisfaction: Focus on business logic rather than infrastructure management
Enhanced Reliability: AI-assisted troubleshooting and preventive maintenance
Future-Proof Architecture: Foundation for emerging AI and ML workloads

What's Next?

To explore Amazon EKS MCP in your environment:

Start with Evaluation: Deploy MCP in read-only mode for risk-free exploration
Pilot Project: Choose a non-critical application for initial testing
Team Training: Invest in AI-assisted development practices
Gradual Adoption: Expand usage based on success metrics and team confidence
Community Engagement: Contribute feedback and use cases to shape future development

The convergence of artificial intelligence and cloud infrastructure management is no longer a future possibility—it's today's reality. Amazon EKS MCP provides the foundation for this transformation, enabling organizations to harness the full potential of AI-assisted development while maintaining the reliability, security, and scalability that modern applications demand.

References

Official AWS Documentation

Technical Resources

Community and Learning

Related Whitepapers

"AI-Driven Infrastructure Management: The Future of Cloud Operations"
"Security Best Practices for AI-Integrated Development Workflows"
"Cost Optimization Strategies for Modern Kubernetes Deployments"
"The Evolution of Developer Experience in Cloud-Native Environments"

The revolution of e-commerce 👗with Three.js and AWS Amplify ☁️

Omar Fathy — Fri, 30 Sep 2022 01:03:33 +0000

Introduction 🏁

The world around us is in a great and huge evolution some examples of this evolution are the evolution in health, industry, transportation, etc... another example of this evolution is the evaluation of Online shopping. Many people are now shopping through the Internet and buying most of their supplies on the Internet without the need to leave their homes. Get off is for bus, work, taxi, etc...

The Problem 😞

Online shopping has disadvantages, for example, How many times have you bought a piece of clothes and been shocked that the product you purchased was not as described on the online site or that the size you bought was not the accurate size, how many times have you wished that you were able to switch between the colors and shapes of the clothes Even if you are in a real clothes store ... Here comes the role of TopShop

What is TopShop? 🛒

TopShop is a 3D Virtual Dressing Room that aims to help the customefacilitateng the process of buying clothes through the Internet by viewing a 3D model of the product before purchasing it, and he can choose from different colors of the product and see the benefits of using the 3D modeling in representing the product as it will look in real life.

Technology 🖥

WebGL
Three.js
Blender
JavaScript
Bulma
Sass
Gulp
AWS Amplify

Demo 🎬

Here user can log in to the website or he can use any one of the demo accounts we listed previously just click on it 😉 you can try the demo from here or here

About 3D Model

I will explain how the model is set up in Blender, and if youd like to create something of your own, change a free model you found somewhere online, or instruct someone youre commissioning. Heres some information about how our 3D model is authored.

Scale

The scale is set to approximately what it would be in the real world.

Layering and naming conventions

This part is important : each element of the object you want to customize independently needs to be its object in the 3D scene, and each item needs to have a** unique name**. Here we have up and down. Note that if you have said, three items all called up, Blender is going to name them as up, up.001, up.002. That doesnt matter, because in our JavaScript well be using includes(up) to find all of those objects that contain the string up in it.

File Format

Three.js supports a bunch of 3D object file formats, but the one it recommends is glTF (.glb). Blender supports this format as an export option, so no worries there.

Three.js

Loading the model

Were going to add the function that loads in models, this is provided by the second dependency we added in our HTML.

Before we do that though, lets reference the model, well be using this variable quite a bit. Add this at the top of your JavaScript, above your BACKGROUND_COLOR. Lets also add a path to the model. Ive hosted it for us, its about 1Mb in size.

var theModel; 
const MODEL_PATH ="https://s3-us-west-2.amazonaws.com/s.cdpn.io/1376484/model.glb";

Now we can create a new loader and use the load method. This sets theModel as our 3D models' entire scene. Were also going to set the size for this app, the right size seems to be about twice as big as its loaded. Thirdly, were going to offset the y position by -1 to bring it down a little bit, and finally, were going to add the model to the scene.

The first parameter is the models filepath, the second is a function that runs once the resource is loaded, the third is undefined for now but can be used for a second function that runs while the resource is loading, and the final parameter handles errors.

Camera 📷

// Init the object Loader 
var loader = new THREE. GLTFLoader();
loader.load(MODEL_PATH, function(gltf) {
theModel = gltf.scene;
// Set the models initial scale
theModel.scale.set(2,2,2);
// Offset the y position a bit 
theModel.position.y = -1;
// Add the model to the scene 
scene.add(theModel);
}, undefined, function(error) {
console.error(error)
});

Lights 💡

// Add Lights 
var hemiLight = new THREE.HemisphereLight(Oxffffff, 0xffffff, 0.61);
hemiLight.position.set(0, 50, 0); 
// Add hemisphere light to scene
scene.add(hemiLight);
var dirlight = new THREE.DirectionalLight(Oxffffff, 0.54);
dirLight.position.set(-8, 12, 8); 
dirLight.castShadow = true;
dirLight.shadow.mapSize = new THREE.Vector2(1024, 1024);
// Add directional Light to scene
scene.add(dirLight);

Controls 🛠

// Add controls 
var controls = new THREE.OrbitControls(camera, renderer.domElement); 
controls.maxPolarAngle = Math.PI/ 2;
controls.minPolar Angle = Math.PI/ 3; 
controls.enableDamping = true; 
controls.enablePan = false; 
controls.dampingFactor = 0.1; 
controls. autoRotate = false; 
// Toggle this if you'd like the model to automatically rotate 
controls.autoRotateSpeed = 0.2;

to Learn more check the documentation here or manual from here

Amplify Hosting

Why should I use it? 🤔

AWS Amplify is a complete solution that lets frontend web and mobile developers quickly build, ship, and host full-stack applications on AWS, with the flexibility to leverage the breadth of AWS services as use cases evolve. No cloud expertise is needed.

To get started, log in to the Amplify console. If you are starting from the AWS Amplify home page, choose to Get Started at the top of the page.

Then choose to Get started under Deliver.

If you are starting from the All apps page, choose New app , then Host web app in the upper right corner.

you can manually deploy an app using drag and drop

but we will use our GitHub repo

Step 1: Connect a repository 🗃

Connect your GitHub, Bitbucket, GitLab, or AWS CodeCommit repository. After you authorize the Amplify console with Bitbucket, GitLab, or AWS CodeCommit, Amplify fetches an access token from the repository provider.

Step 2: Confirm build settings for the front end 🛠

Important: Verify that the build commands and build output directory (that is, artifacts > baseDirectory) are accurate. If you need to modify this information, choose Edit to open the YML editor. You can save your build settings on our servers, or you can download the YML and add it to the root of your repo.

Step 3: Confirm build settings for the backend

To deploy backend functionality using the Amplify CLI during your build, create or reuse an AWS Identity and Access Management (IAM) service role. IAM roles are a secure way to grant Amplify permissions to act on resources in your account. For detailed instructions, see Adding a service role.

Step4: Save and deploy 💾

Review all of your settings to ensure everything is set up correctly. Choose Save and deploy to deploy your web app.

Access the build logs screen by choosing a progress indicator in the branch section. A build has the following stages:

Now your app is built and deployed 🎉🎉🎉

Of course, this is just a simple example of hosting a web app using AWS Amplify, but there is a lot that you can do, so you can learn more throughthis demo and you can use Amplify Studio to easily build and ship complete web and mobile apps in hours. With Amplify Studio, you can quickly build an app backend, create a rich user interface (UI) React components, and connect a UI to the backend in clicks.