Possible to Use SAM with multiple API Gateways in different template.yml with custom domains?

[EchoWhiskeyZero]

I'm new to AWS SAM and really struggling with this. I'm trying to achieve the following.

API Gateway hosting a custom domain (api.hostname.com)
Multiple microservice projects (app1, app2, app3).
Each microservice with their own lambdas (doSomething, doSomethingElse).

So it would look like this:

Microservice Project 1 (separate template.yml)
api.hostname.com/app1/doSomething
api.hostname.com/app1/doSomethingElse

Microservice Project 2 (separate template.yml)
api.hostname.com/app2/doSomething
api.hostname.com/app2/doSomethingElse

The challenge that I run into is that in the first project, I create the custom domain in the first project and everything works correctly but the second project fails because the custom API domain has already been created by the first project.

ApiGatewayApi:
Type: AWS::Serverless::Api
Properties:
StageName: Prod
Domain:
DomainName: api.hostname.com
CertificateArn:
Route53:
HostedZoneId:

Is there anyone with a similar setup that might be able to help (or be able to share your template.yml)?

[EchoWhiskeyZero]

I think what I'm trying to do is to create my custom domain name on API Gateway outside of SAM (using CloudFormation), and then within my SAM app associate it to the pre-existing custom domain name (already defined in API Gateway) when I create an API Gateway instance using SAM. So instead of SAM creating the custom domain name, i'm trying to use SAM to associate it to the custom domain that was already defined.

From the docs, I see a lot about creating custom domains using SAM but not sure how to associate it to a custom domain that already exists: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-domainname.html#aws-resource-apigateway-domainname--examples

Any ideas how to do that?

[hoffa]

I don't have any solutions at the moment, but do #349 and #2175 seem relevant to what you're describing?

[EchoWhiskeyZero]

Great, thanks @hoffa. This is very similar to what I'm trying to do.

[troycampano]

I was able to achieve this; the key is the AWS::ApiGateway::BasePathMapping definition. You can either define your custom dns name (let's say api.hostname.com) manually using the Console or CloudFormation or it's better to define the DNS in your "root" SAM Lambda project because you can automatically associate your Route 53 DNS A record to API Gateway.

But let's assume you already have api.hostname.com added as a custom domain in API Gateway. Set up two SAM projects, one for each of your microservices. Define an API Gateway in each:

Resources:
  ApiGatewayApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: Prod

If you want your microservice to also create the DNS record and associate it to your API Gateway, you can do this instead (but note, only do this in your top-level / root microservice...what would service the / path):

Resources:
  ApiGatewayApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: Prod
      Domain:
        DomainName: api.hostname.com
        CertificateArn: <YOUR CERTIFICATE ARN>
        Route53:
          HostedZoneId: <YOUR HOSTED ZONE ID>

Then create your lambda function and associate the Lambda's event to your API Gateway (using RestApiId):

  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello-world/
      Handler: app.lambdaHandler
      Runtime: nodejs18.x
      Architectures:
        - x86_64
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /
            Method: get
            RestApiId:
              Ref: ApiGatewayApi

Now here's the really important part. Create a new API Mapping associating the API Gateway to a path using the custom domain. This enables different paths to be routed to different API Gateways.

  Microservice01Mapping:
    Type: 'AWS::ApiGateway::BasePathMapping'
    Properties:
      BasePath: 'path1'
      DomainName: api.hostname.com
      RestApiId: !Ref ApiGatewayApi
      Stage: Prod

This will result in an API that can be called at: https://api.hostname.com/path1. If you'd like this to be the root of the API, just change BasePath from path1 to ''.

You essentially want to take this same approach for your second microservice. The only real change you need to make is to change the BasePath in your mapping to be unique.

In the end you can have two microservice projects, each with multiple lambdas, all using a single custom DNS name which looks like this:

https://api.hostname.com/path1
https://api.hostname.com/path2
https://api.hostname.com/path3
https://api.hostname.com/path4

Where path1 and path2 can be separate Lambdas in the same microservice and path3 and path4 can be two other lambdas in your second microservice project. This enables you have to have modularity and decide how many lambdas make up each service or microservice. The only downside here (depends on your opinion) is you're creating multiple API Gateways per microservice/project, which is the "Multiple API Gateways" approach mentioned here: https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-integrating-microservices/api-gateway-pattern.html

Hope this helps.

[EchoWhiskeyZero]

Yes, this is exactly what I'm trying to do. Thank you @troycampano!

[stevenulibarri]

Thanks a lot for this. In my project we had our lambdas in nested stacks, grouped by what feature they belonged to and were outputting all their ARNs up many layers of stacks to be passed into a top level monolithic template with a AWS::Serverless::Api, which was very crufty and difficult to maintain. The service is rather large and we were not going to be able to just replace the existing pattern in one go so I was trying to get nested AWS::Serverless::Api's working alongside the monolithic one. Working from your example I was able to get things working by using AWS::Serverless::HttpApi's in the nested stacks and using AWS::ApiGatewayV2::ApiMapping instead of AWS::ApiGateway::BasePathMapping. It work because the the GatewayV2 Mapping supports multi part basePaths so things look like this now:

• top level monolithic api basePath: /serviceBasePath
• nested feature 1 set http api mapping: /serviceBasePath/featureSet1
• nested feature 2 set http api mapping: /serviceBasePath/featureSet2
• and so on

Eventually we will have migrated everything to the nested HttpApi's and the monolithic one can be torn down completely.

[mcblair]

With this pattern, is it possible to avoid having multiple API Keys? How might you consider auth relative to this pattern?

[stevenulibarri]

In my case we define a single lambda authorizer and pass its arn to each defined ApiGateway so the auth logic is the same no matter which gateway a particular route belongs to. The authorizer lambda calls into our external auth provider to verify user tokens and such. I am not familiar with the options for setting up API key auth for ApiGateways so I can't help so much there.