[saurik]

So making the actual listening port for a database server "public" is generally a bad idea as that is another attack surface of code that honestly is hardly ever made public... but if when you say "public" you mean you are using security groups (which are super trivial to use and easy to understand) to define which other AWS devices can access the port, then yeah: I have never seen any reason why this entire feature should exist and the concept of having to think about IP address ranges as if they somehow matter is one of the things I was escaping when I moved to cloud in the first place, and somehow they wanted to reintroduce it? Why?!? It doesn't even work well (!!), and introduces tons of latency into everything it touches (not just Lambda) :/.

[scoopertrooper]

VPCs are very helpful for when you have a large number of developers working in an AWS environment. It'd be oh so easy for a developer to accidently change a bit of terraform and expose your database to the internet without VPCs.

[paulddraper]

My theory is that a bunch of entrenched network engineers just really like subnets and IPv4 and NAT and don't realize how mostly unnecessary it is in an era of cloud infrastructure and IPv6.

My grandchildren are still going to be NAT'ing.

[StreamBright]

I think it is easy to have dev, qa and prod VPCs. Without VPC these separate infrastructure groups might be harder to split out. I usually reference security groups instead of subnets in security groups, avoiding referencing IP ranges (v4 or v6) entirely.

[watermelon0]

You can also use multiple AWS accounts to separate those environments, which also eases user management (usually you have different people with access to each environment, with some overlap).

This also means that developers can have close to admin privileges, since the worst they can do, is to disrupt work of another developer, without affecting either QA or production.

[WaxProlix]

Accounts are the correct level to separate these at. Keeps credentials easier to manage for devs, techs, etc, and limits blast radius if unauthorized accesses take place.

[StreamBright]

>> This also means that developers can have close to admin privileges

>> limits blast radius if unauthorized accesses take place.

I am not sure if admin privileges are the right way of limiting blast radius. Reasonable roles with least privileges are.

"In information security, computer science, and other fields, the principle of least privilege (PoLP), also known as the principle of minimal privilege or the principle of least authority, requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose."

[WaxProlix]

Yeah, and you want those roles and accounts scoped appropriately. Someone with the 'Admin' role in a pre-prod account wouldn't necessarily get that same role in a production one. Someone with admin in a standard prod account might not get that same privilege in an account that you manage for a customer, or one with extra compliance requirements, etc.

[scarface74]

Which is really an old school way of doing it. Having multiple VPC's doesn't get around account limits, resources with the same name (sns topics, queues, stacks, etc.)

Just use separate accounts in an Organization.

You can give your developers almost complete unrestricted access to your dev account.

[StreamBright]

I work with both style of AWS installations. Having organization is a constant pain for people who access multiple accounts even with something like Okta. 1 browser can access 1 account and if you switch you have to go through the switching process, or use multiple browsers. Quite often people would like to access cross account resources which a whole different level of discomfort. This is why I still think, old school or not, that having a single account and multiple VPCs is a better option.

[scarface74]

If you’re using AWS as a more expensive colo and mostly just using VMs it’s fine. But once you start actually using AWS for anything else it’s s pain. You have to worry about the different service limits and they are all shared.

What’s the process for giving developers access to experiment? When you have different accounts, the development department can have basically unlimited access to the account and moving to production is basically getting a CloudFormation template approved and run by the Devops team.

[StreamBright]

I am not using AWS as a more expensive colo, actually as a much much cheaper colo instead. I have optimized several workloads on AWS to save several hundred thousand / year for companies. In my experience giving unlimited access to anybody is a fairly bad idea since it that credential gets stolen you are going to quickly figure out how much a bitcoin mine costs on AWS. I find it counter productive to have a separate DevOps team and prefer the DevOps resources embedded into teams. I also do not like CloudFormation, it is a horribly verbose and complicated tool there are many alternatives that are better for the use cases for the customers I work with.

I agree that you have to worry about service limits which is exactly the right thing to have, instead of living a wasteful life pretending that we have infinite resources.