[thezenmonsta]

Local AWS emulators are one of those tools where the value is inversely proportional to how much you trust your staging environment. If your staging account perfectly mirrors prod, you don't need a local emulator. But nobody's staging perfectly mirrors prod, so you end up needing something like this for the fast feedback loop on IAM policies, Step Functions state machines, and anything involving SQS/SNS fanout where the iteration cycle against real AWS is measured in minutes per attempt. The question is always parity — how closely does the emulation match real AWS behavior at the edges? LocalStack has been chasing that for years and still hits gaps. Curious how Floci handles the services where AWS's own behavior is underdocumented.

[hnlmorg]

The point of tools like this is for development, not staging. By “development” I don’t just mean developers writing code, but any unit tests that require behavioural testing that cannot easily be mocked too.

So by the time you’re ready to push to staging you should be past the point of wanting to emulate AWS and instead pushing to UAT/test/staging (whatever your naming convention) AWS accounts.

Ideally you would have multiple non-production environments in AWS and if your teams are well staffed then your dedicated Cloud Platform / DevOps team should be locking these non-prod environments from developers in the same way as they do to production too.

Bonus points if you can spin up ephemeral environments automatically for feature branches via CI/CD. But that’s often impractical / not pragmatic for your average cloud-based project.

[rienbdj]

Ultimately you need staging, yes.

But you can’t have every dev tweaking staging at the same time as they work. How can you debug things when the ground is shifting beneath you?

Ideally every dev has their own AWS account to play with, but that can be cost prohibitive.

A good middle ground is where 95% of work is done locally using emulators and staging is used for the remaining 5%.

One of the first things I do when building a new component is create a docker compose environment for it.

[cosmotic]

Relying on staging means no offline development and also leads to toe-stepping. Cheap local implementations are great for consistent tests.

[drzaiusx11]

100% this. I've used AWS emulation layers for local-first development going on the better part of a decade. I cannot stress how much time it saves me from pushing code that would have failed in staging. When the cost of deployment pipelines via cloudformation is so high, it's a no brainer.

DIY mocks alone can get you somewhat there, but that relies on the developer having intimate knowledge of the aws sdk under test and it's very easy to mock the inputs and outputs wrong. I'd rather defer that to an emulation layer that does that mimicry better than my guess and check with 30m between attempts when my cloudformation deployments ultimately fail...