# 👋 Everything about EKS & AI Infrastructure Newsletter "#93" ☁️❤👨‍💻

**Dear EKS & AI Infrastructure enthusiasts,**\
Welcome to Everything about EKS & AI Infrastructure #93.

If one theme ran through this week, it was giving every AI agent its own walls. AWS launched Nitro Sandboxes, which give each EKS pod its own lightweight VM and kernel while it still looks like a normal pod to Kubernetes. A set of 30+ blueprints shows how to use it for coding agents, CI/CD runners and confidential workloads. We also cover the default network limits to raise before you benchmark it, and Strands Box, which adds rules for what an agent is allowed to do inside its sandbox. The isolation used to need a whole machine per workload. Now it fits inside a pod.

On the EKS side, it’s a week of small changes that remove real pain. Auto Mode now gives each pod its own security group, so you no longer need separate nodes just to keep one app away from a database. Provisioned Control Plane clusters get 50% more room in etcd. And AWS Backup can now fix IAM roles, endpoints and image locations as it restores into a new account or Region.

For AI infrastructure, Trainium had a strong week. A 754B model ran on a single Trainium3 machine using standard Hugging Face code, and SGLang now runs on Trainium through a new plugin. We also cover two kinds of GPU failure. ECS now replaces GPUs that report errors automatically. A HyperPod guide shows how to catch the harder kind: a GPU that quietly returns wrong numbers and spoils training for hours.

Let’s dive in.\
\
Performance Engineering in Modern AI Systems 🌩️

