Possibility to get AWS::Serverless::RestApi passed a template variable to Template files with Functions only

[ashwgupt]

We have got a problem where the resource limit of CF is hit when transformed from our SAM Template file.

Given all our Lambdas are behind APIs and we want to maintain all APIs from Single API Gateway, and that we now have to split the SAM Template into multiples to make them independently deploy-able, is there a way that we define one template that has only AWS::Serverless::Api to build out API Gateway with given Swagger file, and then to pass its reference to other template files that will be deploying our AWS::Serverless::Functions.

We simply want to pass the reference of RestApiId to the template files as a CFN Parameter.

Is this possible at this moment? As the error on the attempt says otherwise - RestApiId must be a valid reference to an 'AWS::Serverless::Api' resource in same template, which is quite dis-heartening :-(

[honglu]

You can use CloudFormation export and import to pass the parameters from one stack to a different stack: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-exports.html

To deal with resource limit issue, CloudFormation recommends to use nested stacks: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-nested-stacks.html

The caveat here is that nested stack does not support SAM. One way to get around that is to only define the non serverless resources in nested stacks and still leave the serverless resources in the top level SAM template.
Edit: Nested stacks are now supported, starting November 2018

[piersf]

We shouldn't force people to use nested stacks. They have their own caveats.

The idea proposed in the description of the discussion here is much much better where an AWS::Serverless::Api resource is defined in one template/stack and its ID is exported, and then used by AWS::Serverless::Function resource that could be defined in other templates/stacks.

This is much more flexible and avoids the coupling of things in one master template. It also allows for independent deployment of the stacks.

[ashwgupt]

@honglu thanks for your reply.

We have been doing what you suggested above and now only serverless resources are left in the SAM when we hit the CF limit after transformation.

There were 3 options we came up with and tried but all failed:

1. Define API gateway as a separate SAM file, take export of created Gateway. Split Lambdas into multiple Lambda-only SAM files, with all of these taking already created API Gateway as input for their event.properties.RestApiId => That fails due to the limitation that SAM has i.e. the RestApiId must be a valid reference of serverless:api type resource in the same template file.
2. Define API gateway as a separate SAM file and create Role/Policies such that it is allowed to invoke required functions. Split Lambdas into multiple Lambda-only SAM files but without any Api type Event defined under it. That way we can create our Lambdas and API Gateway independent of each other and integrate using Swagger and arrange for permissions separately => That fails at SAM Local level, upon which we depend a lot for local run and testing, as that now doesn't know against what event a lambda should listen.
3. Define API gateway as a separate SAM file and create Role/Policies such that it is allowed to invoke required functions. Split Lambdas into multiple Lambda-only SAM files but without RestApiId property for event => That gets even worse as now every lambda creates a new Api Gateway for itself assuming that is what it's asked for.
   So at the end we are still blocked in that catch-22 situation due to variety of limits and limitations of SAM and CF.

So at the end we are still blocked in that catch-22 situation due to variety of limits and limitations of SAM and CF.

Is there any other way or ideas that can help us overcome it?

PS: However I also came across another issue - #335 that indicates the option-1 was working until a few days back, which is really interesting and worth watching progressing on that issue.

[lestephane]

Hi Folks, #149 seems to imply one cannot split the api resource from the function resources. This issue seems to imply it is indeed possible, without giving template examples. I would be forever grateful if someone who's managed to do this would post an actual example that works. Many thanks in advance.

[saratitan]

We managed to split them before, but no longer. It suddenly stopped working so we had to redo all of our stack structure which meant a downtime in production. See #335

[mjbuonaccorsi]

Does anyone know if this issue is dead? Or does anyone know if there is a way to use the aws lambda update-function-code CLI method to update the code and roll it out with checkpoints?

[dehli]

It would also be great if RestApiId could be of type AWS::ApiGateway::RestApi instead of just AWS::Serverless::Api. We're currently using CloudFormation and would like to dry up some code by slowly switching to SAM but this prevents us from doing that.

[keetonian]

Nested stacks are now supported in SAM, meaning you can nest resources in other stacks and use the outputs as values in the current stack.

[dehli]

Even though they are supported, when I created the AWS::Serverless::Api in a separate stack from an AWS::Serverless::Function I still got the above error (this was two days ago).

[keetonian]

Can you post an example that creates this issue? Is it as simple as defining an API in one stack and referencing a Function in that API that is from a nested stack?

[dehli]

Sure! These are two stacks that cause an error.

template.yml

---
AWSTemplateFormatVersion: 2010-09-09
Transform: 'AWS::Serverless-2016-10-31'
Resources:
  RestApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: LATEST

  Function:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs8.10
      InlineCode: >-
        exports.handler = async function(event) {
          return { hello: 'world' };
        }
      Events:
        Request:
          Type: Api
          Properties:
            Path: /hello
            Method: GET
            RestApiId: !Ref RestApi

  Substack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: "./substack.yml"
      Parameters:
        RestApi: !Ref RestApi

substack.yml

---
AWSTemplateFormatVersion: 2010-09-09
Transform: 'AWS::Serverless-2016-10-31'
Parameters:
  RestApi:
    Type: String

Resources:
 Function:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs8.10
      InlineCode: >-
        exports.handler = async function(event) {
          return { hello: 'world' };
        }
      Events:
        Request:
          Type: Api
          Properties:
            Path: /world
            Method: GET
            RestApiId: !Ref RestApi

[jlhood]

Thanks for the example. SAM currently requires the API and lambda functions invoked by the API Gateway to be in the same template in order to use the implicit API generation functionality of SAM. This is because the swagger is generated in the template and references the serverless functions using !Ref.

Are you saying you are hitting the CFN 200 resource limit when your template only contains the API Gateway resources and lambda function (and IAM roles) directly invoked by API Gateway and all other resources are in nested stacks? This would imply that you have maybe ~70 resource+methods all being serviced by separate Lambda functions. Is that correct?

Some alternatives you could try:

1. Route multiple resource+methods to the same Lambda function. This requires your Lambda function to be able to route different requests to different handlers in your code. There are a few language-specific frameworks that make this fairly easy. Examples: aws-serverless-express for Node.js, aws-serverless-java-container for Java.
2. Use the Role property of AWS::Serverless::Function to reuse the same role across multiple Lambda functions that handle APIs. There's a security trade-off you may need to make here, but it will save resources.

Adding SAM support for the same intuitive API mapping within the Events section of an AWS::Serverless::Function without the API and function being defined in the same template is non-trivial since the AWS::ApiGateway::RestApi resource expects the full API definition, including function integrations to be defined. If anyone wants to submit an RFC issue proposing how it could be done in SAM, that'd be awesome, but I don't see us prioritizing this without more feedback from customers.

[allanchua101]

200 is a limit from 2019. Its now 2023 and we still have the same challenge.

[allanchua101]

Routing multiple endpoints into a single API feels really weird because if the function is configured with POST and GET and contains routes that does the retrieval inside a POST and retrieval inside a GET. It just breaks consumer experience of our APIs.

[cshenrik]

@jlhood: Let med add some more feedback. I am composing serverless applications using the AWS::Serverless::Application resource. In one SAM template I need to nest two applications that both use an API gateway. In this scenario it's not possible to make the two nested applications share the api gateway because:

RestApiId must be a valid reference to an 'AWS::Serverless::Api' resource in same template

Any ideas for workarounds?

[jlhood]

@cshenrik Really appreciate the additional context and feedback. Agreed, adding triggers based on resources in your current template to functions defined within a nested application is not made easy by SAM today.

Currently, you would have to manage your own API swagger document to add the nested app function as an integration.

What do you think about the possibility of being able to specify event sources on the AWS::Serverless::Application resource similar to how it's done on AWS::Serverless::Function today? Something like this?

  NestedApp:
    Type: AWS::Serverless::Application
    Properties:
      Location:
        ApplicationId: <app id>
        SemanticVersion: 1.0.0
      Events:
        GetRoot:
          Type: Api
          Properties:
            Path: /
            Method: GET
            OutputFunctionName: MyHandlerFunctionName
            OutputFunctionArn: MyHandlerFunctionArn

So here I have a nested SAR app called NestedApp that defines two outputs: MyHandlerFunctionName and MyHandlerFunctionArn, i.e., what would normally be referenced via !GetAtt NestedApp.Outputs.MyHandlerFunctionName and !GetAtt NestedApp.Outputs.MyHandlerFunctionArn. SAM would then automatically add the needed AWS::Lambda::Permission and update the implicit API swagger document to add an integration to call MyHandlerFunction defined inside NestedApp.

Need to flesh out the exact syntax and some more details but wanted to put it out there to get some feedback.

[brettstack]

I think adding a new property to Serverless::Api would solve this problem and more. Maybe we call this Paths for Swagger symmetry.

[juniorclarke]

Just hit the CFN 200 limit today (yes, @jlhood, I am reusing roles) and looking for a workaround led me to this issue.

I initially tried to pass the "AWS::Serverless::Api" as a parameter to "AWS::Serverless::Application" but then I got the dreaded "The REST API doesn't contain any methods" error as it seems CFN is trying to deploy the API before it builds the other nested stacks.

Any workarounds?

EDIT: Looking at my last created CFN stack the problem seems to be the Lambda Permissions is being created 2 times for each lambda function as pointed out in #285. I would love to move to a nested stack solution but #349 prevents me from this.

I really don't want to create a different API endpoint for different resources but that's all I that comes to mind right now.

[normand1]

Also looking for a solution here

[omardoma]

Any updates on this?

[allanchua101]

Seriously guys, we really need to pass down RestAPI to child stacks :D

[siddharthmudgal]

The number of people and orgs looking for this feature. Is it really that hard to AWS SAM peeps?

[awood45]

So to explain, yes, this has technical limitations getting in the way. Right now, when you create an Api event source, it does two things:

1. Creates an AWS::Lambda::Permission resource policy.
2. Modifies the OpenAPI definition to associate a route/verb with a Lambda function, and adding any authorizer/etc properties to that route.

Doing step 2 is the tricky part, because it has to happen right now where the API is defined. You could use AWS::Serverless::Connector to do 1 if you have a fully defined OpenAPI spec. Though it likely would be easier for the Lambda handlers to be inputs into the template with the API definition in that case.

One possible option we could explore if there was high demand for this would be to add some sort of route helpers to the AWS::Serverless::Api resource, which would point to Lambda functions. In that case they could be in separate templates. But with how event sources are defined, it's not likely possible in a backwards compatible or maintainable way.

[troycampano]

This doesn't answer the original question exactly (using a single API Gateway), but if you're OK using an API Gateway per project (let's say each project is a microservice made up of multiple lambdas in each project/microservice), then this is how I did it. Posting in case it's useful to anyone. This enables some modularity so you can break your services down across multiple projects. The downside is that you create an API Gateway per project (which may OK for you if you're want to use the "Multiple API Gateway" pattern referenced here: https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-integrating-microservices/api-gateway-pattern.html#multiple-api-gateways).

Details posted here:
#2703 (comment)

[hoffa]

Adding a reproducible example for posterity.

Save the following as template.yaml:

Transform: AWS::Serverless-2016-10-31
Resources:
  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.8
      Handler: foo
      InlineCode: bar
      Events:
        ApiEvent:
          Type: Api
          Properties:
            Method: get
            Path: /
            RestApiId: !Ref MyApi

Deploy:

sam deploy --region us-west-2 --resolve-s3 --capabilities CAPABILITY_IAM --stack-name test-349 --template template.yaml

It transforms into the following template:

Transformed CloudFormation template

{
  "Resources": {
    "MyFunction": {
      "Type": "AWS::Lambda::Function",
      "Metadata": {
        "SamResourceId": "MyFunction"
      },
      "Properties": {
        "Code": {
          "ZipFile": "bar"
        },
        "Handler": "foo",
        "Role": {
          "Fn::GetAtt": [
            "MyFunctionRole",
            "Arn"
          ]
        },
        "Runtime": "python3.8",
        "Tags": [
          {
            "Key": "lambda:createdBy",
            "Value": "SAM"
          }
        ]
      }
    },
    "MyFunctionApiEventPermissionprod": {
      "Type": "AWS::Lambda::Permission",
      "Properties": {
        "Action": "lambda:InvokeFunction",
        "FunctionName": {
          "Ref": "MyFunction"
        },
        "Principal": "apigateway.amazonaws.com",
        "SourceArn": {
          "Fn::Sub": [
            "arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${__ApiId__}/${__Stage__}/GET/",
            {
              "__ApiId__": {
                "Ref": "MyApi"
              },
              "__Stage__": "*"
            }
          ]
        }
      }
    },
    "MyApiprodStage": {
      "Type": "AWS::ApiGateway::Stage",
      "Properties": {
        "DeploymentId": {
          "Ref": "MyApiDeployment1e98ccf811"
        },
        "RestApiId": {
          "Ref": "MyApi"
        },
        "StageName": "prod"
      }
    },
    "MyFunctionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
            {
              "Action": [
                "sts:AssumeRole"
              ],
              "Effect": "Allow",
              "Principal": {
                "Service": [
                  "lambda.amazonaws.com"
                ]
              }
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
        ],
        "Tags": [
          {
            "Key": "lambda:createdBy",
            "Value": "SAM"
          }
        ]
      }
    },
    "MyApiDeployment1e98ccf811": {
      "Type": "AWS::ApiGateway::Deployment",
      "Properties": {
        "Description": "RestApi deployment id: 1e98ccf811ae5bf67840ade2be6857ddf75298a9",
        "RestApiId": {
          "Ref": "MyApi"
        },
        "StageName": "Stage"
      }
    },
    "MyApi": {
      "Type": "AWS::ApiGateway::RestApi",
      "Metadata": {
        "SamResourceId": "MyApi"
      },
      "Properties": {
        "Body": {
          "info": {
            "version": "1.0",
            "title": {
              "Ref": "AWS::StackName"
            }
          },
          "paths": {
            "/": {
              "get": {
                "x-amazon-apigateway-integration": {
                  "httpMethod": "POST",
                  "type": "aws_proxy",
                  "uri": {
                    "Fn::Sub": "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${MyFunction.Arn}/invocations"
                  }
                },
                "responses": {}
              }
            }
          },
          "swagger": "2.0"
        }
      }
    }
  }
}

The transformed template shows that MyApi (the transformed AWS::Serverless::Api) includes the reference to the Lambda function:

          "paths": {
            "/": {
              "get": {
                "x-amazon-apigateway-integration": {
                  "httpMethod": "POST",
                  "type": "aws_proxy",
                  "uri": {
                    "Fn::Sub": "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${MyFunction.Arn}/invocations"
                  }
                },
                "responses": {}
              }
            }
          },

The API definition of the AWS::Serverless::Api is mutated here:

serverless-application-model/samtranslator/model/eventsources/push.py

Line 946 in a82a19f

api["DefinitionBody"] = editor.swagger

And here:

serverless-application-model/samtranslator/model/stepfunctions/events.py

Line 458 in a82a19f

api["DefinitionBody"] = editor.swagger

But since the API resource is not in the same template as where the event is defined, the SAM transform is unable to edit the API definition. Which is the current technical limitation described in the issue.

[wludwiniak]

Any plans to fix this? It will be 5 years soon

[SimonCMoore]

There are no simple workarounds or 'quick fixes' due to the circular update (lambda refs API, API refs Lambda) which can only be supported in the same template. It is clear there is interest in separating API and Lambdas across more than one template for a variety of reasons, which seems reasonable.
See possible solution previously proposed.#2735
Please +1 parent discussion to show your interest and to drive our prioritization process.

[retrovip]

+1

[hqblock]

+1

[2Ez4Sawako]

+1

[lArtiquel]

+1

[ghost]

+1

[allanchua101]

Challenge: Our API stack (Plain compute layer & no data stores) have surpassed the limit of max resource count of single cloud formation. To get around this, we have to break our large APIs into smaller groups and nest them down as child stack of the main CloudFormation stack which produces a side effect of having to create multiple API gateways and keys for all this child stacks. Another observation of mine is that, the more resources there is on a CloudFormation stack, the slower the deployment time gets.

Solution: We have to remove our API keys from API gateways because there is no way to have a single API gateway on a parent stack and pass its logical ID / reference to lambda functions residing on the nested stacks.

• We’ve hit more than 500 cloud formation resources on 2 of our largest cloud formation stacks
• In order to solve it, we had to create nested stacks for our APIs (eg. Auth, Companies, Officers, Invoicing, Payments, Marketing)

It worked great because:

• We've managed to overcome the 500 max resources of a CloudFormation stack.
• Deployment times became much faster from 7 mins down to under 2 minutes
• We can now scale way more than the built-in limit of CloudFormation for a single stack.

Why this solution sucks

• We have to create an api gateway per substack
• We had to give up the API keys because how can we tell partners that we now have more than 1 api key to work with our APIs
• Have multiple mapping to custom domains :D
• Can't we just configure cross cutting concerns (Caching, Keys, Security headers, rate limiting) on a single place? (Higher level gateway or Custom Domain)

What we're dreaming of

• Have a single API gateway on the parent stack and have the ability to link lambda functions on lower level (Nested stacks)
• We can settle to take a separate provisioning of API gateway and linking multiple independent API groups to it so we don't get so many API keys and redundant configuration.

Probable solution

• Create a construct for RestApiV3 that behaves and gets provisioned differently from the beta (Current) version of it.

[barkermn01]

So we have run into this problem and i just split everything up into nested stacks, and then ran into this issue.

From reading all of these I understand that the problem is SAM is building the OpenAPI Document for the APIGW, currently it does that from the lambda's registering against the API Gateway, so they need to be in the same stack.

Would it not be easier to have a property of the API Gateway that if present stops the complete auto generation and allow us to provide the routes instead?

Example below, but with this method if the Routes property is not supplied works as it currently does, if the Routes Property is suppled then the Routes & API Gateway are created after the Lambda and we have removed the need to have the Lambda's point to the RestAPIId removing the circular reference? (this would also match the mentality that AWS Console users would be familiar with create the function then create the API Gateway pointing to the function)

E.G
template.yaml

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: ""

Resources:
  FunctionsNested:
    Type: AWS::Serverless::Application
    Properties:
      Location: ./functions.yaml
      
  API:
    Type: AWS::Serverless::Api
    Properties:
      Description: The main API Service
      OpenApiVersion: "2.0"
      Domain:
        DomainName: "some.domain.name"
      Routes:
        - Type: AWS::Api::Route
          Method: "GET"
          Path: "/hello"
          Function: !GetAtt FunctionsNested.Outputs.GETHelloARN
        - Type: AWS::Api::Route
          Method: "GET"
          Path: "/helloworld"
          Function: !GetAtt FunctionsNested.Outputs.GETHelloWorldARN

functions.yaml

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: ""

Resources:
  GETHelloFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: nodejs16.x
      Description: "A function"
      Handler: app.lambdaHandler
      CodeUri: ./GET_hello/
  GETHelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: nodejs16.x
      Description: "A function"
      Handler: app.lambdaHandler
      CodeUri: ./GET_helloWorld/
      
Outputs:
  GETHelloARN:
    Value: !GetAtt GETHelloFunction.Arn
  GETHelloWorldARN:
    Value: !GetAtt GETHelloWorldFunction.Arn

[ivancsicsmarkus]

I just discovered this repository: https://github.com/aws-samples/sam-accelerate-nested-stacks-demo. They resolved this issue by only defining the Lambda functions, then sending them down to an API nested stack which uses Serverless::Api::DefinitionBody to reference function's in (here's the openapi yaml: https://github.com/aws-samples/sam-accelerate-nested-stacks-demo/blob/main/api/definition/openapi.yaml). You are responsible to handle IAM, but apart from that, it seems to be a good workaround. I don't see anyone recommending this. Why?

[barkermn01]

This does not work,

Spent a week rebuilding all our endpoint templates to use this for it to not work because doing this does not create the Trigger on the Lambda side so the Lambda is blocking API Gateways calls,

<AccessDeniedException>
  <Message>Unable to determine service/operation name to be authorized</Message>
</AccessDeniedException>

Because the Lambda does not have the trigger on it from the API Gateway just spent an hour on a call with an AWS support worker figuring this out. The support ticket is now being moved from the AWS API Gateway team to the CloudFormation team.

Response from AWS Support worker below.

In looking at some similar cases on my end, I was able to see that this error can occur when a Lambda function does not have configuration in place to allow your API to trigger it. We tested this by manually removing the Lambda proxy integration in the API Gateway console and re-adding it, which created the necessary invocation permissions on the Lambda end. After performing these changes we were able to successfully invoke your Lambda function via the API Gateway.

Will update when we get this figures out now talking to CloudFormation Team

Update 1 (3 hours in)
So when the resources are created by Cloud Formation, something is not being done correctly, when the API Gateway makes a call you send up with a Cloud Trail log of
Turns out the errors were not relevant

Update 2 (4 hours in)

Well, we found the issue. so comparing a none nested stack CloudFormation (NOT SAM) processes a template and created a processed template (you can view this in the CF dashboard on the stack).

So in a none nested stack CloudFormations processing goes Oh API Gateway and Lambda function API Gateway uses lambda create permissions

"_functionname_Permissionv1": {
      "Type": "AWS::Lambda::Permission",
      "Properties": {
        "Action": "lambda:InvokeFunction",
        "FunctionName": {
          "Ref": "GetBlockInfoFunction"
        },
        "Principal": "apigateway.amazonaws.com",
        "SourceArn": {
          "Fn::Sub": [
            "arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${__ApiId__}/${__Stage__}/GET/block",
            {
              "__ApiId__": {
                "Ref": "API"
              },
              "__Stage__": "*"
            }
          ]
        }
      }

This does not get created when the lambda is in a nested stack, the code linked to does actually have something to work arorund this the API Gateway gets a roles that is allowed to call the Lambda's however this no longer seems to work, the API gateway having a role with permissions to call but the Lambda's are still refusing the API Gateway

[laaksomavrick]

I've created a repository demonstrating the discussed work-around: https://github.com/laaksomavrick/aws-sam-apigw-lambda-decomposition-example/tree/refactoring-fix. Alongside this is an accompanying blog post.

[EchoWhiskeyZero]

Thanks @laaksomavrick, this worked great for me using a Rest API (AWS::Serverless::Api), however when I switch to using an Http API (AWS::Serverless::HttpApi) I get an error when I view my API Gateway in the AWS Console which says:

The latest automatic deployment attempt failed.

Deployment attempt failed: Unable to deploy API because no routes exist in this API

Your stage has no deployment attached. Update your API to trigger a new deployment.

And the API doesn't work for me, I get:

{"message":"Not Found"}

Any thoughts on how to fix this?

[laaksomavrick]

Not off the top of my head. I'd try to see what the OpenAPI spec looks like when you make this change - maybe there is a difference in the template between the two types and how it binds routes to integrations. You can export APIGW OpenAPI specs from the console. Let me know how it goes.

[piersf]

The idea proposed in the description of the discussion here is much much better where an AWS::Serverless::Api resource is defined in one template/stack and its ID is exported, and then used by AWS::Serverless::Function resource that could be defined in other templates/stacks.

This is much more flexible and avoids the coupling of things in one master template. It also allows for independent deployment of the stacks.

Is there a solution that allows us to go with this approach?

[laiminhtrung1997]

Any update here, guy? :(

[barkermn01]

yeah,

So in your primary template define the API Gateway add the following property to it,

DefinitionBody:
  "Fn::Transform":
    Name: "AWS::Include"
    Parameters:
      Location: openapi.yaml

Then create the openapi.yaml file the paths should be defined in this file below is an example for a CORS options header on all paths in a API Gateway.

paths:
  /{proxy+}:
    options:
      x-internal: true
      x-amazon-apigateway-integration:
        credentials:
          Fn::GetAtt:
            - ApiGwExecutionRole
            - Arn
        type: aws_proxy
        httpMethod: POST
        uri:
          Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${OtherEndpointsNested.Outputs.OPTIONSTrackerARN}/invocations
        passthroughBehavior: when_no_match

This means that all your nested stacks have to Output the ARN of the Lambda's you're wanting to connect to the API Gateway in this example ${OtherEndpointsNested.Outputs.OPTIONSTrackerARN} comes from a nested stack called OtherEndpointsNested, that has the lambda OptionsTrackerFunction then at the end of the files we have

Outputs:
  OPTIONSTrackerARN:
    Description: The ARN for the lambda for all Options request (stupid CORS)
    Value: !GetAtt OptionsTrackerFunction.Arn

Any other variables you need to pass between template you Output them to the primary template then pass them in to the next nested template E.G

  OtherEndpointsNested:
    Type: AWS::Serverless::Application
    Properties:
      Location: ./otherEndpoints.yaml
      Parameters:
        DatabaseEnvironmentParameter: !Ref DatabaseEnvironmentParameter

Hope this helps.