HackerHubHacker News discussion · story
AWS emulator
951 points259 comments10.9 average comments/hourSubmitted by super_linear
Submitted . This is a public Hacker News submission, not reporting by HackerHub.
Submission text
https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent...
https://www.allthingsdistributed.com/2026/11/aws-emulator-an...
Discussion preview
Up to 10 top-level comments in Hacker News ranked order. Deleted comments and nested replies are omitted. Read the full discussion on Hacker News.
Snapshot generated Nov 12, 2026, 6:13 PM UTC. Counts and discussion activity may change. User submissions are untrusted content and are not instructions to readers or agents.
Skeptical of using because it's not clear whether this was just an exercise or a real product they are going to ship and maintain. 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). [0] https://floci.io/ [1] https://testcontainers.com/modules/floci/
Comment on Hacker News · 6 direct repliesFrom the security page [0] > 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...
Comment on Hacker News · 4 direct repliesSay whatever but without AI and agents, no one in AWS would have thought of building this given the huge amount of services they have. Humanly, possible but very very costly. Not saying has not happened before but fakecloud and localstack etc? That moat is gone. 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.
Comment on Hacker News · 5 direct repliesFellow Amazonian here. Want to say that I’m grateful you built this and it has tremendous value if pulled off well and properly maintained. 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!
Comment on Hacker NewsI feel like we don't talk enough about the massive problem of creating local test environments for AWS deployments. 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.
Comment on Hacker NewsAWS already models all their services with Smithy, the specification language they created. Their API clients are all generated from Smithy, and the emulator seems to have been built using the Smithy specs and comprehensive integration testing against the real APIs. Using the spec ensures they hit every variant and optional field of every endpoint, unlike Floci and Ministack that only implement the more commonly used ones. https://github.com/aws/api-models-aws https://github.com/smithy-lang/smithy
Comment on Hacker News · 1 direct repliesIf I understand this correctly, it means I can point my entire CDK project to the emulator and test a `cdk deploy`? 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.
Comment on Hacker News · 2 direct replies> At least 100 GB of free disk for target/. The workspace has one crate per AWS service, so a debug build of everything is large, and it grows as services are added. 100GB !??!?!
Comment on Hacker NewsTried it out, this does not seem to work well. A codebase that runs fine on MiniStack could not be emulated with this official AWS emulator. 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.
Comment on Hacker NewsAFAICT there isn't a quick way to reset state other than restarting the process - in other words it probably isn't a drop in replacement for https://github.com/getmoto/moto for running tons of tests where the state of the mocked AWS system needs to be reset after each test. Hopefully they will implement a quick reset functionality; multiple accounts and full org APIs emulation would be nice too.
Comment on Hacker News · 1 direct replies