Placing all your resources into a single stack is going to create pain for you later on. Moving and renaming resources between stacks can be quite tricky. Once a resource is managed by a CloudFormation stack it’s not possible to remove that resource without deleting it, and it’s not possible to move a resource from one stack to another. Splitting up your resources across multiple stacks can really help. Here are some suggestions on how you can achieve that.
Continue reading “Split CloudFormation Stacks”Safe Deployments with API Gateway and Lambda AutoPublishAlias
Take advantage of the automatic versioning and aliasing of your Lambdas to instantly shift traffic to your new API deployments. Rollback by repointing the problematic Lambda’s alias to the previous version.
TL;DR
- Use the Serverless Application Model (SAM) AutoPublishAlias parameter to have CloudFormation automatically version and alias your Lambdas upon deployment
- Reference your Lambda Alias from your OpenAPI definition
- Deploy
How to use OpenAPI with API Gateway
Use an OpenAPI specification to define API Gateway APIs. This is good practice because:
- The specification forces you to think about the design upfront before touching code which is expensive to correct later
- This contract first approach allows frontend, backend, and test developers to work in parallel
- Endpoints can be mocked for developers to test against
- Serverless Application Model (SAM) uses the specification to configure the API Gateway API, this makes it living documentation, evolving alongside code and infrastructure.
How to Whitelist IPs with API Gateway
Use an API Gateway Resource Policy to allow access to your APIs only from certain IPs. This is a handy approach for locking down your non-production APIs so that they are not publicly accessible.
Continue reading “How to Whitelist IPs with API Gateway”