Improved VPC Networking for AWS Lambda(aws.amazon.com) |
Improved VPC Networking for AWS Lambda(aws.amazon.com) |
I have tried building an API using API Gateway <-> Lambda, but had to choose between using DynamoDB to store data (no-SQL, so challenging to query) or suffering unacceptably long response times whenever a request happens to cause a cold-start. Theoretically, this problem is now going away!
You could always have fast startup with Lambda + database outside the VPC.
"A database server was found with an open port exposed to the internet and no or poor authentication, all records were exposed."
This also should mean that Lambda's can get stable public IPs through a VPC for firewalls as well.
*edit for must to most.
I think it’s best not to expose the DB to outside connections in general, although it is still possible [1] when using RDS instances.
I think this is different for things like DynamoDB because, instead of a standard SQL-like db “connection”, they use AWS role-based auth for each request.
Of course, one could always configure some type of proxy service between the lambda and the DB... but that seems antithetical to going “serverless” in the first place.
[1] https://stackoverflow.com/questions/45227397/publicly-access...
Edit: I thought it was not possible to expose an RDS instance outside of a VPC, but I was wrong (you can place it in a public subnet, linked in [1]).
AWS is a beautiful mix of business and technology, it's very rare to see such a large engineering-driven organization managing to balance customer friendliness. I'm an unashamed fanboy
As far as I know this was only an issue for legacy architectures.
Stuff like this is pain in the ass, it was a major problem
Overall, definitely a big win!
You can connect API-Gateway with other services via Velocity templates, which don't have cold starts.
AppSync also doesn't suffer from cold starts.
Both are also serverless services.
Lambda is good if the other solutions are missing something, so you can drop it in quickly, but I wouldn't use it as the go to services for that...
There has never been a guarantee of environment reuse. Any architecture which isn't capable of incurring cold starts is not a good fit for serverless.
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.
There are some workarounds that using multiple lambdas, but they have their own gotchas.
Still, hooray, this is good news. The Data API is great for Serverless Aurora, but I can't use that with BI tools.
Going to AWS to save money on resources is about like going to the Apple Store to buy a cheap laptop.
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.
My grandchildren are still going to be NAT'ing.
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 :)
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.
Also, VPCs are really useful if you have many systems and services(yours or theirs) inside AWS.
Or MySQL. Or SQL Server.
Isn't that a core idea of Firebase? Or Dynamo?
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.
So there is always a priority towards things that cause more lock in like VPC.
You can write Velocity templates for integration responses.
Normally they are JSON because that's what all the AWS services return and API-Gateway just passes them along.
But you could write something like this:
#set($pets = $input.path('$'))
<html lang="en">
<head>
<meta charset="utf-8">
<title>Pets</title>
</head>
<body>
<table>
<th>ID</th>
<th>Type</th>
<th>Price</th>
#foreach($pet in $pets)
<tr>
<td>$pet.id</td>
<td>$pet.type</td>
<td>$pet.price</td>
</tr>
#end
</table>
</body>
</html>[1] https://forums.aws.amazon.com/thread.jspa?threadID=288043
>> Just use Fargate
We were trying to and we decided that is not our cup of tea. Lambdas are.
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.
[1] For example https://www.postgresql.org/docs/current/auth-cert.html or https://aws.amazon.com/premiumsupport/knowledge-center/users...
https://www.securityroundtable.org/zero-trust-approach-can-m...
A lambda is never run “from within your VPC”, it’s attached via an ENI (or at least it was).
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)
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.
Just use separate accounts in an Organization.
You can give your developers almost complete unrestricted access to your dev account.
Also, how do you handle the commercial hosted databases like Sql Server and Oracle?
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.
>> 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."
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.
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.
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?