🌩️[**GLM-5 on AWS Trainium3 with Vanilla Transformers**](https://huggingface.co/blog/dacorvo/glm-5-on-aws-trainium3-with-vanilla-transformers)\
David Corvoysier, Hugging Face

Most AI models are built to run on NVIDIA GPUs. AWS makes its own AI chip, called Trainium. Until now, running a big model on Trainium usually meant someone had to rewrite parts of the model first. That extra work is a big reason teams stick with NVIDIA.

This post shows that step may no longer be needed. The author took GLM-5, a very large open model, and ran it on Trainium3 using the same model code everyone downloads from Hugging Face, with nothing rewritten. The whole model ran on a single AWS machine. The model was too big for any one chip, so it was split into 64 parts and spread across the machine. Once it was running, it started answering in about 4 seconds and then produced about 7 tokens, roughly words, per second.

The catch is startup time. Loading the model and preparing it to run took well over an hour the first time. Two default settings also had to be changed, or the run slowed down. The author says this was a first test with no tuning, so treat the speed as a starting point, not a final result.

Starred Content ⭐

⭐ [**AWS Nitro Sandbox on Amazon EKS Blueprints**](https://aws-samples.github.io/sample-eks-nitro-sandbox/)\
AWS Samples, companion to the Nitro Sandboxes launch post

The Nitro Sandboxes launch explains what the feature is. This collection shows how to use it. A sandboxed pod runs in its own lightweight VM, which runs directly on the server and is not nested inside another VM. So if code inside the sandbox breaks out of its container, it only reaches the sandbox’s own operating system, not the server or the apps next to it. To your team, it’s still a normal pod: same images, same tools, same `kubectl` commands.

The blueprints cover the main ways people will use this. There are coding agents, plus Claude and OpenAI managed agents. There are agent-sandbox examples like pause and resume, warm pools, and an IDE in the browser. There are storage examples with EBS, EFS and S3 Files. There are CI/CD runners for Docker builds, GitHub Actions and GitLab. There are confidential sandbox examples, such as encrypted images and Secrets Manager secrets. And there are subagent security setups, including one with Strands Box. Warm pools are worth a look: they keep sandboxes started ahead of time, so an agent can take one in under a second instead of waiting for a new VM to boot.

The catch: the examples are set to us-west-2, so you have to edit the files to use another Region. The coding agent example also needs Docker, the GitHub CLI and access to a Claude model in Amazon Bedrock. The site doesn’t cover pricing, which instance types to use or how big the cluster should be. Start with “Hello sandbox”, because the other examples build on it.

⭐ [**Detecting and Recovering from Silent Data Corruption on Amazon SageMaker HyperPod**](https://aws.amazon.com/blogs/machine-learning/detecting-and-recovering-from-silent-data-corruption-on-amazon-sagemaker-hyperpod/)\
Siddharth Senger, Pradeep Cruz, Nilesh PS and Roy Allela, AWS

Most broken GPUs report an error. Some don’t. With silent data corruption, a GPU returns a wrong number that still looks reasonable, and raises no error at all. In multi-GPU training, that wrong value spreads to every copy of the model, and the training loss can look normal for hours. It isn’t rare. During Meta’s 54-day Llama 3 training run on up to 16,000 H100 GPUs, 6 of 419 unexpected job stops were traced to this. The usual safety checks miss it because they verify memory and network transfers, not whether the math itself was right.

The fix uses a simple fact: in this kind of training, every GPU should end each step with exactly the same model. So the job runs three checks. First, it looks for gradients that have turned into NaN or infinity. Second, every so often, each GPU re-does another GPU’s work and compares the answers exactly. Every GPU gets checked twice, so if both checks fail, that GPU is the one at fault. Third, it compares a short fingerprint of each GPU’s copy of the model. A GPU is flagged only if its copy doesn’t match the majority. When a check fails, the bad update is skipped and no checkpoint is saved. On HyperPod with EKS, the node name includes the EC2 instance ID, so finding the bad server is just a lookup. From there you cordon the node, run a stress test, replace it, and restart from the last good checkpoint.

The catch is cost and coverage. In their test, the stricter checks every 100 steps added about 10% to step time, and running them every 10 steps added about 35%. Fault-free runs of 30,800 steps raised no false alarms, but the faults were simulated in software on a small test model, not on real failing hardware. The method was tested only with plain data parallel training and doesn’t work with full FSDP sharding. Replacing a node also wipes its local disks, so keep checkpoints on shared storage. The authors suggest keeping a human approval step before any node is replaced, until you trust the alarms on your own workload.

⭐ [**Scale Distributed AI Workloads with Ray and Anyscale on Amazon EC2**](https://aws.amazon.com/blogs/architecture/scale-distributed-ai-workloads-with-ray-and-anyscale-on-amazon-ec2/)\
Sindhura Palakodety, Arnab Sinha and Kinnar Kumar Sen, AWS

An AI pipeline is really several jobs in a row: preparing data, training, tuning and serving. Each one needs different hardware, and different teams often own each step. The post names three problems: growing from one machine to many without rewriting code, keeping costs under control, and keeping up with new models and hardware. It answers all three with one design: Ray, an open source tool that spreads Python work across many machines, and Anyscale, a managed service built on Ray. Ray comes with ready-made parts for each step: Ray Data for preparing data, Ray Train for training, Ray Tune for tuning and Ray Serve for serving. Anyscale runs the control layer, but the servers, storage and network stay in your own AWS account, and Anyscale never touches your data directly.

The post gives three ways to run it. Plain EC2 is the default for most teams. EKS is for teams that already run Kubernetes: Ray runs as pods, and Karpenter adds and removes nodes as needed. SageMaker HyperPod is for long training runs that can’t afford to fail, because it replaces broken nodes and resumes from a checkpoint. Each step then runs on the hardware that suits it. Regular Intel, AMD or Graviton servers prepare the data, GPUs or Trainium handle training, Inferentia handles high-volume serving, and cheaper Spot servers take batch work. Ray detects which chip a server has, so each step is sent to the right hardware without manual setup.

The most useful part is how it handles Spot servers, which are cheap but can be taken back at short notice. The main node stays on a regular server and the workers run on Spot. If a worker is taken away, data jobs retry, training resumes from its last checkpoint, and serving moves to another server within the two-minute warning. When it needs servers, it tries reserved capacity first, then Spot, then regular on-demand servers. Scaling happens at two levels: Ray Serve adds copies of the model as traffic grows, and the cluster adds or removes servers to fit. The post’s main point is that the same code runs from a laptop test all the way to production, with only configuration changes.

The catch: this is a design guide, not a tested walkthrough. The EKS option also adds complexity and needs extra setup for the Anyscale operator. Read it for the design patterns. Spot savings only show up if your jobs checkpoint and retry properly.

1. Announcements 📢

📢 [**AWS Nitro Sandboxes: Hardware-Enforced Workload Isolation on Amazon EKS**](https://aws.amazon.com/blogs/containers/aws-nitro-sandboxes-hardware-enforced-workload-isolation-on-amazon-eks/)\
Carlos Santana and Trishi Mehta, AWS

Normally, all the pods on a node share one operating system kernel. That keeps them light and fast, but it means they aren’t fully separated: a flaw in one pod can let an attacker reach the others on the same node. Teams that needed real separation usually gave each risky workload its own machine and left most of it unused. The post names three groups that feel this most: AI agents running code nobody has checked, SaaS platforms that put many customers on one cluster, and regulated industries that need cryptographic proof of separation, not just a list of settings.

Nitro Sandboxes give every pod its own small virtual machine with its own kernel. When a sandboxed pod is scheduled, EKS asks EC2 for a slice of the server called a Nitro Partition and starts a VM inside it. The Nitro Hypervisor enforces that slice of CPU and memory in hardware, so one pod can’t take from another. Inside the VM, a small AWS component checks the pod spec against a policy, pulls the images and starts the containers. Resources that pods still share, such as network bandwidth, disk I/O and DNS, are rate-limited by default so one noisy pod can’t slow the rest. Kubernetes still sees a normal pod, so logs, exec, health checks, Pod Identity, storage volumes and VPC networking all keep working.

There are two modes. Isolated protects the host and neighbouring pods. Confidential goes further and treats even the machine’s operator as untrusted: AWS KMS only releases decryption keys after the VM proves it is running the expected system image and policy. On EKS Auto Mode, both modes are built into every cluster, and nodes that can run sandboxes are added when needed. It works on Nitro-based Intel, AMD and Graviton instances in all commercial AWS Regions. For agents, you can also start a sandbox with no network at all, or allow only certain hostnames.

The catch: you need Kubernetes 1.36 or newer. Without Auto Mode, you have to build a special node image yourself. The post doesn’t give startup time, overhead or pricing. It only says a warm pool of pre-started VMs can hand one out in about two seconds. Hostname rules allow a whole site like github.com, so the agent’s credentials still need to be short-lived and limited.

📢 [**Deploy Frontier AI Models on AWS Trainium with SGLang-Neuron**](https://aws.amazon.com/blogs/machine-learning/deploy-frontier-ai-models-on-aws-trainium-with-sglang-neuron/)\
Alex Nails, Lingyan Hao, Yihao Wang (RadixArk) and Pinak Panigrahi (Annapurna Labs), with the Annapurna Labs inference team

Many teams serve models with SGLang, an open source inference engine, and run it on NVIDIA GPUs. Moving to Trainium, AWS’s own AI chip, has usually meant learning a different serving stack. SGLang-Neuron removes that step. It is a plugin that connects SGLang to Trainium. The core SGLang features, such as RadixAttention and its prefix cache, stay in SGLang itself. The plugin adds the Trainium-specific parts: models, attention, mixture-of-experts and the graph runner. The prefix cache is what lets many requests that share the same opening text, like a long system prompt, reuse work that was already done. You turn it on by installing the plugin and setting `SGLANG_PLATFORM=neuron`.

Under the hood, Trainium shows up as a normal PyTorch device. Models use standard PyTorch operations plus custom Neuron kernels for speed, and `torch.compile` turns these into what runs during serving. The post covers the features large models need: tensor and expert parallelism, which split a model across many chips; chunked prefill; and FP8 KV cache, which stores the model’s short-term memory of a prompt in a smaller format so more fits. It also supports splitting prefill and decode, the two phases of answering a request, onto separate servers. The prefill server reads the prompt and sends its KV cache to the decode server over EFA, AWS’s high-speed network. The decode server then writes the answer. The server exposes an OpenAI-compatible `/v1/chat/completions` endpoint, so your apps don’t need to change.

The catch: this is v0.1.0. The walkthrough serves one model, gpt-oss-120b, on one Trainium3 EC2 instance, and the post gives no throughput, latency or cost figures against GPUs. It doesn’t cover EKS either, so running it on Trainium nodes in a cluster is still up to you. Check the repo for which models and settings are tested before planning a move.

📢 [**Amazon EKS Auto Mode now supports security groups for Pods**](https://aws.amazon.com/about-aws/whats-new/2026/11/amazon-eks-auto-mode-security-groups-for-pods/)

On AWS, a security group is a set of rules that decides who is allowed to connect to what. Until now on EKS Auto Mode, every app running on the same server had to share the same rules. So if only one app should be allowed to reach your database, you had to put it on its own servers, even if they sat mostly empty. Now each app can have its own rules, even when several apps share one server. Your apps can connect to databases like Amazon RDS using the same rules you already use everywhere else in AWS. It needs Kubernetes 1.36 or newer, and there is no extra cost.

How it works: you write a short rule that picks which apps get which security group. You can pick apps by their labels, by the account they run as, or both. EKS then gives each picked app its own network connection on the server, carrying only that app’s rules. All traffic in and out of the app is checked against those rules, separately from the server’s own rules. Traffic between two apps on the same server is checked too. Apps you don’t pick keep using the server’s rules, as before.

The catch: each app with its own rules takes up one of the server’s limited network connections, so a server can run fewer apps. The new limit only applies to new servers, so replace your older ones, or some apps can get stuck waiting to start. Only one rule can match an app. If two match, the app won’t start. Apps that share a rule can’t talk to each other until you add a rule that allows it. A few built-in services skip these rules on purpose, including DNS and health checks. It doesn’t work with third-party networking add-ons. AWS also suggests keeping it to five rules or fewer per server, because more slows down how fast new apps get placed.

📢 [**Amazon EKS Provisioned Control Plane now offers a larger etcd database**](https://aws.amazon.com/about-aws/whats-new/2026/11/amazon-eks-provisioned-control-plane-larger-etcd-database/)

Every Kubernetes cluster keeps a record of everything inside it, such as pods, jobs and events, in a database called etcd. That database has a size limit. When it fills up, you can’t add or change anything in your cluster. This is a real risk for clusters that create many short-lived objects. AWS points to large AI/ML training and inference, batch processing and CI/CD pipelines.

EKS has now raised this limit from 16 GB to 24 GB, 50% more room, on the 4XL and 8XL tiers of Provisioned Control Plane. Provisioned Control Plane is the option where you pay for a bigger, dedicated control plane for the cluster. Existing clusters on those tiers running EKS 1.34 or later get the extra space automatically, with nothing to change.

The catch: it only applies to the 4XL and 8XL tiers. More room also doesn’t fix a cluster that never cleans up after itself. If old jobs and events keep piling up, the database will still fill, just later. So it’s still worth deleting finished jobs on a schedule.

📢 [**AWS Backup now supports resource modifiers for Amazon EKS restores**](https://aws.amazon.com/about-aws/whats-new/2026/11/aws-backup-resource-modifiers-eks/)\
AWS Backup team. Walkthrough by Quinn Winter.

When you restore an EKS backup into a different AWS account or Region, the restored apps still point at the old environment. They keep the old IAM roles, old database endpoints and old ECR image locations, and until now someone had to find and fix each one by hand after every restore. That usually happens in the middle of an outage, which is the worst time to be editing files by hand. Now you write the fixes once as rules in a YAML file, and AWS Backup applies them automatically during the restore. You store the file in S3, and AWS Backup changes each object before creating it in the cluster. Your backup itself never changes. The same rules can also restore a namespace under a new name, so last night’s copy can sit next to the live one while you compare them. It’s available in all commercial AWS Regions and AWS GovCloud (US) Regions, with no extra charge for the feature itself.

The catch: renaming a namespace doesn’t update everything that points to the old name. Role bindings, in-cluster DNS names, IAM trust policies and EKS Pod Identity associations still need fixing by hand. A restore also skips objects that already exist instead of overwriting them. Test your rules on a scratch namespace first. The [walkthrough blog](https://aws.amazon.com/blogs/storage/remap-amazon-eks-namespaces-on-restore-with-aws-backup-resource-modifiers/) shows how, step by step.

Community & Career 🤝

🤝[**Why Does Traditional EKS Take 20 Minutes While Beanstalk Does It in 9?**](https://abdulsomad005.medium.com/why-does-traditional-eks-take-20-minutes-while-beanstalk-does-it-in-9-7171438e277a)\
Abdulsomad005, on Medium

Anyone who has run `eksctl create cluster` knows the wait. Creating the control plane is only the first step. After that come managed node groups, their Auto Scaling Groups, EC2 instances that boot and then register with the cluster, and add-ons like VPC CNI, CoreDNS and the EBS CSI driver. Each step adds time before the cluster can run a pod. The author tried Elastic Beanstalk’s new Cluster Mode, which runs on EKS Auto Mode. The full CloudFormation deployment finished in 8 minutes 59 seconds: a multi-AZ, EKS-backed environment with an Application Load Balancer. Later app deployments took seconds.

The post gives two reasons. First, Auto Mode replaces managed node groups with NodePools and NodeClaims. These launch EC2 instances when workloads need them, so no node group has to bootstrap up front. AWS also runs pod networking, load balancing and EBS storage as managed capabilities, so you do not install or upgrade those add-ons yourself. Second, Beanstalk lets several environments share one cluster. A new app becomes a namespace, a Deployment, a Service and a TargetGroupBinding to an ALB target group, with the image pulled from ECR. No new control plane is created. Namespaces, Auto Mode NodePools and TargetGroupBinding all work on a regular EKS cluster too.

The author also keeps two numbers apart: the first cluster build (minutes) and later app deploys (seconds). A shared cluster does not remove Kubernetes work. Teams still own resource requests and limits, scheduling, workload security and cluster capacity.

🤝 [**Open source inference gateway and EKS setup from ChatLPO**](https://github.com/lyncar98/vllm-scale-to-zero-gateway)\
Lyndon Carlson, ChatLPO

ChatLPO, an AI product for teachers, is getting ready to serve its own AI models instead of only calling someone else’s. Before sending real teacher traffic through them, the team had three problems to solve: keep GPU costs under control, protect sensitive data, and make sure the app keeps working if a model is down. They’ve now open-sourced what they built under the MIT license. It includes a gateway that checks who is calling, sends each request to the right model and tracks usage. It also has a vLLM setup for serving the models, Terraform and Kubernetes files for EKS, and autoscaling examples using KEDA and Karpenter. You can also run the gateway and its tests on a laptop, with no AWS account or GPU.

The most useful part is a mistake they shared. To save money, the GPU can scale down to zero when no one is using it. But the gateway was set up to report “ready” only when the model server was ready. So whenever the GPU scaled to zero, Kubernetes treated the gateway as not ready and stopped sending traffic to it. That happened at exactly the moment the gateway needed to answer and wake the model back up. The lesson: a gateway in front of a model that can scale to zero shouldn’t depend on that model to count as ready.

The catch: the author says it’s not finished yet. The full cycle, where a request arrives, the GPU starts from zero and the app falls back while it waits, still needs end-to-end testing. Treat it as a starter kit, not a production-ready setup.

🤝[**Secure AI Agents on Amazon EKS (online workshop)**](https://aws-experience.com/emea/smb/e/d6b2d/secure-ai-agents-on-amazon-eks)\
\
Building an AI agent demo is easy. The hard questions come right after: what is the agent allowed to do, who is it acting for, and where does the code it writes actually run? This free hands-on workshop shows how to answer those questions on Kubernetes, using open source tools and AWS services you may already run. In the organizer’s words, AI agents are only as trustworthy as the platform they run on.

You’ll run agents, including coding agents like Claude Code, as normal workloads on EKS. Model requests go through an AI gateway, so agents never hold API keys themselves. Tools are reached through an MCP gateway instead of direct connections. Every prompt, tool call, token and dollar is traced. Code written by the model runs in microVM sandboxes with no network access, handed out in seconds from a pool of sandboxes started ahead of time. And the user’s identity is passed along on every tool call, so each tool can check what that user is allowed to do. It’s online, Level 300, on Wednesday 18 November 2026, 09:30 to 11:30 GMT (15:00 to 17:00 IST).

Highlights ✨

✨ [**Automatically Recover from GPU Failures with Amazon ECS Managed Instances**](https://aws.amazon.com/blogs/containers/automatically-recover-from-gpu-failures-with-amazon-ecs-managed-instances/)\
Piyush Mattoo and Nikita Dahiya, AWS

GPUs break more often than most people expect. The post lists memory errors, broken links between GPUs, and a GPU dropping off the server entirely. When that happens, the model stops serving, and an expensive machine sits idle until someone notices and replaces it. Most teams fix this with a homemade chain of scripts that poll the GPU, CloudWatch alarms, a Lambda that pulls the instance out of the load balancer, and a manual or scripted replacement.

ECS Managed Instances now does this for you. It uses NVIDIA’s DCGM, a GPU health monitor that runs on every GPU instance, with no extra agent or setup. The key idea is sorting faults into two kinds. Serious hardware faults, identified by NVIDIA error codes called XIDs, mark the instance as impaired and get it replaced. Software-level faults only restart the app, not the machine, and show up as CloudWatch metrics. Replacement is “start before stop”: ECS stops sending new work to the bad instance, launches a healthy one, lets existing tasks finish, and only then terminates the broken one. To avoid mass replacements when many GPUs fail together, no more than 20% of instances can be drained at once. In their test, the fault was detected in about 2 minutes and the full replacement took about 8.

The catch: replacing the machine is the fast part. A large model then took 15 to 20 minutes to start, depending on weight download and GPU load time. Any request in progress on the failed instance is lost, so your app needs a retry, such as a queue. DCGM and XID codes come from NVIDIA, though, so the same way of sorting faults works for EKS GPU nodes too.

✨ [**Introducing Infinity: A Runtime for Extreme Agent Concurrency**](https://aws.amazon.com/blogs/opensource/introducing-infinity-a-runtime-for-extreme-agent-concurrency/)\
Shadaj Laddad, AWS (Hydro project, with UC Berkeley)

Most of an agent’s life is spent waiting. It waits on builds, pull request events or human approvals. Most agent frameworks run a loop that calls the model, calls a tool and then waits. During that wait, the agent keeps holding a process and its memory, and it can’t respond to anything else. At scale, you end up paying for thousands of agents that are mostly doing nothing.

Infinity, a research runtime, changes this. When an agent calls a tool, Infinity sends the call off, saves the conversation and pauses the agent. When the result comes back, it picks the agent up from where it stopped. This works because the conversation history already holds everything the agent needs to continue, so the runtime can save it, drop everything in memory, and resume the agent later from any process that can read the store. Each agent runs in short steps: load the history, run one model call, save the output, and send at most one tool call. A step never waits on a tool or a timer. The result: 75,000 agents running at once in the 8 GB of a Raspberry Pi 5, using about 100 KB per idle agent. The AWS reference setup has no always-on servers at all: an SQS queue feeds Lambda, conversations live in Aurora DSQL, and DynamoDB tracks duplicate messages.

The catch: it is an early research release. The benchmark used a simulated model and in-memory storage, so it measures the runtime’s overhead, not real model calls. Examples are in Rust. The post doesn’t cover isolation, security boundaries or cost in detail, and it doesn’t mention Kubernetes or EKS. The authors also say it’s an open question how these out-of-order events affect model reasoning, since models are mostly trained on simple step-by-step tool use.

✨ [**Raise the network limits before you benchmark Nitro Sandboxes**](https://docs.amazonaws.cn/eks/latest/userguide/sandboxing-resource-isolation.html)

Many apps can share one server, so Nitro Sandboxes cap how much network each sandbox can use by default. That way one busy AI agent can’t slow down the others. But the default caps are low. Each sandbox gets 100 Mbps in and 100 Mbps out, and 1,500 network packets per second in each direction. At 1,500 packets per second, the most a sandbox can push is about 102 Mbps. So if you load-test a busy service on day one, you’re measuring the cap, not the sandbox.

The fix is a few annotations on the pod. The trap is that speed and packet count are limited separately, so you have to raise both before you see any improvement. Raising only one changes nothing. The docs show raising both speed limits to 1G and both packet limits to 15000 to get about 1 Gbps. You can also set a limit to “disabled” to turn it off. Don’t set it to 0, though: the pod will fail instead of becoming unlimited. Other defaults are worth checking too. DNS lookups are capped at 100 per second, with a maximum of 512. Each sandbox can hold 4,096 outbound connections open at once.

✨ [**Better Feedback for Building with Agents**](https://aws.amazon.com/blogs/aws-insights/better-feedback-for-building-with-agents/)\
Dr. Matt Wood, AWS

AI agents that write code make mistakes, and the longer a mistake goes unnoticed, the more work gets built on top of it. The post explains why that’s hard to fix today: testing in the real cloud is slow and costs money, and mock tests only cover what someone thought of in advance. To fix this, AWS launched AWS Emulator. It is a local copy of hundreds of AWS service APIs, free for Linux and packaged as a Docker container. Agents use the same AWS tools they normally would, without creating real resources or paying for them. Because each copy is separate, an agent can try two different approaches side by side, run the same tests on both, and show you the results.

🎉 **Sponsor Section**

At the moment, we don’t have a sponsor for this edition, but we look forward to working with companies and organizations that support the EKS & AI Infrastructure community in future editions. If you or your company is interested in sponsoring, please contact us at 📧 [**thecloudtechforall@gmail.com**](mailto:thecloudtechforall@gmail.com)

📝 **Words from the Author\
**This edition ended up being mostly about one question: when an AI agent writes and runs its own code, where does that code actually run, and what stops it from reaching things it shouldn’t? Nitro Sandboxes giving each pod its own small VM, warm pools that hand out a ready sandbox in about a second, and AWS running a whole workshop on securing agents on EKS. A year ago, most of these were ideas. Now they’re things you can use. For me, that’s a sign that running agents safely is no longer just an AI problem. It’s a platform problem, and that puts it right in this community’s hands.

It’s also where most of my own time is going right now. I’m writing a book on this exact topic, *Mastering Agent Sandboxing on Amazon EKS*. It covers what I’ve learned about isolating agents, controlling what they can reach, and what holds up in a real cluster versus what only works in a demo. I’ll share more about it soon. Apart from the code talk, I’ll keep sharing what I learn here first.

Closer to home, we’re hosting our next AWS User Group Vadodara meetup this Saturday, 21 November, from 10:00 AM to 1:00 PM IST at PMC, Alembic Campus, Vadodara. Ashish Kumar (CTO, CloudZenia) will talk about the AWS DevOps Agent. Jay Gandhi (AI Technical Architect, PMC) will share how PMC built its own LLM gateway to control token costs and enforce policies across teams. It’s free and in person, but you need to RSVP to get in: [RSVP on Meetup](https://www.meetup.com/aws-community-vadodara/events/317220111/). I first came to this group as someone sitting in the audience. More than six years and 50+ meetups later, Saturdays like this are still my favourite part of the community. If you’re in or near Vadodara, come say hi.

And in two weeks, it’s re:Invent. I’m already excited. After a year this full of agent and infrastructure launches, I’m curious to see what comes next for EKS and AI infrastructure. Expect a re:Invent edition that cuts through the announcements and picks out what actually matters for platform teams.

One last thing: the Kindle edition of *Mastering Containers on AWS* is on sale this weekend, ₹105 on Amazon.in and $5 on Amazon.com. If you’ve read it, an honest review on Amazon would mean a lot to me, because it helps other engineers decide whether the book is for them. And if you know someone just getting started with containers on AWS, please send it their way.

Thank you for reading, and for being part of this.

Adit