Adventures in Cloud

AWS re:Invent 2025: My Favorite Announcements and What They Mean for Infrastructure

Posted December 5, 2025 by Trevor Roberts Jr ‐ 5 min read

AWS re:Invent 2025 delivered announcements that will reshape how we build infrastructure. I'm excited about several of them. Let me share my thoughts on the announcements that got my attention and what they mean for infrastructure automation.

Introduction

I spent the better part of December at AWS re:Invent 2025. The conference was packed with announcements, and while not all of them will move the needle for most infrastructure engineers, a few really stood out to me. These are the ones I think will have lasting impact on how we build and operate infrastructure on AWS.

Let me walk through my favorites and the infrastructure implications of each.

1. EC2 Graviton4 and the ARM Revolution Continues

The Graviton4 instances are coming, and they're even more performant than their predecessors. AWS is pushing hard on this ARM-based processor roadmap, and for good reason.

Why this matters: The cost-to-performance ratio keeps improving. If you're still running all your infrastructure on AMD/Intel instances out of habit, you're likely overspending. Graviton instances offer 15-20% better compute performance per dollar compared to comparable x86 instances.

For infrastructure teams:

# Terraform: Consider Graviton4 for your next instance family upgrade
resource "aws_instance" "app_server" {
  ami           = data.aws_ami.amazon_arm64.id
  instance_type = "t4g.xlarge"  # Graviton3 today, upgrade path to Graviton4
  
  # Ensure your AMIs support ARM64
  metadata_options {
    http_tokens = "required"
  }
  
  tags = {
    Architecture = "arm64"
    Processor    = "Graviton"
  }
}

The key is ensuring your container images and software support ARM64. If you haven't already, adding multi-architecture build pipelines to your CI/CD is no longer optional—it's a competitive advantage.

2. Lambda Extensions and Custom Runtimes Get More Power

The new Lambda Extensions framework makes it easier to integrate observability, security, and custom logic into your Lambda functions without modifying application code.

Why this matters: This democratizes advanced patterns like distributed tracing, security scanning, and compliance checks. You can now package these as Lambda Extensions and apply them across your organization.

For infrastructure teams:

# Lambda Extension: Automatic distributed tracing injection
import json
import os
import requests

class TraceExtension:
    def __init__(self):
        self.extension_id = None
        self.api_version = "2022-07-01"
        self.base_url = f"http://{os.getenv('AWS_LAMBDA_RUNTIME_API')}/{self.api_version}"
    
    def register(self):
        url = f"{self.base_url}/extension/register"
        payload = {
            "events": ["INVOKE", "SHUTDOWN"]
        }
        response = requests.post(url, json=payload)
        self.extension_id = response.headers.get("Lambda-Extension-Identifier")
        return self.extension_id
    
    def next_event(self):
        url = f"{self.base_url}/extension/event/next"
        headers = {"Lambda-Extension-Identifier": self.extension_id}
        response = requests.get(url, headers=headers)
        return response.json()

# Deploy as a Lambda Layer and apply to all functions
# This is significantly cleaner than modifying every function

This is infrastructure-as-code friendly and reduces toil significantly.

3. ElastiCache Serverless Ships Generally Available

Managed Redis and Memcached without infrastructure management overhead. No more capacity planning for cache layers.

Why this matters: For teams that don't want to manage ElastiCache cluster infrastructure, this removes operational burden. The pay-per-request pricing smooths out bursty cache workloads.

For infrastructure teams:

# ElastiCache Serverless: No cluster management
resource "aws_elasticache_serverless_cache" "session_cache" {
  name     = "my-session-cache"
  engine   = "redis"
  family   = "redis7"
  
  data_storage {
    maximum = 10  # In GB
  }
  
  daily_snapshot_time = "03:00"
  
  security_group_ids = [aws_security_group.cache.id]
  subnet_ids         = var.private_subnet_ids
}

The tradeoff: You lose fine-grained control over cluster configuration, but gain operational simplicity. For most workloads, this is a win.

4. S3 Express One Zone: The High-Performance Tier

S3 Express One Zone provides single-digit millisecond latency for extremely demanding workloads. This is a new S3 storage class specifically engineered for performance.

Why this matters: If you have performance-critical workloads that previously required external caches or databases, S3 Express One Zone might replace them. The use case is narrow, but it's genuinely transformative for those who need it.

