[wiether]

A few notes about "local AWS" (or "local cloud") based on other comments and my own XP:

- I'm not sure this kind of product is really a foot in the door to create new customers. Someone not willing to create an actual account because they have no money or they just don't want to put their card details is not someone who's going to become a 6 figures per year customer, which is the level to be noticed by those providers.

- The free tier of AWS is actually quite generous. For my own needs I spend less than $10/year total spread around dozens of accounts.

- If one wants to learn AWS, they MUST learn that there are no hard spend limits, and the only way to actually learn it, is to be bitten by it as early as possible. It's better to overspend $5 at the beginning of the journey than to overspend $5k when going to prod.

- The main interest of local cloud is actually to make things easier and iterating faster, because you don't focus on all the security layer. Since everything is local, focus on using the services, period. Meanwhile, if you wanted to rely on actual dev accounts, you need to first make sure that everything is secure. With local cloud you can skip all this. But then, if you decide to go live, you have to fix this security debt and it most often than not break things that "work on my computer".

- Localstack has the actual support of AWS, that's why they have so much features and are able to follow the releases of the services. I doubt this FOSS alternative will have it.

[regularfry]

Security is the entire reason I want tools like this. Specifically for emulating IAM: if you've got a hard organisational "least privilege" mandate then you start with virtually nothing allowed and have to enable permissions for the explicit set of API calls you're using. You're not doing `Allow :` but you're also not using AWS-managed roles. That combined with the fact that - certainly with terraform - there's no mapping between "I need to manage this resource" and "these are the permissions needed to do so" means that every time you do something new in your infrastructure you're going into a game of permissions whack-a-mole where the deploy/fix/deploy cycle can easily take a multiple of the time it took to develop the feature you want to deploy, because one trip round the loop is a full attempted deployment. Whereas if there's an accurate local emulator not just of the feature but of the permissions attached to it, you can shortcut the slow bit.

Localstack does have IAM emulation as part of the paid product. I'm intrigued to see how well this does at the same thing.

[CSDude]

A major use case for LocalStack is CI/CD.

When you're running hundreds of integration test suites per day in CI pipelines, the free tier is irrelevant. You need fast, deterministic, isolated environments that spin up and tear down in seconds, not real AWS calls that introduce network latency, eventual consistency flakiness, rate limits, and costs that compound with every merge request.

It'd be great to just use AWS but in practice it doesn't happen. Even if billing doesn't, limits + no notion of namespacing will hit you very quickly in CI. It's also not practical to give every dev AWS account, I did it with 200 people it was OK but always caused management pain. Free tier also don't cover organizations.

> they MUST learn that there are no hard spend limits, and the only way to actually learn it, is to be bitten by it as early as possible

This is a bizarre take. "The best way to learn fire safety is to get burned." You can understand AWS billing without treating surprise charges as a rite of passage.

[cyberax]

The main use case for local emulators is unit testing. Maybe even some integration testing, especially for stuff like VPC setup that often can't be done without global side effects.

Security for dev accounts is not a big deal, just give each developer an individual account and set up billing alerts.

[wiether]

> Security for dev accounts is not a big deal, just give each developer an individual account and set up billing alerts.

If your only focus is spending, yes.

Otherwise, a "not a big deal" dev account can quickly become the door to your whole org for hackers

[cyberax]

It really depends on the way you set it up and use it. Raw EC2 instances are obviously the most dangerous items.

RDS databases, DynamoDB, and S3? Much less so.

[wiether]

> you set it up and use it

That's my point: I'm not the one setting it up and using it, it's the devs using it

And I'm not expecting them to know how to navigate a cloud provider securely.

So it's either setting the dev account with all the required guardrails in place, or using "local cloud" on their computer