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

91–100 of 100 posts

Re: Improved VPC Networking for AWS Lambda

#91

Post by StreamBright »

WaxProlix wrote: post #51
watermelon0 wrote: post #34

Earlier quoted context omitted.

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.

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.

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

Re: Improved VPC Networking for AWS Lambda

#92

Post by scarface74 »

StreamBright wrote: post #90
scarface74 wrote: post #75

Earlier quoted context omitted.

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…

The issue is that you have “shared” service limits between Dev, QA, and production. With separate accounts you can have service limits per environment. If you are worried about limiting dev resources, it’s a lot easier to do it per account using an organization.

How do you propose automating resource creation if not using either CloudFormation or an equivalent tool.

For instance, Parameter Store and Lambda have account level service limits. For lambda it’s 2000 concurrent instances. Do you really want all of your environments sharing that limit.

Parameter Store has a strict unchangeable limit per account. Do you want your dev environment affecting production?

Re: Improved VPC Networking for AWS Lambda

#93

Post by jimmychangas »

k__ wrote: post #73
scarface74 wrote: post #50

Earlier quoted context omitted.

No. Using an RDMS instead of DynamoDB is not a “legacy” architecture. You also shouldn’t expose your database publicly.

RDMS is not legacy, but perimeter security certainly is.

Honest question: what, in you opinion, is the state-of-the-art approach? Something like BeyondCorp?

Re: Improved VPC Networking for AWS Lambda

#94

Post by paxys »

paulddraper wrote: post #89
paxys wrote: post #65

Earlier quoted context omitted.

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?

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.

Re: Improved VPC Networking for AWS Lambda

#95

Post by scarface74 »

StreamBright wrote: post #68
scarface74 wrote: post #36

Earlier quoted context omitted.

Which is a horrible idea.... How many lambdas do you keep warm? 5, 10, 20? Every new connection is a new lambda instance. You're still just delaying the inevitable. Just use Fargate if you want to stay serverless and don't want the cold start times -- well at least before today.

Sorry but it does not matter how many since everything is automated and you create the warm up scheduler when you create the function. As other pointed out in this thread that are other challenges with this approach. >> Just use Fargate We were trying to and we decided that is not our cup of tea. Lambdas are.

Yes it does matter. In your scheduler, how do you ensure your ping (the way you start an instance) is actually creating another instance to keep warm or reusing another instance?

If you want to always keep 20 instances warm, you have to keep the first ping active until the 20th one is done.

In other words, if you want to keep 20 active instances warm and you send 20 requests in 5 seconds, if each request only takes .25 seconds. You will only have 5 warm lambdas. The 6th real concurrent connection will still have a cold start. Also while you are pinging the request to keep it warm, that instance can serve a real user.

Also, API Gateway has an algorithm to decide whether to launch a new lambda are cache a request hoping that using an already warm lambda will free up.

Re: Improved VPC Networking for AWS Lambda

#96

Post by k__ »

jimmychangas wrote: post #93
k__ wrote: post #73

Earlier quoted context omitted.

RDMS is not legacy, but perimeter security certainly is.

Honest question: what, in you opinion, is the state-of-the-art approach? Something like BeyondCorp?

I think zero-trust goes into a good direction.

https://www.securityroundtable.org/zero-trust-approach-can-m...

Re: Improved VPC Networking for AWS Lambda

#98

Post by reilly3000 »

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.

I’m not against AWS or $36/mo. It just is kinda a drag when the promise of serverless is pay per user and scaling to zero. You could get a nice EC2 t3.medium and do a lot more RPS for the cost of that NAT and Lambda invocations.

Re: Improved VPC Networking for AWS Lambda

#99

Post by scarface74 »

reilly3000 wrote: post #98
scarface74 wrote: post #79

Earlier quoted context omitted.

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.

I’m not against AWS or $36/mo. It just is kinda a drag when the promise of serverless is pay per user and scaling to zero. You could get a nice EC2 t3.medium and do a lot more RPS for the cost of that NAT and Lambda invocations.

If you don’t care about cold starts, there is always Aurora Serverless with the Data API. I don’t believe it requires either a NAT or for the lambda to be attached to your VPC.

Re: Improved VPC Networking for AWS Lambda

#100

Post by WaxProlix »

StreamBright wrote: post #91
WaxProlix wrote: post #51

Earlier quoted context omitted.

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.

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

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.
Post reply on HN