AWS::Serverless::Api auto deploys API when a resource is being added

[ariasvzla]

Description

The AWS::Serverless::Api deploys the API when a resource to the stage is being added, this is causing a path change in the S3 versioned static site, causing outages.

Steps to reproduce

add new resource to api stage, bump the S3 version, deploy.

Observed result

The path to a new version is being made and deployed before we upload files to the S3 key

Expected result

The addition of a resource should not trigger API deployments

[paulhcsun]

Hi @ariasvzla, SAM's responsibility is to transform AWS::Serverless::Api to Cloudformation so I don't believe this is a SAM issue. It seems like you're either uploading to S3 after the Clouformation deployment is finished or your Cloudformation stack is not deploying in a specific order that you need for your use case. To help me better understand, could you describe how you're deploying the stack when you upload to S3 and provide a minimal example to explain what's going on here?

[ariasvzla]

Hi Paul,

We have a FrontEnd API that is being created via CFN using AWS::Serverless::Api macro, this has integration with S3, so the endpoints points to a versioned folder.

Order of deployment is:
1- We determined a Version for the UI ( it is bumped when a change is detected in one of the UI compoents)
2- Create/Update API stack, we pass the UI version and bucket name as parameters to build the uri.
3- Build the FrontEnd package
4- Upload to the S3 versioned folder
5- Deploy Front End API

The ideal scenario for us is to deploy the API after files are uploaded, but the deployment is happening on step 2 (see order of deployment), when we add/remove a resource to the API, this causes the API uri points to a empty versioned folder, creating an outage until step 4 is completed.

The expectation is that, when we add or remove a resource from the API the deployment only will occur on step 5.

According to this https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-generated-resources-api.html the resource AWS::ApiGateway::Deployment is being created on creation, but looks like it changes on update also, triggering a deployment without our consent.

[jfuss]

According to this https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-generated-resources-api.html the resource AWS::ApiGateway::Deployment is being created on creation, but looks like it changes on update also, triggering a deployment without our consent.

This doc is miss leading. The AWS::ApiGateway::Deployment is generated within SAM. So since you are doing a stack update, the expectation is new changes to you API Gateway are deployed. Since you are updating your stack and SAM is detecting changes, that is "consent" to deploy the API Gateway. This is not something we can change and in most cases is what customers want. So if you are updating the API, you should expect SAM will deploy it on stack update.

You will need to change your deployment order to achieve what you want. Specifically, you want step 4 to happen before Step 2. From what you described, there shouldn't be any reason that can't happen. You can probably do something else but would require you to manage the Deployment Resource, which requires you to move off of SAM's resources. I wouldn't recommend this because there are some sharp edges you will run into trying to manage API Gateway Deployments in CloudFormation (which is what SAM is solving for you here).

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.