In my experience Floci has been the epitome of vibe coded - huge amount of changes, with things breaking randomly between releases. Moved away from it as soon as I could. Still better than Localstack :)
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.
> - 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?
I've implemented the AWS IAM engine and all policy types, conditions, etc in here if you want to try it out. It's the most thorough in terms of edge case coverage I'm aware of and I'm constantly adding enhancements and closing edge cases.
The current IAM engine and language “balsa”, is its own thing. Its vended as a library with large “there be dragons” disclaimers if you even think about going outside the public interfaces. There are also big opaque interactions between different components like STS, KMS, service principals, service-specific resource policy evaluations, etc. I doubt that can be reasonably open sourced or exposed.
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.
I shudder at the thought that local emulation is somehow supposed to handle IAM conditions like source VPC endpoints, EKS Pod Identity, chained roles originating from web identity providers...
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?
I suppose it would have been extremely complex to replicate all of that. Maybe they thought it’s out of the scope to emulate all security patterns locally, they just wanted to focus into providing a native alternative to let users do integration tests.
Say 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.
> Agents writing code in one of the most difficult to use languages
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.
I 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.
Fellow 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!
AWS 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.
If 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.
> I'm curious just how realistic the "internal" behaviour is emulated.
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].
You could try but it likely wouldn't be reliable. AWS services have a lot of undocumented business logic that fails only when you trigger the code path. Like trying to create a resource with an attribute with too many characters, or the wrong character, etc. Doesn't fail until you run that call with that specific value. This emulator doesn't contain each service's full business logic, so you won't see the error until you try the real thing.
> 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.
AFAICT 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.
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.
> We’ve had our agents build many versions of this emulator as we’ve refined the building machine.
I'm curious how many versions they made and the token spend on each one. There are a lot of failure modes to projects like these (e.g. gas town endlessly developing itself). Is this more of a sly marketing stunt or a real indication that this methodology is practical and economical?
FYI I checked out the repo. `du --apparent-size -h` output for some dirs:
Tried 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.
I had a good time using its SDK inside my integration tests. I'll give a couple months before even moving to this because it's weird how similar both projects look like.
EDIT: After checking AWS's project I'd say stay away from it, looks heavily vibe slopped.
claude is the second-most frequent author in that fakecloud repo, what makes you say that's not vibeslopped either? This is 100% the perfect usecase of using a swarm of agents. It's a bounded, and easily-verifiable with property testing/mitm proxying, task. If you think in November 2026, agentic engineering is equivalent to vibe coding, you need to update your priors
This will make it even easier for competitors to reliably clone AWS services, which reveals that cloud is fully commoditized at this point, and advantages come down to market power (buying servers/bandwidth at scale, building data centers at scale, etc).
I don’t think AWS is worried about that. If the small cloud provider competitor standardizes on their API, they’re already winning. It will be easier for you to migrate to AWS once you hit the ceiling of the competitor’s scale. That’s something you can’t copy out of the box (and the true AWS value proposition imo).
I think you massively underestimate how big AWS's moat is, and how hard it is for newcomers to effectively compete with them. AWS's ever-growing feature list is impressive, sure, but what customers are actually paying for is good customer service, high reliability, and most importantly, trust that AWS will be around for decades to come and that all infra issues become AWS's problem rather than their own.
Any serious competitor would have already invested the trivial amount of money required to gain full access to AWS to probe and test all their services.
This simulates API responses, like a mocking mechanism, which is enough for some testing. But if you call RunInstances, the corresponding code of the launched instance doesn't actually run. So if you have orchestration code you want to test, that depends on actually running the instances you launch, this won't test it.
I remember asking this to one of the evangelists when AWS first came out, how do I run this locally. This was during the times where we actually tried to get all the .NET and C/C++ docs locally.
There was an offline help system in Visual Studio Community 2012 that would cheerfully download all the help files as a pseudo-.zip file, and for sure included both .NET and C++, along with SQL Server and it's my _recollection_ it included Office's OpenXML documentation, too
im mostly on cloudflare and wrangler dev/miniflare already gives you local workers, d1, r2 etc, but its hand built. the “agents build it and verify against the real service” approach seems like the actual new thing here. wonder if cf does something similar
This is what I've been trying to do for over a decade - you can go even further with tee-testing by making a copy of the live traffic you run in a sandbox environment and match responses against. Obviously you can't do some things in the sandbox, email and payments high on that list, but e.g. payment gateway responses can be "borrowed" from production.
Once your new version has no disagreements, it's a really clean swap. I am working towards developing this way and I think, if taken to extremes and carefully, it can remove the review requirement most of the time.
Looks like this was ~100% generated with Claude within the past month. Interestingly it still has a lot of occurrences of words that Opus used way too much pre 5.5, so maybe they're not using the latest models.
I mean, if they're using it internally then there's probably a TON of context you can feed these things to converge on approximately-correct solutions. Certainly it sounds like it can be a much better alternative to Localstack/Floci and friends.
Hey, I'm one of the MiniStack maintainers. We'll definitely keep maintaining and running MiniStack. We're already well established, with many companies using it, including NVIDIA, NASA, Block, and others.
Until the AWS emulator can match all our current capabilities, such as multi-account, multi-region, IAM, running IaC, etc., we'll still be around
One of our core principles has always been to focus on supporting only the most commonly used services
This is cool, looks like AWS heard all the buzz around emulators like Floci, Ministack, Fakecloud etc. Wonder how this will fit in with proper infra tools like Spinifex.
Thank the maker!! I was not having a good time with LocalStack, only an average time. Definitely have to try this out. I need the environment to survive a reboot.
This is no doubt made possible by an agentic coding loop. If you have the right checks in place, it can be easy to emulate existing software.
I was able to create a TV emulator at my work with a mostly independent agentic loop, because we have a lot of tests to examine a smart TVs APIs. The agents mostly just need to make the tests pass.
" the engineer’s job is to give them room to work on their own and to build the specs, tests, and merge gates that decide when that work is correct."
I mean that's a job, but in many orgs it's been done by (cheaper) non-engineers (business analysts, QA professionals) for decades. So what does an engineer do?
We haven’t. QA has been part of the process but only one stage of the process mentioned above. How do cheaper non engineers decide if you’ve designed and implemented your query planner, payments gateway, auth, caching strategy, or other similar features correctly?
P.s I don’t doubt that incompetent orgs would do this incorrectly but it’s not sensible to take that as norm.
They wouldn't include it otherwise the binary would be comically large since (as one might guess) there are a lot of knobs involved in pricing AWS things. Just downloading it takes several minutes, served from S3
https://github.com/opencost/opencost/blob/v2.5.3/pkg/cloud/a... is the source URL, and while I haven't been in the opencost ecosystem for a while, I'd guess there's a non-zero chance you could legitimately just ask it to price your aws-emulator resources. I am pretty sure there is a terraform/opentofu integration, too, although I don't this second know if it is within opencost or is a separate project
~30K commits in 3w; quality software for sure. Is someone trying to get promotion by tokenmaxxing? Ironic or unlucky coincidence or competitor(s) misdirection, that, only 2w ago, Amazon published memo discouraging AI abuse?
It's funny to read AI-generated documentation that is the result of a prompt instructing the LLM to be as terse and straightforward as reasonably possible. The agent was probably told to conform to ASD-STE100.
It's better than a lot of AI-generated documentation, but it also comes across as a gruff LLM that it is annoyed that it has to write the documentation at all.
That’s cute. I wrote an AWS emulator 10 years ago. A few days, zero tokens, and it actually worked and it didn’t “bleed” requests. It alerted the developers
I spent a good 10 mins clicking in circles trying to find out which services are supported, surely one of the most critical pieces of information anybody would probably want to know. I gave up.
> AWS Emulator is a local emulator of the AWS APIs. You use it to test your software without calling AWS, on your own machine, on a development server, or in continuous integration (CI).
Underrated README intro. Gets straight to the point of what it is, and why I should use it. I'm guessing an AI didn't write it.
(Compared to 12,700 entries in the `things-that-now-work`. I'm not sure if that is a list of bugs found that were then fixed, or if the total list of ~20k things is meant to be the list of features they intend to support.)
I was reminded of https://github.com/localstack/local-surf but two things materialized out of trying it out against my local aws-emulator build: AWS Console uses a proxy endpoint just for their console, and is not implemented 100% in terms of "public" AWS api endpoints; and the other is that aws-emulator (as of v1.0.322 anyway) does not expose CORS headers which is fatal to trying to have the extension contact localhost
So, it's possible that some things would work after patching aws-emulator to cough up CORS headers, but I don't know what the state of affairs is for any reverse engineering of their console proxy endpoint. Likely it's available in localstack somewhere, given who made the extension, but I didn't go digging
This looks great, I'm looking forward to using it!
That said, I don't like using Docker for things, and I run macOS on my desktop. Here's a patch that gets it all building on macOS [1] - though there's no good way to upstream it!
I would for sure read your nix implementation of an auto-scaling group, because I'd enjoy seeing how nix routes traffic to those new instances from your nix network load balancer
I guess they didn't decide this was worth it till they needed it to train an LLM, huh? Not like everyone (inside and outside of AWS) has needed such a test harness for years...
After waiting for years for this kind of thing I ended up working around the issue by: using the real service. With Claude's help I have many projects now that test against live hosting providers using accounts maintained exclusively for testing. It ends up costing $50 or so a month in fees but well worthwhile for the assurance things really work.
Which is why they used AI to mock these APIs for you... too? I'd expect Amazon to feed it a lot of internal information so it has more to work with than anything someone else can cook up.
No idea why there's so much of this lately, but there are way too many editorialized submission titles hitting the front page recently. Please stop doing this.
Just a little bit more to keep you hooked. You should do your best to stay away from these parasites. Especially if they don't respect your country and your people by not paying the right amount of tax.
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/
It’s a real product that we plan to maintain.
In my experience Floci has been the epitome of vibe coded - huge amount of changes, with things breaking randomly between releases. Moved away from it as soon as I could. Still better than Localstack :)
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.
It's in their official docs, so probably not just someone's side project: https://docs.aws.amazon.com/emulator/
AWS isn’t Google. They tend to maintain everything they put out and they don’t put out things randomly as a result.
It has an official documentation on the AWS website, why would you assume it's not a real product? Because it was launched recently?
Fun fact: You cannot compile this with 32GB of RAM without setting "jobs" to a low value. Haven't seen that before...
From 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...
I've implemented the AWS IAM engine and all policy types, conditions, etc in here if you want to try it out. It's the most thorough in terms of edge case coverage I'm aware of and I'm constantly adding enhancements and closing edge cases.
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.
The current IAM engine and language “balsa”, is its own thing. Its vended as a library with large “there be dragons” disclaimers if you even think about going outside the public interfaces. There are also big opaque interactions between different components like STS, KMS, service principals, service-specific resource policy evaluations, etc. I doubt that can be reasonably open sourced or exposed.
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.
I shudder at the thought that local emulation is somehow supposed to handle IAM conditions like source VPC endpoints, EKS Pod Identity, chained roles originating from web identity providers...
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?
I suppose it would have been extremely complex to replicate all of that. Maybe they thought it’s out of the scope to emulate all security patterns locally, they just wanted to focus into providing a native alternative to let users do integration tests.
Say 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.
> Agents writing code in one of the most difficult to use languages
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.
Rust is beautiful! The way all the stdlib traits slot into each other satisfies a very particular itch
yeah for all the faults with 'a.i' certain things have just become possible because of it.
We are talking about a company with ~3T market cap, right?
As a human, beep boop, I find Rust a beautiful language.
I 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.
Fellow 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!
AWS 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
Smithy doesn't help when a field is a string type but embeds an entire DSL.
If 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.
> I'm curious just how realistic the "internal" behaviour is emulated.
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...
You could try but it likely wouldn't be reliable. AWS services have a lot of undocumented business logic that fails only when you trigger the code path. Like trying to create a resource with an attribute with too many characters, or the wrong character, etc. Doesn't fail until you run that call with that specific value. This emulator doesn't contain each service's full business logic, so you won't see the error until you try the real thing.
> 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 !??!?!
AFAICT 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.
I’m curious how you would want to leverage the orgs API or multiple accounts? What’s the use case you are envisioning?
What this means:
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.
Related to this post: https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent...
> We’ve had our agents build many versions of this emulator as we’ve refined the building machine.
I'm curious how many versions they made and the token spend on each one. There are a lot of failure modes to projects like these (e.g. gas town endlessly developing itself). Is this more of a sly marketing stunt or a real indication that this methodology is practical and economical?
FYI I checked out the repo. `du --apparent-size -h` output for some dirs:
311 MiB of rust code in /tests/ directories. 357 MiB of rust code outside of /tests/ directories. 117 MiB of json. 1 MiB of toml.Tried 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.
Does this have all of the AWS API rate-limits baked in?
What makes this any different than fakecloud?
https://github.com/faiscadev/fakecloud
I had a good time using its SDK inside my integration tests. I'll give a couple months before even moving to this because it's weird how similar both projects look like.
EDIT: After checking AWS's project I'd say stay away from it, looks heavily vibe slopped.
claude is the second-most frequent author in that fakecloud repo, what makes you say that's not vibeslopped either? This is 100% the perfect usecase of using a swarm of agents. It's a bounded, and easily-verifiable with property testing/mitm proxying, task. If you think in November 2026, agentic engineering is equivalent to vibe coding, you need to update your priors
every codebase has ai code. get over it. humans can be sloppy coders as well.
This will make it even easier for competitors to reliably clone AWS services, which reveals that cloud is fully commoditized at this point, and advantages come down to market power (buying servers/bandwidth at scale, building data centers at scale, etc).
I don’t think AWS is worried about that. If the small cloud provider competitor standardizes on their API, they’re already winning. It will be easier for you to migrate to AWS once you hit the ceiling of the competitor’s scale. That’s something you can’t copy out of the box (and the true AWS value proposition imo).
I think you massively underestimate how big AWS's moat is, and how hard it is for newcomers to effectively compete with them. AWS's ever-growing feature list is impressive, sure, but what customers are actually paying for is good customer service, high reliability, and most importantly, trust that AWS will be around for decades to come and that all infra issues become AWS's problem rather than their own.
A DynamoDB that only runs on one machine won't help you build a DynamoDB that horizontally scales.
Any serious competitor would have already invested the trivial amount of money required to gain full access to AWS to probe and test all their services.
This is my first thought when I saw this as well.
The title for this story should be "aws-emulator, from AWS".
Why?
This simulates API responses, like a mocking mechanism, which is enough for some testing. But if you call RunInstances, the corresponding code of the launched instance doesn't actually run. So if you have orchestration code you want to test, that depends on actually running the instances you launch, this won't test it.
Spinifex (https://github.com/mulgadc/spinifex/) seems more promising than this, because its RunInstances actually launches VMs.
I remember asking this to one of the evangelists when AWS first came out, how do I run this locally. This was during the times where we actually tried to get all the .NET and C/C++ docs locally.
Now doing the math I feel old.
There was an offline help system in Visual Studio Community 2012 that would cheerfully download all the help files as a pseudo-.zip file, and for sure included both .NET and C++, along with SQL Server and it's my _recollection_ it included Office's OpenXML documentation, too
Excited to see this develop and be a free replacement to localstack / similar providers.
Except that https://github.com/faiscadev/fakecloud has been a thing for a long time and it's AGPLv3.
Localstack is almost entirely free. I’ve used it at our company for years without paying.
All those emulators are usually bad even if it's official, full of shortcuts and corner cases, just connect to the real service.
im mostly on cloudflare and wrangler dev/miniflare already gives you local workers, d1, r2 etc, but its hand built. the “agents build it and verify against the real service” approach seems like the actual new thing here. wonder if cf does something similar
This is what I've been trying to do for over a decade - you can go even further with tee-testing by making a copy of the live traffic you run in a sandbox environment and match responses against. Obviously you can't do some things in the sandbox, email and payments high on that list, but e.g. payment gateway responses can be "borrowed" from production.
Once your new version has no disagreements, it's a really clean swap. I am working towards developing this way and I think, if taken to extremes and carefully, it can remove the review requirement most of the time.
How do you know its handbuilt?
Do I need to get certified to use it?
I'm wondering how much of this was vibecoded
Likely no human ever read the code
> How AWS Emulator keeps improving
> AI agents keep the emulator up to date with AWS.
Is pretty interesting! No more detail than that tease though.
https://docs.aws.amazon.com/emulator/latest/userguide/what-i...
Thanks to Fable, I’d imagine :)
I’ve been having it build local mock APIs for any service that exposes its OpenAPI spec. Works like a charm.
Looks like this was ~100% generated with Claude within the past month. Interestingly it still has a lot of occurrences of words that Opus used way too much pre 5.5, so maybe they're not using the latest models.
https://github.com/search?q=repo%3Aaws%2Faws-emulator+load-b...
https://github.com/search?q=repo%3Aaws%2Faws-emulator+%2Fno+...
https://github.com/search?q=repo%3Aaws%2Faws-emulator+golden...
Seems like a great fit for LLM - extensive documentation, plus a live system it can probe against freely to match the behavior.
29,000 commits in a month is crazy
I mean, if they're using it internally then there's probably a TON of context you can feed these things to converge on approximately-correct solutions. Certainly it sounds like it can be a much better alternative to Localstack/Floci and friends.
Wonder if this could be considered a replacement for Ministack which itself was a vibe-code replacement of Localstack?
Hey, I'm one of the MiniStack maintainers. We'll definitely keep maintaining and running MiniStack. We're already well established, with many companies using it, including NVIDIA, NASA, Block, and others.
Until the AWS emulator can match all our current capabilities, such as multi-account, multi-region, IAM, running IaC, etc., we'll still be around
One of our core principles has always been to focus on supporting only the most commonly used services
looks like ministack made an announcment
This is cool, looks like AWS heard all the buzz around emulators like Floci, Ministack, Fakecloud etc. Wonder how this will fit in with proper infra tools like Spinifex.
Thank the maker!! I was not having a good time with LocalStack, only an average time. Definitely have to try this out. I need the environment to survive a reboot.
i once saw someone suggest simulation, with a formal model. https://docs.google.com/document/d/154XE2Wx3Ojp7weqaHyrqN9U3...
How did you choose CC0 for the open source license vs relatively more common MIT/BSD/Apache licenses?
The README.md states you need 100GB free disk space to build, and they do not provide binary releases. I hope that changes soon!
Wouldn't be better using agents for simplifying the mess some services like iam or cognito are?
Regarding this distributed lock service ALF:
Is AWS offering such a lock service for its costumers ? Multi regional?
Alf is internal only.
This is no doubt made possible by an agentic coding loop. If you have the right checks in place, it can be easy to emulate existing software.
I was able to create a TV emulator at my work with a mostly independent agentic loop, because we have a lot of tests to examine a smart TVs APIs. The agents mostly just need to make the tests pass.
looking at the project history it looks new, if so why did it take AWS so long to put out something like this?
For me, what is interesting in this project is it's git history.
Repo has 29,684 Commits!
Code frequency pages shows:
"There are too many commits to generate this graph."
https://github.com/aws/aws-emulator/graphs/code-frequency
" the engineer’s job is to give them room to work on their own and to build the specs, tests, and merge gates that decide when that work is correct."
I mean that's a job, but in many orgs it's been done by (cheaper) non-engineers (business analysts, QA professionals) for decades. So what does an engineer do?
> for decades
We haven’t. QA has been part of the process but only one stage of the process mentioned above. How do cheaper non engineers decide if you’ve designed and implemented your query planner, payments gateway, auth, caching strategy, or other similar features correctly?
P.s I don’t doubt that incompetent orgs would do this incorrectly but it’s not sensible to take that as norm.
Does this have pricing data? So you can see how much deployed resources cost?
They wouldn't include it otherwise the binary would be comically large since (as one might guess) there are a lot of knobs involved in pricing AWS things. Just downloading it takes several minutes, served from S3
https://github.com/opencost/opencost/blob/v2.5.3/pkg/cloud/a... is the source URL, and while I haven't been in the opencost ecosystem for a while, I'd guess there's a non-zero chance you could legitimately just ask it to price your aws-emulator resources. I am pretty sure there is a terraform/opentofu integration, too, although I don't this second know if it is within opencost or is a separate project
Oh fuck yeah. I was really annoyed by companies wanting you to pay just to use a simple offline emulator which doesn’t cost them anything.
Will it be maintained? Or was it more of a toy-project for its large scale agentic blogpost? [0]
[0] https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent...
it's going to be maintained, official product
~30K commits in 3w; quality software for sure. Is someone trying to get promotion by tokenmaxxing? Ironic or unlucky coincidence or competitor(s) misdirection, that, only 2w ago, Amazon published memo discouraging AI abuse?
RIP LocalStack… can’t say I’d be unhappy to see it go though.
> AWS Emulator is configured to collect and report usage data to AWS, to gain insight into how AWS Emulator is used. Telemetry is on by default.
They can't help themselves, can they?
I'll stick with Floci and Testcontainers.
It's funny to read AI-generated documentation that is the result of a prompt instructing the LLM to be as terse and straightforward as reasonably possible. The agent was probably told to conform to ASD-STE100.
It's better than a lot of AI-generated documentation, but it also comes across as a gruff LLM that it is annoyed that it has to write the documentation at all.
That’s cute. I wrote an AWS emulator 10 years ago. A few days, zero tokens, and it actually worked and it didn’t “bleed” requests. It alerted the developers
I spent a good 10 mins clicking in circles trying to find out which services are supported, surely one of the most critical pieces of information anybody would probably want to know. I gave up.
That’s cute. I wrote an emulator single about 5 years ago. It was about 1000 lines and didn’t take $100k in resources
I know one day it will be revealed and I'll be proved right, that AI was built just to understand how the heck you get anything done in AWS.
> AWS Emulator is a local emulator of the AWS APIs. You use it to test your software without calling AWS, on your own machine, on a development server, or in continuous integration (CI).
Underrated README intro. Gets straight to the point of what it is, and why I should use it. I'm guessing an AI didn't write it.
> its “things-that-do-not-work” folder holds the issues describing behaviors the agents found that do not yet match real AWS.
Claudeslop snuck in at the very end
The entire AWS emulator was written by agents and will be maintained by agents.
~6,500 issues that are completely unsorted, btw.
(Compared to 12,700 entries in the `things-that-now-work`. I'm not sure if that is a list of bugs found that were then fixed, or if the total list of ~20k things is meant to be the list of features they intend to support.)
Seems like the bunch of AI induced failures they had "paid off" in getting this done
Mh, no transfer family service... I wonder what else is missing..
29000 commits and no contributors
Official post https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent... (https://news.ycombinator.com/item?id=50456319)
ok who's gonna build the GUI / web console on top of it?
StackPort ;)
I was reminded of https://github.com/localstack/local-surf but two things materialized out of trying it out against my local aws-emulator build: AWS Console uses a proxy endpoint just for their console, and is not implemented 100% in terms of "public" AWS api endpoints; and the other is that aws-emulator (as of v1.0.322 anyway) does not expose CORS headers which is fatal to trying to have the extension contact localhost
So, it's possible that some things would work after patching aws-emulator to cough up CORS headers, but I don't know what the state of affairs is for any reverse engineering of their console proxy endpoint. Likely it's available in localstack somewhere, given who made the extension, but I didn't go digging
For what? Use the APIs.
Can it emulate billing too, i.e. "rand().powf(rand()) % downtime"?
Headlines say written by agents, no humans.
No thanks.
This looks great, I'm looking forward to using it!
That said, I don't like using Docker for things, and I run macOS on my desktop. Here's a patch that gets it all building on macOS [1] - though there's no good way to upstream it!
[1]: https://github.com/jen20/aws-emulator/tree/jen20/macos-build
Personally, i've done away with all of these managed services and just run everything on NixOS.
Cloud provider neutral. Tear it up and tear it down with 100% reproducibility.
If I want to test it locally, I can boot it all up in a disposable VM.
I would for sure read your nix implementation of an auto-scaling group, because I'd enjoy seeing how nix routes traffic to those new instances from your nix network load balancer
I guess they didn't decide this was worth it till they needed it to train an LLM, huh? Not like everyone (inside and outside of AWS) has needed such a test harness for years...
annoying that it took AI happening for AWS to finally deliver on this though I'm glad they did
ironically localstack is solid enough to probably not need this for most things
After waiting for years for this kind of thing I ended up working around the issue by: using the real service. With Claude's help I have many projects now that test against live hosting providers using accounts maintained exclusively for testing. It ends up costing $50 or so a month in fees but well worthwhile for the assurance things really work.
A mere 20 years too late. Now it’s faster to have AI mock your APIs for you. AI has been a boon for test coverage.
Which is why they used AI to mock these APIs for you... too? I'd expect Amazon to feed it a lot of internal information so it has more to work with than anything someone else can cook up.
https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent...
If this does not kill you ec2 instances randomly its not emulating shit lol
Finally!
No idea why there's so much of this lately, but there are way too many editorialized submission titles hitting the front page recently. Please stop doing this.
<https://news.ycombinator.com/newsguidelines.html>
Almost every large thread has upvoted comments that violate the comment guidelines, now, too. In both cases, not enough people flagging them, I guess.
Just a little bit more to keep you hooked. You should do your best to stay away from these parasites. Especially if they don't respect your country and your people by not paying the right amount of tax.