Imagine you are developing a serverless application using Amazon S3, AWS Lambda, DynamoDB, and SQS.
You write some code, deploy your infrastructure, test the application, discover a configuration issue, fix it, and deploy again.
Then you make another small change.
Another deployment.
Another waiting cycle.
And sometimes, another unexpected AWS bill.
Wouldn't it be better if you could develop and test much of your AWS application locally before deploying it to the cloud?
That's exactly what local AWS emulation makes possible.
For years, developers have used tools such as LocalStack, Moto, and DynamoDB Local to simulate AWS services locally.
But November 2026 brought an interesting development: AWS announced its own local AWS API emulator.
Now we have a new comparison:
AWS Emulator vs LocalStack — which one should developers choose?
Let's explore the problem, compare both technologies, and build a practical project.
1. The Problem: Cloud Development Can Be Slow and Expensive
Consider a typical serverless application:
- Amazon S3 for file storage
- AWS Lambda for processing
- Amazon DynamoDB for application data
- Amazon SQS for asynchronous messaging
- Amazon SNS for notifications
- Amazon CloudWatch for monitoring
Testing one Lambda function is relatively simple.
Testing the entire workflow is different.
For example:
- A customer uploads a file.
- An S3 event triggers processing.
- Lambda processes the file.
- DynamoDB stores the result.
- SQS handles asynchronous tasks.
- SNS sends a notification.
Testing this complete workflow repeatedly against real AWS resources can introduce several challenges.
Repeated deployments: Small code changes can require additional deployment cycles.
Unexpected costs: Storage, requests, compute, and data transfer can generate charges.
Integration testing: Individual functions may work perfectly while service-to-service communication fails.
AI coding agents: AI agents can generate code quickly, but repeatedly deploying to AWS can slow down their feedback loop.
The solution is not to stop using AWS.
The solution is to improve the development process.
2. What Is an AWS Emulator?
An AWS emulator provides local endpoints that imitate supported AWS APIs.
Instead of sending requests to real AWS services, your application sends requests to a local endpoint.
Traditional workflow:
Application | v AWS SDK | v AWS Endpoint | v Real AWS Service Local development workflow:
Application | v AWS SDK | v Local Endpoint | v Emulated AWS Service Your application can continue using familiar AWS SDK operations while you configure it to communicate with a local environment.
This makes local development and integration testing easier.
3. Meet AWS Emulator
On November 11, 2026, AWS announced AWS Emulator, an official local AWS API emulator.
Its capabilities include:
- AWS CLI and AWS SDK support.
- Local AWS API endpoints.
- Local development and CI workflows.
- Published API fidelity tests and scores.
- Identification of unsupported API operations.
- An installation skill for AI coding agents.
- No additional emulator service fee.
One particularly interesting feature is API fidelity testing.
AWS Emulator aims to reproduce supported AWS API behavior, including successful responses and AWS-style errors.
If an operation is not implemented, it can return NotImplemented.
This is useful because developers can identify which operations are available rather than assuming every AWS service feature is supported.
Documentation: https://docs.aws.amazon.com/emulator/
4. Meet LocalStack
LocalStack is an established local cloud development platform.
It provides local emulation for supported AWS services and integrations with common development tools.
Its capabilities include:
- Local application development.
- Integration testing.
- CI/CD workflows.
- Terraform integration.
- AWS CDK integration.
- AWS SAM integration.
- Developer interfaces and tooling.
- AI-agent development workflows.
LocalStack offers a broader development ecosystem, with feature availability depending on its product edition and plan.
Documentation: https://docs.localstack.cloud/
5. AWS Emulator vs LocalStack
Here is a practical comparison.
| Feature | AWS Emulator | LocalStack |
|---|---|---|
| Primary focus | Official AWS API emulator | Local cloud development platform |
| AWS CLI | Yes | Yes |
| AWS SDK | Yes | Yes |
| Local development | Yes | Yes |
| Integration testing | Supported operations | Supported services |
| Fidelity information | Published fidelity tests | Service-specific compatibility |
| AI agent integration | Dedicated emulator skill | Agent integrations |
| Infrastructure tools | Depends on supported workflow | Terraform, CDK, SAM integrations |
| Developer interface | CLI and API endpoint | CLI, API endpoint and web interface |
| Multi-cloud direction | AWS-focused | Broader product direction |
| Production replacement | No | No |
The key difference:
AWS Emulator focuses on AWS API compatibility and fidelity. LocalStack provides a broader local development environment.
Neither is automatically the best choice for every application.
6. What Is New in November 2026?
There are two developments worth watching.
AWS Emulator announcement
AWS announced its official local emulator on November 11, 2026.
It introduces a local AWS API endpoint, published fidelity tests, and an AI coding-agent installation skill.
Its default HTTPS endpoint is:
https://127.0.0.1:9297 The emulator generates its own credentials and configuration files.
LocalStack continues expanding
LocalStack's 2026.09.0 and 2026.10.0 releases introduced additional capabilities and improvements involving:
- S3 Files.
- DynamoDB.
- Kinesis.
- Lambda Web Functions.
- EventBridge Scheduler.
- API Gateway.
- CloudFormation.
LocalStack also introduced a unified distribution for LocalStack for AWS beginning in March 2026. Developers should review its current authentication-token and licensing requirements.
The broader trend is clear: local cloud development is becoming increasingly important.
7. Real-World Use Cases
Where can developers benefit?
Serverless application development
Build and test applications using S3, Lambda, DynamoDB, and API Gateway locally.
Data engineering
Test supported event-driven workflows involving S3, SQS, Lambda, and application databases.
CI/CD automation
Start a local environment, provision resources, execute integration tests, and discard the environment after testing.
AI coding agents
Allow AI agents to create resources, execute AWS CLI commands, test application behavior, and troubleshoot issues locally.
Cloud education
Students and independent developers can experiment with supported AWS APIs without deploying real cloud infrastructure for every exercise.
8. Hands-On Project: LocalCloud Lab
Let's build something practical.
Project: Serverless Order Processing Platform
Imagine an e-commerce company receiving customer orders.
Whenever a customer submits an order:
- The application receives the order.
- S3 stores the order JSON file.
- SQS receives an order event.
- Lambda processes the order.
- DynamoDB stores the processing status.
- SNS sends a notification.
Architecture
Customer | v Order Submission | v Amazon S3 (Order JSON) | v Amazon SQS (Order Event) | v AWS Lambda (Order Processor) | +-----+-----+ | | v v DynamoDB Amazon SNS (Order Status) (Notification) Technology stack
- Python
- Boto3
- AWS Emulator or LocalStack
- Amazon S3
- Amazon SQS
- AWS Lambda
- Amazon DynamoDB
- Amazon SNS
- Docker
- Pytest
- AWS SAM
- GitHub
Step 1: Create the project structure
localcloud-lab/ │ ├── app/ │ ├── order_processor.py │ ├── order_service.py │ └── config.py │ ├── infrastructure/ │ └── template.yaml │ ├── tests/ │ ├── test_orders.py │ └── test_processor.py │ ├── scripts/ │ └── create_resources.py │ ├── requirements.txt ├── docker-compose.yml ├── .env.example ├── README.md └── .gitignore Step 2: Install dependencies
Create requirements.txt:
boto3 pytest python-dotenv Install:
python -m venv .venv # Linux / macOS source .venv/bin/activate # Windows PowerShell .venv\Scripts\Activate.ps1 pip install -r requirements.txt Step 3: Create the order processor
Create app/order_processor.py:
import json import os import boto3 ENDPOINT_URL = os.getenv("AWS_ENDPOINT_URL") REGION = os.getenv("AWS_REGION", "us-east-1") session = boto3.Session( region_name=REGION ) s3 = session.client( "s3", endpoint_url=ENDPOINT_URL ) dynamodb = session.resource( "dynamodb", endpoint_url=ENDPOINT_URL ) table = dynamodb.Table("Orders") def process_order(event, context=None): for record in event.get("Records", []): message = json.loads( record["body"] ) order_id = message["order_id"] response = s3.get_object( Bucket="localcloud-orders", Key=f"{order_id}.json" ) order = json.loads( response["Body"].read() ) table.put_item( Item={ "order_id": order_id, "customer_id": order["customer_id"], "amount": order["amount"], "status": "PROCESSED" } ) return { "statusCode": 200, "body": "Order processing completed" } This demonstrates the core integration between SQS, S3, and DynamoDB.
For production, add schema validation, idempotency, structured logging, retries, and dead-letter queue handling.
Step 4: Create local resources
Create scripts/create_resources.py:
import os import boto3 endpoint = os.getenv("AWS_ENDPOINT_URL") region = os.getenv("AWS_REGION", "us-east-1") session = boto3.Session(region_name=region) s3 = session.client( "s3", endpoint_url=endpoint ) sqs = session.client( "sqs", endpoint_url=endpoint ) dynamodb = session.client( "dynamodb", endpoint_url=endpoint ) s3.create_bucket( Bucket="localcloud-orders" ) sqs.create_queue( QueueName="localcloud-order-queue" ) dynamodb.create_table( TableName="Orders", KeySchema=[ { "AttributeName": "order_id", "KeyType": "HASH" } ], AttributeDefinitions=[ { "AttributeName": "order_id", "AttributeType": "S" } ], BillingMode="PAY_PER_REQUEST" ) print("Local AWS resources created.") This is a minimal first-run setup. Make resource provisioning idempotent before using it in repeated CI runs.
Step 5: Start AWS Emulator
The AWS Emulator endpoint is:
https://127.0.0.1:9297 Follow the official installation guide for your operating system.
For example, on Amazon Linux 2023:
PKG=https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest sudo dnf install -y \ $PKG/aws-emulator-x86_64.rpm Start it:
aws-emulator Configure your environment:
export AWS_ENDPOINT_URL=https://127.0.0.1:9297 export AWS_SHARED_CREDENTIALS_FILE=~/.aws/emulator/9297/emulator_credentials export AWS_CONFIG_FILE=~/.aws/emulator/9297/config export AWS_EC2_METADATA_DISABLED=true export AWS_DISABLE_HOST_PREFIX_INJECTION=true export AWS_REGION=us-east-1 export AWS_DEFAULT_REGION=us-east-1 unset AWS_ACCESS_KEY_ID unset AWS_SECRET_ACCESS_KEY unset AWS_SESSION_TOKEN unset AWS_PROFILE Check emulator health:
curl \ --cacert ~/.aws/emulator/9297/ca.pem \ https://127.0.0.1:9297/__admin/health Verify the AWS CLI:
aws sts get-caller-identity The emulator uses this account ID:
000000000000 See the official getting-started guide for the latest installation instructions.
Step 6: Run LocalStack as an alternative
Create a docker-compose.yml:
services: localstack: image: localstack/localstack container_name: localcloud-localstack ports: - "4566:4566" environment: SERVICES: s3,sqs,dynamodb,sns,lambda AWS_DEFAULT_REGION: us-east-1 LOCALSTACK_AUTH_TOKEN: ${LOCALSTACK_AUTH_TOKEN} volumes: - "/var/run/docker.sock:/var/run/docker.sock" - "./localstack-data:/var/lib/localstack" Configure the authentication token according to the current LocalStack documentation.
Start the service:
docker compose up -d Configure the endpoint:
export AWS_ENDPOINT_URL=http://localhost:4566 export AWS_REGION=us-east-1 Now Boto3 can communicate with LocalStack.
Step 7: Upload an order
Create order-1001.json:
{ "order_id": "order-1001", "customer_id": "customer-501", "amount": 250.75, "currency": "USD", "status": "NEW" } Upload it:
aws s3 cp order-1001.json \ s3://localcloud-orders/order-1001.json Step 8: Send an SQS message
aws sqs send-message \ --queue-url YOUR_QUEUE_URL \ --message-body '{"order_id":"order-1001"}' Once Lambda is deployed and connected through an SQS event-source mapping, it can process the order.
Check DynamoDB:
aws dynamodb scan \ --table-name Orders Expected application-level result:
{ "order_id": "order-1001", "customer_id": "customer-501", "amount": 250.75, "status": "PROCESSED" } Important: This example demonstrates the main application flow. A complete deployment still requires Lambda packaging, event-source mapping, permissions, SNS integration, and resource configuration. Verify that every required API operation is supported by your chosen emulator.
Step 9: Add automated testing
Create tests/test_processor.py:
import json def test_order_event_contains_order_id(): event = { "Records": [ { "body": ( '{"order_id": "order-1001"}' ) } ] } message = json.loads( event["Records"][0]["body"] ) assert message["order_id"] == "order-1001" Run:
pytest -v Next, add integration tests that create resources, submit messages, execute the processing workflow, and verify the final DynamoDB records.
Step 10: Deploy to real AWS
After local testing, deploy the application using AWS SAM or CloudFormation.
Your real AWS environment should include:
- Least-privilege IAM roles.
- S3 encryption and access controls.
- SQS visibility timeout and dead-letter queue.
- Lambda retry and failure handling.
- DynamoDB backup configuration.
- SNS topic policies.
- CloudWatch monitoring.
- AWS Budgets.
Run the same business-level integration tests against your AWS development account.
This final validation is essential.
9. Important Limitations
Local emulation is powerful, but it is not identical to real AWS.
AWS Emulator documents limitations including:
- IAM and resource-based policies are not evaluated like real AWS.
- Resources are not isolated by account and Region in the same way as AWS.
- Fidelity varies by service and operation.
- Resources are held in memory and deleted when the emulator stops.
- It is not designed for production workloads or load testing.
LocalStack also has service-specific implementation and compatibility boundaries.
I recommend four testing layers:
- Unit tests for business logic.
- Local integration tests using AWS Emulator or LocalStack.
- AWS staging tests for IAM, networking, quotas, and actual managed-service behavior.
- Production monitoring using CloudWatch and application telemetry.
Local testing accelerates development. Real AWS testing validates production readiness.
10. Who Can Benefit?
I see five important groups that can benefit from local AWS development.
Individual developers: Experiment with cloud architectures more easily.
Startups: Create repeatable local environments and reduce unnecessary development deployments.
Enterprise teams: Standardize integration testing and developer environments.
Data engineers: Test supported event-driven data processing workflows.
AI coding-agent developers: Give coding agents local environments to create resources, execute commands, and troubleshoot applications.
The market opportunity is not simply about replacing AWS deployments.
It is about faster feedback, repeatable testing, and more productive cloud engineering.
11. The Future: Local Cloud Development Meets AI Agents
Imagine asking an AI coding agent:
"Build an order processing application using S3, SQS, Lambda, and DynamoDB."
The agent generates the code.
It starts a local emulator.
It creates supported resources.
It runs tests.
It identifies an error.
It fixes the implementation and runs the tests again.
Finally, you review the code and deploy it to AWS.
This is where local AWS emulation becomes particularly interesting.
AWS Emulator and LocalStack are both relevant to this evolving development experience.
The next generation of cloud development will not only be about deploying infrastructure.
It will also be about how quickly developers and AI agents can build, test, and improve applications.
Final Thoughts
AWS Emulator introduces an official AWS-focused approach to local API emulation.
LocalStack offers a broader local cloud development platform with an established ecosystem.
Both have their place.
My recommendation is to test both against the actual AWS operations your application uses instead of choosing based only on feature lists.
Build locally. Test intelligently. Validate on AWS. Deploy confidently.
What would you choose for your next project: AWS Emulator or LocalStack?
I'd love to hear your experience in the comments.
References
AWS Emulator
- Official AWS Emulator Documentation
- AWS Emulator User Guide
- Getting Started
- Fidelity Testing
- AWS Announcement
LocalStack
- LocalStack Documentation
- Getting Started
- CI/CD Integration
- LocalStack 2026.10.0 Release
- LocalStack 2026.09.0 Release
AWS Development Tools
This is an independent educational comparison and project. AWS Emulator, LocalStack, and the AWS services mentioned belong to their respective owners. Capabilities, licensing, and service coverage may change.



