AWS Lambda now supports IPv6 endpoints for inbound connections | Hacker News Reader

AWS Lambda now supports IPv6 endpoints for inbound connections

aws.amazon.com

127 pointskiyanwang31 comments

Its not the lambda run time that gets Ipv6, its the lambda API that is now dual stack. (the endpoint you hit when you want to invoke a lambda.)

When you do an invoke, if you use lambda.us-east-1.api.aws instead of the old ipv4 only lambda.us-east-2.amazonaws.com you will hit a v6 ula if you are on v6:

so if you want to talk to ipv6 unicast endpoint to invoke a lambda do so by specifying the new endpoint with --endpoint-url:

aws lambda invoke --function-name my-function out --log-type Tail --endpoint-url lambda.us-east-1.api.aws

> lambda.us-east-1.api.aws Server: one.one.one.one Address: 1.1.1.1

Non-authoritative answer: Name: lambda.us-east-1.api.aws Addresses: 2600:1f18:20cb:b301:7ced:3d08:1e2b:ed32 2600:1f18:20cb:b303:fa58:3743:b0dd:f703 2600:1f18:20cb:b302:d19a:21c7:11ee:8ad2 54.85.112.20 3.220.153.240 34.235.81.32

IPv6 to save costs on IPv4 addresses will become the standard I think. Multiple providers are starting to offer cheaper services without IPv4 where you can get a load balancer or floating IPv4 address. In a relative sense it would also be more secure as it would be hard to scan IPv6 ranges. Although you could argue that people should use private networks and maybe not use IPv6 at all.

> Although you could argue that people should use private networks and maybe not use IPv6 at all.

Managing 10/8 space is still a chore in an organization when you have lots of vpcs and lots of subnets per vpc; even with private space ipv4 is too scarce. I'm hoping ipv6 will help with that

That, and the added fun when you try to bridge two organizations' networks and find out that some internal ranges are used by both.

It can be "solved" using various NAT schemes on one or both sides, but the network setup gets increasingly spaghettified. :)

This is a nightmare the bigger it gets. Once there were about 15 companies it was easier to just create a new shared space for any new things.

Does this mean one can connect to a specific Lambda directly without having an API gateway and/or ELB in front?

I dont think so.

Yes you can, however you need IAM credentials which permit invoking the AWS Lambda Function and you need to sign the request using SigV4 with these credentials.

There is a somewhat incomplete answer on Stack Overflow for a similar question: https://stackoverflow.com/a/57809234

Not right now but I did read that AWS were planning to allow use of lambdas like this without a ELB fronting them in the future.

They accidentally released (then later pulled back) some documentation about "Lambda Function URLs" back in November, so I imagine they are close: https://web.archive.org/web/20211119230509/https://docs.aws....

This change doesn't really do anything to remove the need for an API gateway or ELB.

However, with some Javascript it has always been possible to call a lambda directly from a web browser, it's just a bit complicated, and you can't use it to act like a general http webserver, the way you can with a lambda "proxy" integration.

https://www.mbejda.com/invoking-aws-lambdas-on-the-browser-c...

I was always doing that using the python boto3 api. Just recently switched to API Gateway for some public endpoints and rest apis.

For the uninitiated, what is the advantage?

Increased margins for AWS as the shortage of public IPv4 makes the price per IP more and more expensive. You may also save a few $ per year.

I doubt it. They still default to giving an EC2 machine a public IPv4; if their primary motivation would be saving IP costs, they could easily go for the low-hanging fruit.

EC2 is their oldest service; I bet it has oodles of legacy workflows both on Amazon's side and on customers' side. Lambda is likely a much lower hanging fruit in terms of the effort required to make changes to it.

To be pedantic, SNS is their oldest service, if I remember my AWS training correctly.

You are thinking of SQS, the preview version of which was the first to be introduced. S3 was the first non-preview service made generally available.

Correct - you know your AWS launch history!

The number of deployed lambdas likely exceeds the number of ec2 instances by many multiples (pure conjecture). It's a perfect use-case for v6 - dual stack in front and then v6 internally.

EC2 is not really low hanging fruit. Most expect to get a ipv4 when creating an instance and many relies on that. Cheaper instances with ipv6 only is probably coming

That's very likely. Hetzner already offers cheaper ipv6-only dedicated servers: https://news.ycombinator.com/item?id=29471986

AWS introduced IPv6 only VPCs last year[1] and it made many AWS APIs endpoints unreachable from IPv6 instances as they are IPv4 only. So they are adding IPv6 support to them[2]. You can expect more of these type of blog posts this year.

[1] https://news.ycombinator.com/item?id=29327190

[2] https://news.ycombinator.com/item?id=29767004

Compliance with federal policies: https://aws.amazon.com/blogs/publicsector/aws-enables-us-fed...

Interesting trickle down effect from governments having a lot of purchasing power.

This is all about being able to invoke AWS Lambda from an IPv6-only network. Their copy states as much: "(...) removes the need for expensive networking equipment to handle address translation between IPv4 and IPv6."

Use cases will be IPv6-only networks with no NAT64 capabilities, either due to compliance reasons or because you're running, eg, IoT devices that need to call home over a provided 3G/4G connectivity and you were only able to get competitive prices if you stayed away from the cellular provider's IPv4 stack.

I think this always worked if you used CloudFront in front of lambda which is probably good practice anyway?

No, you're talking about API Gateway triggering lambda. My understanding is that is is about the invoke endpoint being listening on IPv6, so you can invoke your functions from your cli or SDK using IPv6.

Technically CloudFront requests to the origin server are IPv4 only, so there's still IPv4 in the stack even if the distribution has IPv6 enabled.

Personally this is one area I'd like AWS to focus on, along with load balancers listening on IPv6 only (currently it's dual stack). Every load balancer we deploy takes up at least 3 IP addresses - I'd quite happily switch them to being IPv6 only if CloudFront could access them over IPv6.

I would not say putting a CloudFront in front of Lambda is a good practice anyway. It highly depends on your use cases (load, frequency of data changes, etc). In general, I probably lean the other way and use a CloudFront only when necessary as it only introduces additional architectural complexity which makes it more difficult to troubleshoot issues. You can also get in a bad place if there are two many CloudFronts in the call stack.

Welcome to 1995, Amazon.

Reply on news.ycombinator.com