upvote
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.
reply
Sort of. The releases page leads you to a massive blob of json with all the compatibility tests and scores.

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.

reply
Asked a clanker to correlate the test data (link in parent) with: https://raw.githubusercontent.com/aws/aws-emulator-evaluatio...

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%

Pass rates from the release's scores.json (commit 7753983), joined with the eval suite's manifest.jsonl. Tests = behavioral checks touching the service. All = overall pass rate. Happy/Reject = valid requests vs. requests AWS should refuse. Ctrl/Data = control plane vs. data plane. Solo/Integ = single-service vs. multi-service checks. Wire# / Wire% = count and pass rate of recorded request/response replay tests (a test passes only if every call matches).

Edit: Also worth a look: https://ministack.org/blog/aws-emulator

reply
If its up to this emulator to keep track of changes in Services APIs this is doomed to fail.
reply
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.
reply
But their auto generated API clients don't have the invariant baked into them, which makes them very rough to use in say Rust.

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] }
Except, this is not defined in schemas, this is merely defined in prose around the documentation.

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.

reply
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.
reply
AWS Config already doesn’t support some pretty important things
reply
Agreed but it used to be way way worse.
reply
AWS has lots of unfunded mandates like this and they historically just depended on bleeding the souls of engineers and managers to get done.

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.

reply
There are many AWS services. Simply offering an alternative to a few of the most used could be a good business. It doesn't have to cover all AWS in all release versions, just enough to get and hold some clients
reply
This wasn't clear to me, either.
reply
I mock (ask Claude Code to make something run in a container) my own AWS services today for CI and development. I'm excited to learn more about how AWS uses it and hopefully use this for CI and development.
reply
Not to be rude, but your profile doesn't list who you are in relation to AWS.
reply
Any chance it will be able to spawn actual containers in the future?
reply
That is pretty much the key thing IMO. It needs to be able to run our actual code, locally, with fairly high fidelity to the real thing in terms of behavior.

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.

reply
Okay I've asked for this product for literally years on a cadence of every 18 months, so I'm very thankful to hear this.
reply
>> 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.

> 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.

reply
Planning to maintain probably means planning to continue telling Claude to maintain it
reply
And that’s probably something that AI will be really good at.
reply
Good! Been waiting for a first party thing like this.

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.

reply
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.

reply
I don’t take it personally; I realize you don’t know me, and a sentence on HN isn’t much of a guarantee.

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.

reply
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.
reply
It has its official document page: https://docs.aws.amazon.com/emulator/latest/userguide/gettin... and it lives in https://github.com/aws/ org. I think AWS is pretty committed.
reply
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.
reply
I think one thing that concerns many people is that this looks like AI slop, which it clearly is according to the blog post.

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?

reply
To me, something like this is actually what vibe coding thrives the best at; tight, looped, easily verifiable, test-driven dev work. In fact, this is probably the field it can do with little or no intervention, if you're willing to waste tokens.
reply
Is it? How is it verified that this catches all the potential edge cases of interacting with AWS? Or is handling all the edge cases of AWS not in scope?

Like, what am I actually getting here? Is it just happy path operations being correct here?

reply
For real edge cases, it will be like any other software. Users get to be the guinea pigs and report bugs as they find them.

Hopefully AWS has had enough internal guinea pigs before they published this!

reply
In the near future, every case will be a real edge case and every one will be a guinea pig.

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.

reply
Back in the day, we assumed that when a major company open sourced code, that code would have problems. We invented all these things like ‘issues’ to deal with this.
reply
reply
deleted
reply
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.
reply
Also doesn't mention any benchmarks or compatibility matrix.

This feels like table stakes for an emulator.

reply
Until the plan changes, which at some point, it will. Comment is still appreciated for what it is.

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.

reply
This is an Amazon product, not a Google product.
reply
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.

[0] https://aws.github.io/copilot-cli/

