August 2026 Summaries

LocalStack for AWS 2026.08.0 introduces emulation for Lambda Durable Functions, including checkpointing, retries, callbacks, execution management, and multiple runtimes, though it requires a paid plan and omits some AWS monitoring, encryption, quota, and rate-limit behavior. The release also adds CloudFront KeyValueStore support for viewer-request CloudFront Functions, makes the native ELBv2 provider the default with automatic state migration and closer AWS-compatible validation and responses, and expands Verified Permissions with OIDC token authorization, policy-store aliases, enhanced Cedar support, pagination, and CloudFormation updates. RDS gains Aurora and Data API capabilities, refreshed engine metadata, parameter-group operations, and cluster improvements, while OpenSearch 3.7 becomes the default for new domains and supports upgrades and richer domain configuration updates. CloudFormation now supports in-place updates for numerous resources across API Gateway, analytics, identity, security, networking, scheduling, and other AWS services, alongside compatibility fixes for CDK and Amplify workflows. Additional changes restore the Docker image base to Debian trixie, add service-specific Docker flags, resolve runtime and memory issues, and improve fidelity across S3, IAM, STS, EventBridge, MSK, AppSync, SNS, CloudWatch Logs, and other providers. The release also announces removal of unsupported LocalStack 0.12.x and several legacy images on September 25, 2026, removes the EC2 Libvirt VM manager, deprecates older AMIs and Amazon Pinpoint, and plans to retire the legacy ELBv2 provider.

LocalStack enables developers to locally emulate AWS services and test containerized, message-driven applications without repeatedly building, pushing, and deploying images to AWS. The tutorial demonstrates a Go application running as an ECS Fargate task that long-polls an SQS queue and stores processed messages in DynamoDB, with infrastructure provisioned through AWS CDK. LocalStack emulates ECS/Fargate using Docker, routes CDK and AWS CLI commands through its `lstk` tools, injects local service endpoints into containers, and allows applications to use standard AWS SDKs and APIs. After starting LocalStack with an authentication token, users deploy the stack, send a test SQS message, and confirm that the Fargate worker writes it to DynamoDB. The workflow can also be automated with a Jest integration test that sends a unique message, polls DynamoDB, and verifies the stored result, making it suitable for repeatable local and CI/CD testing while reducing cloud costs, deployment delays, and configuration drift.

AWS MCP servers can be redirected from real AWS accounts to LocalStack by using an AWS profile with a LocalStack endpoint, allowing AI coding agents to build, validate, deploy, test, and recover from mistakes without cloud costs or production risk. In a demonstration, an agent used AWS serverless and infrastructure-as-code MCP servers to create a webhook service with API Gateway, Lambda, SQS, DynamoDB, Secrets Manager, KMS, and constrained IAM policies, while validation and compliance checks caught CloudFormation description-length errors before deployment. After deploying the application through SAM to LocalStack, the agent verified signature authentication and idempotent DynamoDB writes, then added a Lambda MCP server that exposed the deployed functions as callable agent tools. An adversarial test suite of 30 cases found seven issues, including a significant worker failure in which a malformed but valid JSON value caused an uncaught TypeError, failing an entire SQS batch and potentially sending valid messages to the dead-letter queue alongside poison records. The agent diagnosed the problem from logs, changed the worker to validate message structure and retry only transient failures, redeployed it, and confirmed that malformed records were discarded while valid records in the same batch processed successfully. The experiment took roughly 26 minutes, 74 MCP tool calls, and $13.26 in model usage, illustrating how LocalStack can provide a low-risk environment for autonomous agents to exercise AWS-oriented development workflows.

An experiment used Claude Code with the LocalStack MCP server, IAM enforcement, and App Inspector tracing to diagnose and repair a CDK-based S3, SQS, Lambda, and DynamoDB inventory pipeline without accessing a real AWS account. The pipeline’s original batch-processing behavior caused one malformed record to fail an entire SQS batch repeatedly, producing duplicate DynamoDB writes for healthy records and eventually sending all records to the dead-letter queue. After deploying and reproducing the issue in LocalStack, the agent used traces to identify DynamoDB type validation as the failure source and IAM events to rule out permission problems. It fixed the system by enabling Lambda partial batch responses, catching failures per message, validating malformed data before writing, and replacing random record IDs with deterministic keys to make writes idempotent. Verification showed that healthy rows were stored once, the malformed row alone reached the DLQ after the configured retries, and production queue settings were restored; the run reportedly took about 17 minutes, used 32 MCP calls, and incurred no cloud charges.

AI coding agents can provision infrastructure, execute code, and interact with cloud services autonomously, creating risks of unexpected costs, security misconfigurations, production data corruption, and conflicts between agents when they use real credentials and shared environments. The discussion distinguishes code execution sandboxes, model evaluation tools, data sandboxes, and infrastructure sandboxes, arguing that only the latter prevents generated code from reaching real cloud services. LocalStack is presented as an infrastructure sandbox that locally emulates AWS services such as S3, Lambda, DynamoDB, SQS, and IAM, allowing agents to test realistic APIs, errors, and permissions without cloud spending or production impact. Used alongside execution sandboxes, it can isolate both an agent’s runtime and its cloud calls, while ephemeral environments prevent agents from interfering with each other. The example describes Claude Code building an S3-to-Lambda-to-SQS file-processing pipeline in LocalStack, encountering an IAM denial for missing SQS permissions, diagnosing it through App Inspector and an IAM policy analyzer, then correcting the policy and completing the workflow locally.

Service Control Policies (SCPs) in AWS Organizations act as critical guardrails by limiting permissions for accounts and organizational units, but their impactful scope can cause apprehension among teams due to the potential for widespread disruptions if misconfigured. This document explores how LocalStack's 2026.06.0 release enhances SCP usability by incorporating SCP evaluation into its IAM enforcement engine, allowing for the creation of a local AWS organization to safely test SCPs with specific conditions like region locks, IMDSv2 enforcement, and tag requirements. The tutorial guides users through setting up a sandbox environment, attaching an SCP with condition-based rules, and simulating workloads to verify SCP effectiveness through denial messages and an enhanced policy simulator. This approach provides a practical solution for testing SCPs outside of AWS's limitations, facilitating the integration of SCP evaluations into continuous integration workflows while highlighting new features like numeric and negated string condition operators for comprehensive policy testing.