Posted by super_linear 18 hours ago
https://www.allthingsdistributed.com/2026/11/aws-emulator-an...
Floci[0] has been great for me. Use the Testcontainers[1], too.
Bonus: works for GCP and Azure, too (so far have only used in limited capacity, though).
Edit: The current one: https://github.com/aws/aws-emulator/releases/download/v1.0.3...
You can get some idea if the product name is unique enough with <ctrl-f> and looking at each of the related test scores.
And output something meaningful for some of the more popular services:
Service Tests All Happy Reject Ctrl Data Solo Integ Wire# Wire%
----------------- ----- --- ----- ------ ---- ---- ---- ----- ----- -----
Data Firehose 288 77% 85% 91% 92% 72% 89% 59% 24 62%
SES 132 72% 65% 79% 79% 42% 79% 0% 21 52%
EventBridge 889 71% 74% 64% 72% 68% 83% 67% 75 84%
KMS 432 70% 82% 69% 81% 68% 97% 36% 69 84%
Step Functions 907 70% 79% 53% 69% 67% 73% 65% 68 76%
DynamoDB 1437 69% 70% 61% 62% 65% 82% 53% 243 62%
SNS 594 69% 72% 55% 62% 68% 75% 65% 39 69%
SQS 1480 68% 70% 67% 61% 68% 94% 62% 29 45%
Secrets Manager 414 68% 78% 65% 66% 72% 79% 57% 26 77%
Cognito UserPools 781 65% 67% 66% 82% 36% 75% 33% 193 64%
S3 2488 62% 62% 57% 61% 57% 83% 51% 296 68%
CloudFront 627 62% 62% 63% 70% 46% 71% 41% 190 22%
API Gateway 1009 61% 64% 59% 77% 41% 75% 43% 200 73%
SES v2 210 61% 63% 59% 75% 48% 77% 40% 44 30%
Route 53 130 61% 63% 59% 62% 53% 69% 0% 49 67%
CloudWatch 1186 60% 66% 51% 66% 53% 77% 36% 152 55%
ECR 392 60% 55% 75% 67% 49% 87% 27% 74 65%
Kinesis 380 59% 69% 44% 63% 50% 62% 54% 25 44%
IAM 991 58% 63% 50% 60% 34% 78% 41% 228 57%
Batch 274 58% 62% 59% 78% 20% 65% 17% 19 47%
CloudWatch Logs 1016 58% 61% 54% 71% 47% 78% 41% 185 59%
OpenSearch 342 57% 62% 52% 70% 29% 59% 50% 98 48%
API Gateway v2 292 57% 64% 52% 74% 38% 73% 33% 107 27%
EKS 349 57% 60% 52% 65% 10% 59% 38% 55 62%
Glue 646 54% 51% 55% 66% 32% 69% 40% 155 43%
Lambda 2808 53% 53% 42% 58% 48% 48% 54% 171 42%
ECS 808 51% 45% 52% 62% 23% 62% 34% 118 44%
Redshift 241 49% 57% 47% 53% 52% 47% 57% 50 46%
STS 218 49% 58% 46% 56% 30% 57% 34% 22 50%
ELBv2 596 45% 43% 47% 55% 19% 58% 30% 111 63%
RDS 659 43% 54% 45% 54% 35% 51% 31% 99 28%
ElastiCache 186 42% 43% 49% 54% 0% 47% 17% 27 41%
EC2 2043 40% 35% 36% 39% 5% 44% 32% 429 33%
CloudFormation 2019 36% 33% 31% 30% 40% 78% 24% 2161 3%
AppSync 419 34% 35% 35% 54% 1% 44% 0% 91 13%
SSM 566 28% 28% 27% 27% 25% 26% 30% 175 11%
Athena 420 22% 20% 15% 7% 28% 16% 37% 37 0%
EC2 Auto Scaling 440 21% 19% 23% 19% 18% 21% 20% 89 16%
Edit: Also worth a look: https://ministack.org/blog/aws-emulator
They'll have something like this:
MySchema:
type: object
properties:
enum_member: { enum: [foo, bar] }
enum_member_2: { enum: [quz, qux] }
if: { properties: { enum_member: { const: bar } } }
then: { required: [enum_member_2] }
So your Rust API is full of Option, and it gets really annoying when you're testing things like say Bedrock, which takes 10 minutes, and then fails because what you submitted 10 minutes before doesn't match their schema.
I understand this can be fixed by reading the documentation in more detail, but it has gotten so verbose, and sometimes you just want to start something.
I suspect this is built by agents through bleeding the soul of GPUs until it gets too expensive (unfunded mandates are free after all on the OP1/2). Then it just decays into the place all good PR/FAQs decay once their sponsors are promoted, burned out, or are laid off.
For the AWS people behind this, it means going the extra mile(s), with a level of care and depth that you typically mostly see within great startups. Perhaps agentic coding will enable AWS to reach this, perhaps it will stay relatively abstract.
> It’s a real product that we plan to maintain.
29,684 commits in a repository less than a month old does not instill confidence in this being a "real product." That is roughly 1,000 accepted commits per day.
It’s actually interesting that such a thing exists. It’s in Amazon’s interest that the only way to test a lot of services is to have a test environment in AWS.
Official statements made by a company are still poor representations of their current business plans, and don't mean anything 3 months later (no matter how much they pinky promise). But a HN post isn't even that.
That said, it’s been announced publicly here: https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent...
Additionally Swami, our SVP of AI blogged about it separately and our CTO is tweeting about it - which is more than a number of products get in terms of coverage.
I think this is a super interesting direction, but how can we trust the accuracy of this simulator? Agentic loops are great and all, but they can still miss plenty of things.
Or maybe a better question: where is the accuracy of this simulator going to be guaranteed enough that we should trust it?
Like, what am I actually getting here? Is it just happy path operations being correct here?
Hopefully AWS has had enough internal guinea pigs before they published this!
The border between AWS and AWS emulator becomes fuzzy. And the users of AWS will be agents as well. A completely offline emulator will save a lot of resources and could be a great training ground for more focused (offline) models.
This feels like table stakes for an emulator.
Edit: Comment is in the spirit of "it gets tiring to build on sand which is at the whims of corporate management folks far disconnected from the actual work." If someone is asserting "this will stick around," words are insufficient, words are free. Show me the contract, show me the penalties for failure to abide by the assertion.
Google builds up a product over time and abandons it. This is annoying for long term adopters.
AWS has a habit of throwing a bunch of products at the wall, but only bothering to maintain & build up a few of them. This is annoying for early adopters.
Not many, and not often but it is annoying.
The Copilot CLI https://aws.github.io/copilot-cli/ you can feel polish and pride of the team that built this, as an example.
Can we just appreciate that they _appear_ to be doing the right thing here? Save the criticism for when (if?) they turn their backs.
I appreciate the effort dang and team have put into keeping the quality high here over the years, and I'm not sure what the optimal solution is.
Fig: "The open-source project will continue to be maintained!" https://news.ycombinator.com/item?id=39684576
And yet: https://github.com/withfig/autocomplete/issues/2068
Work from home: "My team's never going back to the office." https://news.ycombinator.com/item?id=32779047
Same commenter a few months later: "I (work at Amazon and) already have to go in once a week, and I literally do NOTHING that day. [...] This is a disaster in the making."
You choose the attitude you want to have in your life to disappointment and the attitude you bring to this site. You chose cynicism. You're going to crowd out people who don't make the same choice.
I crashed my motorcycle years ago and have mild but still lifetime injuries. As a result, I've changed my behaviors and have put away my motorcycle. It's given me a place to reflect on what my own life is about, where I want to go, and the pain my family felt when they heard about the crash.
I choose the attitude of learning from the past and adjusting my behaviors.
I try not to share my cynicism with the world too broadly because I think our modern era has too much of it. I think humanity is advanced by the wild dreamers.
Yes, we're obviously different, but... dude.... dude. this is a damned conversation about a damned cloud server emulator that's not even close to 100% in-parity. It's perfectly healthy to inductively recognize that using such a system, like its sibling tools, might not continue receiving support.
Also, I'd argue that your post right before this one is cynicism so I'm not really sure I follow your point. https://news.ycombinator.com/item?id=50459315
Sometimes things suck and it's okay to express our frustrations about them.
I guess I care because I've been on this forum for a very long time and everyone individually says that, but then the comment section as a whole turns into a hazard zone. Anyway I think I've engaged too much on this site for today.
Now if they abandon it, then sure, light them torches.
I didn't have a good experience with test containers, but perhaps it'd work better with fast starting containers. We run our test fixture with compose, and have the tests manage their data in isolation - so we don't pay the startup penalty in our test suites.
I think I'd trust this project at least as much as Floci. Embedded Rust mode also looks very interesting for us.
> How we built the agents that built AWS Emulator
> Thousands of autonomous AI agents wrote every line of code in AWS Emulator, a new local emulator for AWS now available for download.
Doesn't feel like a real product. But I also didn't look very hard for docs; I kind of expect it to be linked on the GH in the site and have a nice `llms.txt` for me to give to my agents.
The product documentation is here: https://docs.aws.amazon.com/emulator/latest/userguide/what-i...
While the GitHub project is young, the internal effort to build this has been going for quite some time now.
> Doesn't feel like a real product. But I also didn't look very hard for docs
You should try, they're there.
> I kind of expect it to be linked on the GH in the site and have a nice `llms.txt` for me to give to my agents.
There's an official Amazon Documentation site that's linked. There's also an `AGENTS.md` file in the repository.
This post https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent... doesn't set the right tone for me at all and it has nothing to do with agents and everything to do with the lens of looking at this as a science experiment instead of a real enterprise tool.
This feels like such a weird nit-pick when AWS is criticized for not moving quickly enough. Why should I care if there's a link in the side bar, when there's plenty of links in the `README`? If anything, I'm happy that there's alternatives to Localstack that are supported by AWS themselves that I can begin incorporating. They have a well written `README` that I can start working with and a User Guide to get me started. What else could I want?
> Did you look at the blog post as well?
I did.
> Does it look like a product that some team there loved and will care for? Or the output of some exercise for some enterprise content?
Do you even have the grounds to cast judgement like this when you admittedly didn't even look hard enough?
This lacks polish.
Small details like getting your GH repo set up for a public audience. Lacking. Compatibility and support matrix clearly advertised? None.
If this public facing artifact exhibits a lack of care and love, what does it say about the code? I am all for vibe coding and agent software factories, but then the humans should show some love with all of that extra time saved.
Look at Floci (I have no affiliation) https://floci.io/ the blog https://floci.io/chronicle/ and the labs https://floci.io/labs/
Do you agree that there's a polish here that shows a team's pride in that work that is clearly missing in this work?
> ...especially when engaging with (presumably) actual AWS employees in this thread replying to you
No and I think the inverse is also possible and if anything more likely. You can make a website look really pretty, really easily and have the product still suck. This is "product as a slide" in a new age where making visual eye candy with AI has never been easier.
> I do not care if their feelings are hurt because this "product" clearly shows a lack of polish and love.
The point isn't about hurting feelings. The point is about providing critque and feedback based in reality, not based on "vibes." You're trying to gatekeep people releasing software because you dont like the way they're launching it lol.
??? It's in bold just before the "Quick start" section
The team didn't even take the time to review these small details of the repo, you know, by editing the repository details to place the docs URL there.
I mean, I don't know about you, but I feel like I still like to see people care about the stuff they produce and missing something as basic as the repo website URL in GH settings shows a lack of polish and love.
If you have a product that has APIs and can be verified, anyone can copy the APIs and the features. By the way, you absolutely want to offer APIs so your product can be used by agents.
This means you need to compete on aspects other than features.
Just because you can emulate all the APIs doesn't mean you can build AWS.
Availability, reputation, performance, domain expertise, price: all of these become critical in a world where features can be copied.
> Don’t use the emulator to test the following:
> - IAM policies and permissions boundaries
> - Resource-based policies, such as bucket policies
> - AWS KMS key policies
> - Access across AWS accounts or across AWS Regions
> - Any other security control
> Some services in the emulator evaluate IAM policies for IAM users and roles that you create in the emulator, but not the same way as AWS. The emulator never denies a request signed with its own key. It doesn’t check AWS KMS key policies or Amazon S3 bucket policies. It also doesn’t support calls across accounts or Regions. So a request that AWS denies might succeed in the emulator. A request that AWS allows might fail.
This is a shame because I'd love for the official AWS product to be better than e.g. ministack and localstack on this, which will go some of the distance. I think because the agents were only building on the public API surface, it's hard to build this part. But they should've tried and let the agents read whatever policy engines AWS has. Or maybe it's a way to prevent someone from trivially running aws-emulator as AWSaaS?
[0] https://docs.aws.amazon.com/emulator/latest/userguide/securi...
https://github.com/act-security-labs/iam-lens
It uses https://github.com/act-security-labs/iam-collect to get all the policies which includes example terraform to gather all the data at scale.
There was an attempt at a public implementation of the “next gen” AWS IAM language/engine with “cedar.” However I think that got sidetracked as an authz product and didnt have any real penetration with AWS IAM.
IAM itself is free. Most IAM conditions involve resources which are free (e.g. VPC gateway endpoints, web identity providers) or which are free additions on top of a cluster you have for other purposes (e.g. EKS Pod Identity). Presumably you already have an AWS account. What value does an emulator give here?
This is probably the root of your problems. In principle, non-production accounts should have vastly reduced security requirements. Personally, I can't understand how companies are OK with offering more-or-less unrestricted guest WiFi (which, of course, has no access to production systems, let alone internal systems), but somehow offering minimally restricted AWS accounts (basically, just slap billing alarms on, maybe common-sense SCP-based restrictions like no public IPv4) for development purposes is problematic?
I am shocked TBH that this is the new normal. Agents writing code in one of the most difficult to use languages. And ugly as well TBH, it pokes into your eyes. Subjective I know but it is a horrible language for humans.
Arguably, languages with strong static guarantees are exceptionally effective for LLMs since they're much quicker to provide feedback to the LLM than a dynamically typed language (which only fails once you actually run it - often several times to find the actual problem). You also get very well-designed build error messages rather than having to parse unstructured stderr output, etc etc.
An actual AWS supported env that you can run on your local machine would be super useful, even if it just had a subset comprising the most popular services.
Agentic development is all about closing off a system as much possible, then mocking up or simulating any inputs or dependencies that cannot be closed off. At that point, you let Claude crawl over the system and do its thing.
This inevitably runs into problems with infrastructure and any tools that help mock up those interfaces will be tremendously valuable. Thank you!
I'm curious just how realistic the "internal" behaviour is emulated. It's been a while (since I got my stack working and I just don't like touching it now...), but I recall it being a real pain that sometimes odd, sometimes inconsistent things happened with setup and teardown (even through Terraform), which led to long timeouts if you did things in the wrong (but seemingly valid) order.
It seems like some reasonable shortcuts are taken, like services reading from each other's states directly instead of using APIs [0]. But then it will go so far as to run an in-process NodeJS emulator for lambda functions, and give it a shim so the code it runs can call other emulated AWS services using the main router [1].
[0] https://app.ilograph.com/demo.ilograph.AWS%2520Emulator/Serv... [1] https://app.ilograph.com/demo.ilograph.AWS%2520Emulator/Invo...
Specifically it does not support certain SFN fields (like `Assign`) and Lambda Python code was not fully supported, so SFNs and Lambdas did not work and the test had to stop there.
I got a lot of enjoyment out of https://awsteele.com/blog/2020/09/26/aws-access-key-format.h... at the time, too