Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improved VPC Networking for AWS Lambda

aws.amazon.com

Post reply on HN
Print view View original

81–90 of 100 posts

Re: Improved VPC Networking for AWS Lambda

#81

Post by fulafel »

Niksko wrote: post #69
fulafel wrote: post #63

Earlier quoted context omitted.

But VPC is not an especially efficient additional "defense-in-depth" layer against this kind of "fucked up both firewall and password" configuration mistake. The first 2 obvious ones are passwords, network-level firewalling, host-level firewalling of course, and after that you can add monitoring / port scanning for all your "must be firewalled" services. And you can mandate better-than-passwords authentication method…

You mention defense in depth, but then immediately decide that an extra layer of defense is unnecessary.

Are you proposing that by acknowledging defense-in-depth, consistency dictates that one should pile up as many layers per attack vector as possible? Maybe, if you have infinite resources and don't need to make compromises on where you spend effort and resources in your risk management plan. But that's rarely the case in the real world.

Re: Improved VPC Networking for AWS Lambda

#82

Post by fulafel »

scarface74 wrote: post #80
fulafel wrote: post #62

Earlier quoted context omitted.

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 awa…

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.

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.

Re: Improved VPC Networking for AWS Lambda

#83

Post by [deleted] »

scarface74 wrote: post #79
abhorrence wrote: post #60

Earlier quoted context omitted.

You can run your own gateway instance(s) for a lot cheaper than the nat gateway service. There are definitely some tradeoffs, but if $36/mo is an issue, they can be worthwhile: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Ins...

This is not meant to be a criticism of AWS, I’m an AWS true believer, but the main purpose of going to AWS is to make the “undifferentiated heavy lifting” someone else’s problem not to save money. Going to AWS to save money on resources is about like going to the Apple Store to buy a cheap laptop.

[deleted]

Re: Improved VPC Networking for AWS Lambda

#84

Post by scarface74 »

fulafel wrote: post #82
scarface74 wrote: post #80

Earlier quoted context omitted.

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.

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.

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

Re: Improved VPC Networking for AWS Lambda

#85

Post by serkanh »

paulddraper wrote: post #8

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 o…

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.

Re: Improved VPC Networking for AWS Lambda

#86

Post by fulafel »

scarface74 wrote: post #84
fulafel wrote: post #82

Earlier quoted context omitted.

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.

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

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)

Re: Improved VPC Networking for AWS Lambda

#87

Post by scarface74 »

fulafel wrote: post #86
scarface74 wrote: post #84

Earlier quoted context omitted.

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

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)

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?

Re: Improved VPC Networking for AWS Lambda

#88

Post by fulafel »

scarface74 wrote: post #87
fulafel wrote: post #86

Earlier quoted context omitted.

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)

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?

Certs is a standard feature. IAM doesn't require nonstandard client or protocol features either (see https://aws.amazon.com/premiumsupport/knowledge-center/users...).

I think with client certs work fine with SQL Server and Oracle too, with standard clients.

But I'm sure you can come up with imagined scenarios where you end up cornered to use VPCs. I get it, these situations may exist. I'm just saying they suck, not that you'll never have to resort to them.

Re: Improved VPC Networking for AWS Lambda

#89

Post by paulddraper »

paxys wrote: post #65
paulddraper wrote: post #8

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 o…

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.

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

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

Re: Improved VPC Networking for AWS Lambda

#90

Post by StreamBright »

scarface74 wrote: post #75
StreamBright wrote: post #66

Earlier quoted context omitted.

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 scho…

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 pr…

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.

Post reply on HN