Programmatically defining public Urls for lambda endpoints...

[karlkras]

Trying to figure out how to define public endpoints to my deployed lambda module in aws via (I'm assuming) serverless.
I see a small mention of this in the documentation but remains unclear to me where to obtain a clear description on how to go about this.
I understand it involves some configuration through the api gateway, and my attempts to manually configure through the aws console have not succeeded. I'm hoping to be able to do this via our github action deployment process? Any help would be greatly appreciated.

[t-richard]

If you want to use API Gateway, please refer to this documentation
https://www.serverless.com/framework/docs/providers/aws/events/http-api

If you want to use Lambda Urls, you can take a look at this article https://www.serverless.com/blog/aws-lambda-function-urls-with-serverless-framework

In any case, this will deployed as part of the serverless deploy command so it can be automated via github actions.

If you have more detailed questions, feel free to ask 🙂

[mnapoli]

I'd suggest following this guide: https://bref.sh/docs/first-steps.html

[mikevang]

Hello, Karl's coworker here. Let me add a little more information. We have an API built on the laravel framework that we're currently deploying to AWS just fine, but what we're looking for is to use a custom domain name, and have it setup automatically via the deploy process instead of having to manually set it up within the AWS console.

We currently get a url from the deploy along the lines of https://{uniqueid}.amazonaws.com/ but we want to use https://api.{ourdomain}.com. We've tried setting this up manually in the AWS console using the information here: Custom domain names - Bref but depending on how we set it up we get various errors and nothing has worked so far.

Additionally, we'd like to have this configured during the deploy process via the serverless.yml (or where ever it needs to be setup) so that we don't have to do this manually. However, we've found zero information on how that can be achieved, if it's even possible.

Thanks for any help you can provide.
Mike

[mnapoli]

Ah ok, you might want to look at https://github.com/amplify-education/serverless-domain-manager which can automate it for you.

[mikevang]

@mnapoli that seems like exactly what we need, thanks! One question though, is the serverless create_domain something you only run once, or should it be part of our CI/CD process?

[mnapoli]

@mikevang I don't know

[karlkras]

So I'm surprised that this process isn't a commonly known/practiced workflow when working with bref lambda deployments.
Is it not common to want to map API endpoints to a user friendly url?

[deleugpn]

I'll answer as a top-level answer instead of a comment due to the size of my comment.

For me it's very common to deploy a custom domain with AWS Lambda, but for some backend-only projects, it's not uncommon to use the domain provided by AWS.
There are a few things at play here.

1. It's a simple request but AWS over-complicate it
2. Domains are account-level bound and global resources (not region specific)
3. CI/CD can either be interpreted as project-specific or global

Let's start with 1: I just want a custom domain in front of my service. Although it sounds simple, AWS forces us to:
1- Provision a new DNS on Route 53
2- Provision a new Certificate on Certificate Manager
3- Validate the Certificate (via Email or DNS validation)
4- Associate the DNS with your Incoming Request service (API Gateway V1, API Gateway V2, Load Balancer - each of them is configured differently)

The fact that nowadays http:// is unacceptable and custom domains require a custom certificate, the process isn't as straight forward as one would hope. To make matters worse, AWS used to provide only manual validation of certificates (via Email) or manual validation by requiring a human to provision the correct DNS validation. Only more recently tools to automatically validate the DNS were made available so it's not uncommon to find lots of information on the internet requiring manual steps.

As for 2) Imagine you have more than 1 project on your company and/or domain. Maybe you have a frontend team app.mycompany.com and a backend team at api.mycompany.com. Maybe you even have a data engineering team with insights.mycompany.com. Notice how they all share the same domain, only different subdomain? Domain is often considered an account-bound resource and not just project specific. Do you want your frontend team app.mycompany.com to be "the owner" of the domain? What if they are restructuring their project and suddenly they bring your entire domain down?
For that reason, whenever I'm providing consulting services or implementation services, I usually provision Route 53 and Wildcard Certificate separate from the project-specific being deployed, which brings step 3

Your CI/CD for a specific project/github repository may not be the best place to put DNS provisioning information. Domains are created only once and never again. You do not want to reprovision DNS on every deployment. Your CI/CD should rely on deploying based on existing account-level infrastructure, but how will that look like heavily depends on your infrastructure. Terraform, CloudFormation and Serverless all provide different forms to do this.

Hope this clarifies some things and shed some light on why it appears to be simple on the surface but it's quite complicated.

Btw, I have heard from many people that they solve this problem by simply singing up for a free CloudFlare account and forgetting about it.

[karlkras]

Thank you for a very insightful explanation. Many of the hurdles you outline are precisely what we're discovering.