[paulddraper]

Iconoclast view ahead (change my mind please):

AWS does tons of stuff around VPCs....I feel like they really want me to use them (or their customers really want to use them), but I just don't see why.

I just run RDS on the internet. I don't have to muck with the complexity or cost of NATs or peering or Lambda slow start or any other weird networking issues.

I know it's "public", but that seems irrelevant in the era of cloud services. This isn't any different than, say, how Firebase or a million other services run. Should I be concerned that my Firebase apps are insecure because someone isn't overlaying a 10.* network on them?

EDIT: I should clarify that I understand the legitimacy of security groups, especially for technologies that weren't meant to operate outside a firewall. But that's mostly a different subject; AWS had security groups years before VPCs and subnets and NATs.

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

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

[fulafel]

This is true, AWS is pretty anti-internet in all their architecture recommendations. IMO security is better done by firewalling and protocol level authentication (belt + suspenders) because it keeps your configuration clean and understandable, and complexity is the enemy of security.

The attitude has two things in AWS interest: 1) keep lock-in by encouraging customers to build AWS-internal networks 2) don't scare away the lift-and-shift customers who want to transplant their 1990s style "intranet" (or mental model, at least) onto AWS.

Explains also why they aren't very keen about IPv6 because that would encourage internetworking.

Just don't tell anyone that you can access the AWS console from the internet :)

[scarface74]

It’s never been considered best practice to expose services needlessly to the Internet. I’m as far from an old school net ops guy as you can get and jump at any new AWS technology that’s feasible as anyone but it would be the height of stupidity for me to expose my Aurora cluster to the Internet. Good luck explaining that to your external auditors.

[fulafel]

Of course. I'm just saying that firewalling and end-to-end security are better ways of doing that than routing and ambiguous (rfc1918) addressing. Never trust the network, lest you end up making yours soft and chewy on the inside.

[scarface74]

How do you propose you firewall your database access and only allow certain IP addresses when you need access from lambda when the lambda is always run from a random location on AWS’s network?

A lambda is never run “from within your VPC”, it’s attached via an ENI (or at least it was).

[fulafel]

Yeah, this kind of thing is part of what I meant when I criticised AWS encouraging VPC use instead of end-to-end security.

But off the top of my head, you could always use the firewall API from the lambda to open network access between it and the RDS when the lambda starts. (In addition to using certs or IAM security on your TLS connection to the RDS db)

[scarface74]

And then you are depending on a proprietary connection and authentication protocol instead of being able to use the standard MySQL/Postgres drivers.

Also, how do you handle the commercial hosted databases like Sql Server and Oracle?

[enitihas]

VPCs are very useful when running things like elasticache though( memcache and redis), because AFAIK those don't have an authentication ecosystem so making them public would be a terrible idea.

[paulddraper]

Memcache has had reliable authentication (SASL) for some time. Redis has authentication meant to be a secondary protection.

But that's a good point.

I suppose all the services I use already have security models (usually more complex, multi-user ones, so agent X can read but not modify, etc.).

HOWEVER...this could be solved with security groups, but it seems that's not the model AWS has emphasized. Security groups are orthogonal to NAT and private networks; AWS had security groups before it had VPCs.

[saurik]

Just use security groups, which fully solved this problem without all of the overhead and complexity of VPC.

[cle]

Defense in depth. Not having public routes to your database adds another layer of protection. You should have multiple, and they should be redundant.

[Scarbutt]

Firebase was made specifically for the cloud, RDS is the cloud atop postgres, I don't know how secure RDS is (against the myriads of attacks) but it wouldn't be bad idea to use the built-in aws firewall to at least restrict access to trusted IPs ;)

Also, VPCs are really useful if you have many systems and services(yours or theirs) inside AWS.

[dragonwriter]

> RDS is the cloud atop postgres

Or MySQL. Or SQL Server.

[paxys]

Exposing a database to the public internet is a terrible idea. Yes, it's behind an auth layer, but is a username and password really enough protection for literally all of your company's data? Heck most people here have probably set up 2FA for their social media profiles, and for good reason.

[paulddraper]

> Exposing a database to the public internet is a terrible idea.

Isn't that a core idea of Firebase? Or Dynamo?

[paxys]

Not sure about Firebase, but DynamoDB can be behind your VPC. From what I know about Firebase, it's meant to be a backend for mobile apps, so I guess it makes sense for it to be public.

[dragonwriter]

> AWS does tons of stuff around VPCs....I feel like they really want me to use them (or their customers really want to use them)

VPC is a very convenient fit for enterprise customers extending on-premises networks into the cloud, I think that's the market it's mainly focussed on.

> I know it's "public", but that seems irrelevant in the era of cloud services.

It's not irrelevant, but neither is it necessary critical all the time; there doesn't need to be a one-size- (or even one-shape-)fits-all universal approach to network security, and AWS encompasses a lot of different customer setups, including enterprises for which it is a virtual extensions of the on-premises internal network.

[serkanh]

Say you have bunch of ec2 instances with public ip addresses that runs an application that makes calls to 3rd party service. Say that 3rd party service allows only access from certain ip ranges, would you rather give them a single ip or hundreds of ips for them to whitelist? What you say may be acceptable for small infra but not in large setup.

[momokoko]

You need to realize that the point of AWS is lock in. Once your service becomes a ball of various AWS pieces, it becomes almost impossible to leave once you start scaling.

So there is always a priority towards things that cause more lock in like VPC.

[AmericanChopper]

I don’t think AWS want you to use VPC at all. The Golden Path for serverless on AWS has always been “networkless”. If your use case fits into their stateless HTTP stack (API Gateway + Lambda + Dynamo + SQS...) then you’re gonna have a really easy time. The reason VPC is required is because not every use case is going to fit into that stack, and the fact that VPC functionality seems to be always just a little bit not good enough (in comparison) doesn’t make me think they’re pushing people towards it.

[zten]

They definitely do if you're trying to use things based on EC2 instances. The newest types of instances have been VPC-only for years now.

[AmericanChopper]

But if you’re using EC2, then you’ve already wandered far off the serverless path.