reply
Yes, we are still struggling with a good replacement. The way they handled this - from steady release cadence to complete stop with no info at all but just speculations makes me very reluctant to adopt AWS maintained projects.
reply
There has been no food replacement as far as I can see that doesn't involve writing a pile of code for what Copilot was doing with a few lines of config.
reply
deleted
reply
The two have different failure modes.

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.

reply
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.
reply
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)
reply
Yeah I disagree. First of all, Azure is mostly garbage so avoid it if you can. Second of all, Azure deprecation follows Microsoft's general policy of deprecation which is The Fadeaway Policy. Don't publish anything publicly about it, gut the team to go work on something else, transfer the service to be one of 6 dozen other services some random offshore team is "maintaining", experience enough outages and trouble and during every support call they nudge you to move to something else, but the service is "totally not deprecated" because we haven't gotten a memo that says that, but we're only doing "security" fixes now. wink wink, nudge nudge.
reply
Fine to disagree - but it would be better to share real insights rather than just blanket statements. Sounds like you have had some bad experiences - maybe you could share more?
reply
Let me quickly compile a list of the last 700 failing bicep deployments with an “Internal Service Error” or No capacity errors along the all the no-op idempotent puts that take 30+ minutes for some reason, the broken networking system all up, the constant support advise to move to different regions, except half the things you use are not in that region, or the constant advice to just delete everything and start again or the half docs half marketing fluff docs. Azure only exists because large enterprise looks at a list of checkboxes before signing a contract. No reasonable person should ever use that garbage unless you’re offered deep discounts to do so, and even then, limit your usage to things you can migrate easily whenever the discount expires.
reply
Yup I hear you with bicep. Post Microsoft I've used either Terraform or Pulumi. Sorry to hear about the other issues.
reply
To be fair, that's Microsoft in general
reply
This is annoying for everyone.
reply
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.
reply
deleted
reply
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.
reply
Why would you say this? AWS are notorious for maintaining things.
reply
"Things change over time" that is how the linear passage of time tends to work, yes.
reply
I mean isn't that true for every single thing made by anyone? In that case what more do you want from them?
reply
As someone who used QLDB as a WORM audited log for a financial system, and ran AWS classes that used Cloud9, they do depricate.

Not many, and not often but it is annoying.

reply
A bit more polish for a public facing artifact from a multi-billion dollar org with armies of engineers and big token budgets.

The Copilot CLI https://aws.github.io/copilot-cli/ you can feel polish and pride of the team that built this, as an example.

reply
Except for things they make: forever maintained forever.
reply
[flagged]
reply
You are talking to a person in some sort of relevant capacity and the abstract entity called “AWS”. You know that right?
reply
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?
reply
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.

reply
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.
reply
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.

reply
It comes from a history of this sort of thing where an Amazon staff person will say that X will always or never happen and then their promises falls flat because of big company dynamics.

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."

reply
I've tripped several times in my life while walking. I've even hurt myself a few times. I don't go outside wincing to myself about whether I'm about to fall and hurt myself.

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.

reply
Your tripping example is incredibly patronizing.

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.

reply
I had a similar experience on my bike and chose to get back on, though it certainly took me a while, and I've stopped riding in weather and in other conditions. My family supported me in my decision. I guess you and I are just wired differently.

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.

reply
You're making a lot of assumptions about me, what my risks are/aren't and... dude, can you not, please? I sold my motorcycle and once I recovered, I rented a motorcycle out in New Zealand as a sendoff and I reflect on that time with deep joy and appreciate the deep joy that others feel when they ride motorcycles. But I would not blame anyone for stopping, or infantilize them like you're doing to me now.

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.

reply
> 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.

reply
Thank you for articulating in this reply what I've struggled to put into words, and what made me write the initial comment about cynicism on HN.
reply
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.
reply
Sure, and I agree they have a mixed track record, but leading with cynicism isn't particularly great. They're not Google.

Now if they abandon it, then sure, light them torches.

reply