[mikeocool]

Personally, I would get value out of really solid compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind) with a light weight gui interface and persistence.

If I’m getting into esoteric features or some “big” features that don’t make sense locally, then I just spin up a real dev account of aws, so I know I’m getting the real experience.

[petcat]

> getting into esoteric features

The problem is that everybody needs different "core" features

> > compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind)

For instance, I don't care about any of those features at all. But I would care a lot about EC2, RDS, and ElastiCache Redis

[mikeocool]

Interesting — those are the ones that depending on the case, approximating them with local redis/postgres/vms without the AWS specific APIs on top is often good enough — because my app is just talking to them over native protocols anyway.

Or I am doing something so specific, that a local emulation of the aws api isn’t ever going to be good enough, so there’s not a lot of point in trying. For example, writing code that handles automatically spinning up RDS instances from an RDS snapshot — a local emulation of that process is going to be so far off from what would actually happen no matter what they do.

[drzaiusx11]

I'd put ALL the ones listed above: SQS, S3, KMS, DynamoDB, EC2, RDS, Redis in the required "core" services column, and also throw in IAM, SNS, and SecretsManager as well. Those are all table stakes imho.

I'm using all of the above in LocalStack today. Frankly, I don't believe this is as "impossible" a task as several in this thread are insinuating. It's the type of rote work you can delegate to AI to build these days, as observed in this OP.

Building a test suite to validate the state-transient mocks in question against the real deal is not difficult. Only annoyingly expensive (in time and money) if run often, which is exactly the problem they're solving.

[lucas_vieira]

This is exactly the approach fakecloud takes — depth over breadth. 13 services right now, but each one is conformance tested against the AWS Smithy API models (34,856 test variants). The bet is that fewer services with correct behavior is more useful for integration testing than broad coverage that surprises you in production.