For infrastructure teams:

# S3 Express One Zone: High-performance storage
resource "aws_s3_bucket" "performance_critical" {
  bucket = "performance-critical-data"
}

resource "aws_s3_directory_bucket" "express_oneaz" {
  bucket = "my-express-bucket--usw2-az1--x-s3"
  location_name = "usw2-az1"
}

# Usage example: Real-time analytics, ML feature stores, etc

The catch: Only one availability zone, and pricing is higher. This is for specific use cases, not general-purpose storage.

5. Trainium and Inferentia Chips: AI Infrastructure

AWS is getting serious about making custom silicon accessible. Trainium for training and Inferentia for inference are now more accessible to organizations actually running on-prem ML workloads.

Why this matters: The total cost of ownership for running AI workloads drops significantly with custom silicon. If you're running transformer models or inference workloads at scale, investing time in Trainium/Inferentia is worth it.

For infrastructure teams:

# EC2 with Trainium acceleration
resource "aws_instance" "ml_training" {
  ami           = "ami-0trainium-optimized"
  instance_type = "trn1n.32xlarge"  # 16 Trainium accelerators
  
  tags = {
    Purpose = "model-training"
    Hardware = "trainium"
  }
}

# EC2 with Inferentia acceleration  
resource "aws_instance" "ml_inference" {
  ami           = "ami-0inferentia-optimized"
  instance_type = "inf2.xlarge"  # Inferentia2 chips
  
  tags = {
    Purpose = "model-inference"
    Hardware = "inferentia"
  }
}

If you're on the fence about moving ML workloads to AWS, this announcement means your economics just improved.

6. Bedrock Model Context Window Extensions

Bedrock models now support much larger context windows, enabling new patterns for RAG and document analysis applications.

Why this matters: Larger context windows mean fewer API calls to retrieve and process information. Your RAG applications become simpler and cheaper to operate.

7. AppConfig Multi-Tenancy Features

AppConfig got significant enhancements for managing configurations across multiple environments and deployment strategies.

For infrastructure teams, this means:

# AppConfig: Deploying gradual rollouts of configuration changes
resource "aws_appconfig_deployment_strategy" "gradual_rollout" {
  name                           = "gradual-10-percent"
  type                           = "LINEAR"
  deployment_duration_in_minutes = 30
  final_bake_time_in_minutes     = 10
  growth_factor                  = 10
}

resource "aws_appconfig_deployment" "feature_flag_update" {
  application_id             = aws_appconfig_app.main.id
  environment_id             = aws_appconfig_environment.production.id
  configuration_profile_id   = aws_appconfig_config_profile.feature_flags.id
  deployment_strategy_id     = aws_appconfig_deployment_strategy.gradual_rollout.id
  configuration_version      = aws_appconfig_hosted_config_version.latest.version_number
  
  tags = {
    Environment = "production"
  }
}

Configuration governance just became part of infrastructure automation rather than a manual process.

The Bigger Picture

What strikes me about this year's announcements is the theme: abstraction and managed services continue to win. AWS is pushing Graviton, serverless options, managed silicon, and less infrastructure management across the board.

This is great news for infrastructure teams because:

  1. Less undifferentiated heavy lifting - You focus on business logic, not infrastructure tuning
  2. Better cost efficiency - Managed services and custom silicon drive costs down
  3. Operational simplicity - Fewer moving parts to manage and debug
  4. Infrastructure-as-Code friendly - Most of these services Terraform support

What I'm Watching

A few things I'm keeping an eye on:

  • Bedrock pricing: As models get more capable, will pricing remain competitive?
  • Graviton ecosystem: How quickly do third-party ISVs add ARM64 support?
  • S3 Express One Zone adoption: Will this gain traction or remain a niche service?
  • VPC Lattice maturity: Will teams migrate from PrivateLink?

Wrapping Things Up...

re:Invent 2025 delivered announcements that will shape infrastructure strategies for years to come. Whether you're optimizing costs with Graviton, simplifying operations with serverless options, or leveraging custom silicon for AI workloads, there's something that will impact how you build.

The consistent theme? Managed services and abstraction continue to win. The infrastructure teams that adapt to this reality will find themselves with more time for strategic work and less time managing infrastructure minutiae.

If you were at re:Invent too, I'd love to hear which announcements excited you most!

If you found this article useful, let me know on BlueSky or on LinkedIn!