The week of 14 September was AWS selling platform engineering as a product: Elastic Beanstalk Cluster Mode puts a portfolio of applications on shared, fully managed EKS, and the new getting-started experience hands a new builder a pre-configured project instead of an empty account. Underneath, the compute got cheaper in two directions (T8i instances, ARM64 in ECS Express Mode), PrivateLink gained a tunnel endpoint for sharing whole network segments, and two identity changes landed that will quietly break monitoring if you ignore them. Migration tooling was quiet this week (nothing from AWS Transform or DMS), so the platform story leads.

Elastic Beanstalk Cluster Mode: the PaaS argument, again

On 17 September AWS Elastic Beanstalk introduced Cluster Mode: multiple applications run on shared infrastructure powered by Amazon EKS, fully managed, with one operational baseline. You upload source in Java, .NET, Python, Node.js, PHP, Ruby, or Go (or a Dockerfile, or an image), Beanstalk containerizes it with Cloud Native Buildpacks when needed, and the environment gets traffic-shifting deployments with automatic rollback, event-driven autoscaling, Secrets Manager integration, OpenTelemetry observability, and AI-assisted troubleshooting. Standard and Cluster Mode environments coexist inside the same application, so you migrate one environment at a time.

The per-application cost argument is the one every internal platform team has made to fund a shared EKS cluster. The difference is who runs it: AWS, for the life of the workload, and you never see a node, a kubeconfig, or an upgrade window.

With twenty small services and no appetite for Kubernetes, Cluster Mode is probably the right default. If you have a platform team that already owns EKS, Cluster Mode competes with them for the same workloads and offers less control: no custom admission policies, no node tuning, no choice of CNI. The failure mode is the one shared platforms always have, a baseline upgrade that is right for nineteen applications and wrong for the twentieth, except now the twentieth cannot pin anything. Pilot it with the applications you would be happy to lose control over.

Cheaper compute, two ways

On 17 September EC2 T8i instances went generally available: custom sixth-generation Intel Xeon 6, sixth-generation Nitro cards, four sizes (nano, micro, small, medium), up to 30% better price performance than T3, up to 70% more compute, 1.25x the network bandwidth, 2.4x the EBS bandwidth. Same CPU credit system with Standard and Unlimited modes, so the move from T3 is a change of instance type and nothing else. t8i.micro and t8i.small are in the Free Tier.

On 18 September ECS Express Mode added ARM64 as a CPU architecture, so the "give me a URL for this image" path can land on Graviton, which AWS rates at up to 40% better price-performance than x86. Configurable for new and existing Express Mode services through console, CLI, SDK, and IaC.

Both save money only if someone makes the change. The T3 fleet in most accounts is bastions, build runners, and forgotten internal tools; a Terraform variable change and an instance refresh is the whole job. For Express Mode ARM64, the prerequisite is a multi-arch image, and the failure mode is a base image or a native dependency that only ships amd64. Build with docker buildx build --platform linux/amd64,linux/arm64 and let the manifest list do the work, then flip the architecture.

PrivateLink Tunnel Endpoints: share a CIDR, not a service

On 18 September AWS PrivateLink announced Tunnel Endpoints, a new VPC endpoint type. Previously, sharing resources with an external party meant one Resource Configuration per resource. Now a Resource Configuration can represent a CIDR range in your network; you share it through AWS RAM, and the other side creates a tunnel endpoint and uses GENEVE encapsulation to reach anything inside that range. Hourly charge per tunnel endpoint plus a per-GB charge for data processed.

This fills the gap between PrivateLink (one service, one endpoint, no routing exposure) and Transit Gateway or peering (full routing, both ways, and a CIDR negotiation). A vendor that needs forty hosts in your management subnet used to force the heavyweight option; now they get a tunnel into exactly the range you named.

The per-GB charge makes this a control-plane path, not a bulk-data one; model the cost before someone routes backups through it. And "a CIDR range" is a broader grant than "a service": the security group and NACL discipline inside that range is now part of your external attack surface, so treat the range you expose as a DMZ and size it accordingly.

Two identity changes that break dashboards

On 14 September root user sign-in started being served from US East (Ohio) and US West (Oregon) as well as N. Virginia, with traffic distributed across all three. Good for resilience, but the CloudTrail ConsoleLogin event for a root sign-in is now recorded in whichever Region processed it. If your root-login alarm is a metric filter on a us-east-1 trail, it now catches roughly a third of root logins. Move it to an organization trail or add the other two Regions this week.

On 15 September STS collapsed its session token limits into a single 4,096-byte limit, replacing separate caps on token size and on passed-in session policies and tags. STS now returns the token size and percentage utilization, logs them to CloudTrail, and publishes CloudWatch metrics; a new optional parameter mints deliberately large tokens so you can test whether your proxies and headers survive them. If you have ever hit "packed policy too large", this is the fix, and the test parameter proves your stack handles the ceiling before a session tag pushes you into it.

Also this week

The throughline

Cluster Mode and the new builder experience are the same product at two scales: AWS picks the defaults and takes the operational responsibility that comes with them. The cost is that defaults chosen for everyone fit nobody perfectly, and the places where that bites (node tuning, a root-login alarm that assumed one Region, a session token that assumed two limits) are exactly the places this week's smaller launches touched. The platform work does not disappear when AWS runs the platform; it moves from building the thing to knowing which of its defaults are wrong for you.

Read this next

For the AI and agent reading of the same week, see ercan.ai. If your team needs hands-on help with AWS, cloud architecture, CI/CD pipelines, Linux, GitHub or GitLab, and the platform work around them, the consulting side lives at ercanermis.com.

References