Is there anywhere I can find a matrix of what services are emulated and how complete that emulation is? I tried the docs but just ended up going round in circles.
[3 hidden]5 mins ago
If its up to this emulator to keep track of changes in Services APIs this is doomed to fail.
[3 hidden]5 mins ago
Yeah whatever they did internally to get service teams to actually adopt AWS Config ~5 years ago needs to happen here or it’s going to get stuck with marquee services and that’s it. Especially given this is a much much larger ask of each service.
[3 hidden]5 mins ago
I believe AWS already autogenerates their API clients (e.g. boto3) based on some authoritative internal service api spec so I imagine that spec could be used upstream of this tool as well.
[3 hidden]5 mins ago
Until the plan changes, which at some point, it will. Comment is still appreciated for what it is.
[3 hidden]5 mins ago
This is an Amazon product, not a Google product.
[3 hidden]5 mins ago
Amazon team killed the Copilot CLI[0] which I thought was the single best thing they ever did for AWS infra. Made it tolerable to deploy on AWS; still salty about this one.
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.
[3 hidden]5 mins ago
Azure on the other hand. Will throw products out, ensure they are never consistent with other offerings on their platform, and then deprecate it from under you while promoting the same thing with a new name.
[3 hidden]5 mins ago
I think there was some truth in this in the early days of Azure (and all clouds) as the companies were looking to work out what cloud services were really needed. I don't see this as much any more though esp when a services makes it to GA they have published commitments for service availability and API compatibility. (I was in Azure for 10+ years so definitely let me know if you disagree)
[3 hidden]5 mins ago
This is annoying for everyone.
[3 hidden]5 mins ago
And Azure will send you an email every day about how you need to migrate X to Y without any way for you to know where those instances are or how to find them.
[3 hidden]5 mins ago
You're certainly not wrong. But in the wake of Localstack's changes, the landscape has been full of slopware and low trust anyway. I don't think this is worse, for now at least.
[3 hidden]5 mins ago
Why would you say this? AWS are notorious for maintaining things.
[3 hidden]5 mins ago
"Things change over time" that is how the linear passage of time tends to work, yes.
[3 hidden]5 mins ago
I mean isn't that true for every single thing made by anyone? In that case what more do you want from them?
[3 hidden]5 mins ago
Except for things they make: forever maintained forever.
[3 hidden]5 mins ago
Nothing personal, but unless you can link us to a public announcement made by Amazon, your statement is worth less than nothing.
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.
[3 hidden]5 mins ago
I don’t take it personally; I realize you don’t know me, and a sentence on HN isn’t much of a guarantee.
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.
[3 hidden]5 mins ago
I didn't mean announcing the tool, I meant an announcement committing to the maintenance/support that users like the GP poster were looking for. My bad on describing that clearly, I'm gonna get clowned on in the comments and I'm not turning this around.
[3 hidden]5 mins ago
I understood what you meant. I was just trying to add evidence to support my claim that it was a real product and would be maintained. And yeah, votes on comments can be fickle.
GP statement still stands, actually being strengthened. This blog post doesn't even mention nor seems to care about maintainability or long-term support or anything that users will care about. Only talks about how cool the team is and how amazing they're at using AI, multi-agent workflows, and this kind of bs. It's funny how author talks so much about testing when they themselves also boast how they haven't written or reviewed any of the code.
[3 hidden]5 mins ago
[flagged]
[3 hidden]5 mins ago
You are talking to a person in some sort of relevant capacity and the abstract entity called “AWS”. You know that right?
[3 hidden]5 mins ago
This site is riddled with companies and commenters officially representing massive entities that go back on their promises. Are you saying that we should trust them just because they represent their company?
[3 hidden]5 mins ago
FFS this is a huge effort in an area that was badly under-served.
Can we just appreciate that they _appear_ to be doing the right thing here? Save the criticism for when (if?) they turn their backs.
[3 hidden]5 mins ago
Strongly agree. I've been wanting an official emulator from AWS for years. It looks like they've finally produced it, and it looks like somebody that works there is saying they're planning on maintaining it. And they've blogged that it was released. And somehow the comments are focusing on the fact that they haven't promised to maintain it for a long time. It's extremely rare to ever see statements about longevity when something is first announced.
[3 hidden]5 mins ago
HN has gone wildly cynical in a way I haven't seen in this community previously. It's exhausting, and makes me spend less time here.
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.
[3 hidden]5 mins ago
We can appreciate it while also recognizing that history repeats itself into disappointment while also recognizing that Amazon has done large social media campaigns (remember the FC Ambassadors?). I would have been more excited about this ten years ago.
[3 hidden]5 mins ago
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.
[3 hidden]5 mins ago
It has an official documentation on the AWS website, why would you assume it's not a real product? Because it was launched recently?
[3 hidden]5 mins ago
No docs site linked on the GH. 3 weeks old. 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.
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.
Almost every large thread has upvoted comments that violate the comment guidelines, now, too. In both cases, not enough people flagging them, I guess.
[3 hidden]5 mins ago
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 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.
[3 hidden]5 mins ago
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.
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!
[3 hidden]5 mins ago
Do I need to get certified to use it?
[3 hidden]5 mins ago
For me, what is interesting in this project is it's git history.
[3 hidden]5 mins ago
Wonder if this could be considered a replacement for Ministack which itself was a vibe-code replacement of Localstack?
Excited to see this develop and be a free replacement to localstack / similar providers.
[3 hidden]5 mins ago
Localstack is almost entirely free. I’ve used it at our company for years without paying.
[3 hidden]5 mins ago
Localstack is no longer free and if you’re using it commercially you need to pay for a license. The free plan explicitly states that it is non commercial.
The title for this story should be "aws-emulator, from AWS".
[3 hidden]5 mins ago
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.
Seems like a great fit for LLM - extensive documentation, plus a live system it can probe against freely to match the behavior.
[3 hidden]5 mins ago
29,000 commits in a month is crazy
[3 hidden]5 mins ago
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.
[3 hidden]5 mins ago
Seems like the bunch of AI induced failures they had "paid off" in getting this done
[3 hidden]5 mins ago
Will it be maintained? Or was it more of a toy-project for its large scale agentic blogpost? [0]
RIP LocalStack… can’t say I’d be unhappy to see it go though.
[3 hidden]5 mins ago
> 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.
[3 hidden]5 mins ago
~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?
[3 hidden]5 mins ago
Mh, no transfer family service... I wonder what else is missing..
[3 hidden]5 mins ago
ok who's gonna build the GUI / web console on top of it?
[3 hidden]5 mins ago
For what? Use the APIs.
[3 hidden]5 mins ago
I could see this being useful. Just let Console pick the localhost:xxxx endpoints for everything, boom, my "own" fake AWS.
[3 hidden]5 mins ago
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...
[3 hidden]5 mins ago
Finally!
[3 hidden]5 mins ago
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.
[3 hidden]5 mins ago
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.
it takes more time for my AI to learn their "emulator" . And I end up with far fewer dependencies on my own.
I've been prompting the agents to build everything using stdlib
[3 hidden]5 mins ago
I think having an interface with your AWS implementation and one for test mocks has always been great advice. With this though, it helps enable better integration testing too. I consider this a testing compliment, but if I had to choose one these days, integration tests are cheaper and better hang for your buck than ever.
I'll continue to choose both though, depending on the thing being tested.
[3 hidden]5 mins ago
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.
[3 hidden]5 mins ago
[flagged]
[3 hidden]5 mins ago
Their business isnt making software, its providing compute. Thats not automatable until we have physical AI driven robots mining silicon and turning them into chips to put in datacenters
[3 hidden]5 mins ago
OMG, you're correct! I just tried this prompt, and it worked:
“Claude, make my LLC into the largest global logistics business and largest U.S. cloud provider overnight. Thanks.”
[3 hidden]5 mins ago
Make no mistakes.
[3 hidden]5 mins ago
How could I forget that part! No wonder it didn’t get some of those third party contracted rates right.
[3 hidden]5 mins ago
I don't see Claude building a data center. Amazon is in no way obsolete.
[3 hidden]5 mins ago
he thinks VMs come from nothing
[3 hidden]5 mins ago
Big 'i can build it in a weekend' energy.
Nevermind the massive logistics and network infrastructure, enormous market position, etc.
Sure, you can build something in a few days. Replicating their business model? Yeah. No.
Call me when Claude can design, manufacture, ship, and build a data centre.
[3 hidden]5 mins ago
pass the blunt, I want a hit
[3 hidden]5 mins ago
What even is their business model, in your opinion? Make no mistakes.
[3 hidden]5 mins ago
The current state of AI psychosis.
[3 hidden]5 mins ago
Tell me you’re not in devops without saying you’re not in devops
HN.zip
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/
[0] https://aws.github.io/copilot-cli/
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.
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.
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.
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.
Background on how it was written
<https://news.ycombinator.com/newsguidelines.html>
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.
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.
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!
https://blog.localstack.cloud/2026-upcoming-pricing-changes/
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...
[0] https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent...
They can't help themselves, can they?
I'll stick with Floci and Testcontainers.
https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent...
I've been prompting the agents to build everything using stdlib
I'll continue to choose both though, depending on the thing being tested.
“Claude, make my LLC into the largest global logistics business and largest U.S. cloud provider overnight. Thanks.”
Nevermind the massive logistics and network infrastructure, enormous market position, etc.
Sure, you can build something in a few days. Replicating their business model? Yeah. No.
Call me when Claude can design, manufacture, ship, and build a data centre.