AWS Lambda function URLs: Built-in HTTPS endpoints

  • Very pleased by this addition! :-) Note that it creates special .on.aws URLs so if you want to use your own domain to future proof the endpoint (against linkrot if you ever leave AWS, say) you'll want to set up a redirect/proxy for yourself (whereas API Gateway does custom domains).

    Also an interesting note from the docs about how said URL is generated: "Because this process is deterministic, it may be possible for anyone to retrieve your account ID from the <url-id>." I don't know how much of a problem this could be, but it's worth being aware of.

  • It's super frustrating that AWS has no equivalent to GCP's Cloud Run which offers fast startup, scales to zero but offers the flexibility and simply exposing HTTP to the container it runs.

    Lambda has scale to zero and fast startup but its custom RPC interface (presumably an outgrowth of its batch processing origins) does not support streaming responses, has awkward response size limits, and prevents multiple requests from being executed concurrently on the same instance (so caches cannot be shared.)

    Fargate provides the flexibility from simply running an HTTP server inside a container but at the cost of slower startup and no ability to scale to zero.

  • My previous company had thousands of lambda functions and api gateway integrations and near impossible to do anything with confidence when you starting integrating with all the other cloud offerings. My current environment is similar scale, but all containers it's night and day difference when it comes to confidence. We can move 100x faster when you can reproduce environments locally or separate account in seconds or minutes with everything baked in. I don't think I could move back, but hey at least this might eliminate a few API Gateway integrations.

  • Amazing, now I don't have to pay API Gateway to do just an HTTP routing.

  • Can anyone using lambda at scale pitch in regarding costs? It seems companies are using it to build pipelines which could be much cheaper by writing full services as opposed to small functions that you pay for per invocation.

  • I'm confused, the whole news is that you can directly call lambdas without having to go through API gateway, like you do on cloudflare?

  • Today we are coincidentally releasing the beta for https://tinyfunction.com/ TinyFunction is the simplest NodeJS and Python function deployer. All functions are deployed in AWS.

  • Is it possible to front this with your own domain using a CNAME or are the function URLs dynamically genrerated on each commit/upload/build?

  • finally. Having to setup a gateway is so cumbersome.

  • Are those function urls backed by WAF and AWS Shield ?

    If not -> get prepared for huge bill of ddosed function invocations.

    I hope we can at least attach something to those urls.

  • Really Cool addition. I just moved my lambdas from API Gateway to ALB (because of API G limit to 30s). I also use Serverless framework. It was a day of work, but developing with ALB is a bit more of pain. Maybe this would be better. Are there any timeout or mb constraints on these URLs?

  • If you are using Python and looking for a framework to quickly get your Aws Lambda Functions up and running, try out the framework I am developing. It is still in the early stages, but it has some optimizations that make it simple to do things like use 3rd party packages. If you are interested, a good place to start are the docs on how to connect functions to Api Gateway https://staging.cdevframework.io/docs/examples/httpendpoints....

    If you want the developer experience of Django with the benefits of Serverless Compute platforms check it out!

  • I wish that Azure Functions had this.

    I have a function triggered by Cron once a day that goes wrong about once a month. I trigger it again using the debugging tools, but it would be nice if I could just hit a URL to trigger it again.

  • This is fantastic, I'm making an iOS application that is 100% serverless. Having no servers feels great but managing API Gateway endpoints is annoying. I don't know about performance but Google Cloud Functions definitely had an edge there, because I believe they had native function endpoints since launch.

    I wonder if it's worth changing my current API Gateway endpoints to the built in Lambda URL's, since I haven't launched yet.

  • Although it doesn't mention in the blog post, the HTTPS endpoints are dual-stacked.

    Seems like AWS is actually launching new endpoints with IPv6 support by default now.

  • So its a public https endpoint, with no built in throttling? This... doesn't seem like a ddos vulnerability to anyone? All it would take is one script kiddie to rack up an unsuspectingly large aws bill, no?

  • How is it that my UX looks completely different to the blog post?

    I don't have advanced settings. Instead I have to go "Configuration->Function URL" to find this.

  • Where are at least ACL and green header filtering?! This is 2022. If this is not supported at the entry point the product should be sent back to design.

  • Nice! Of course this has always been possible to do, but removing the API Gateway dependency will make simple use cases a lot simpler.

  • Now if only you could add an EIP to a lambda function without a VPC NAT and the $20/mo minimum that comes with it.

  • Very happy to hear it has first-class alias support. Now if only they would allow per-alias environment variables...

  • For someone who has only worked with Cloud Functions on GCP, can someone explain to me how is this different?

  • How is it different than cloudflare workers?

  • Is this similar to a cgi-bin script?

  • AWS Lambda has now gone full PHP. Never go full PHP.

  • undefined

  • undefined