AWS API Gateway Multi-Stage Deployment with Lambda Alias

Click on the image to zoom

The Cloud Computing World is moving to Serverless architecture for obvious reasons. There is no need to keep your servers running and paying for 24X7 where you application may be serving your customers 50% of a day. You should pay only for the time your application actually processing your customer’s requests.

When we talk about Serveless Architecture on AWS, the very first thing would come to your mind is Apigateway with Lambda ! You can build your REST APIs without running EC2 instances. That’s very cool. But when I first adopted this stack, I was wondering how I can handle my CI/CD. For example, during development phase I like to update my lambda functions several times without effecting my PROD REST APIs which are being used by my customers. I deployed two Apigateway stages?—?dev and prod but problem was they both point to same lambda function. As a result, when I was updating my lambda function during development, it was effecting prod APIs as well.

Click on the image to zoom

Coming from Elastic Beanstalk where I can create multiple environments for an application and controlling code promotion from DEV to PROD so that PROD APIs are updated only when I decide to promote code from DEV to PROD, I was looking for similar mechanism using Apigateway and Lambda where I can control when to publish lambda code to PROD.

After some research I found we can achieve same behavior using Lambda alias with versioning and Apigateway stage variables.

When you use versioning in AWS Lambda, you can publish one or more versions of your Lambda function. As a result, you can work with different variations of your Lambda function in your development workflow. Each version is immutable with unique ARN. In addition, you can create aliases for your lambda function pointing to different immutable version. You can think alias as logical name of you environment specific lambda function which underneath points to different versions. For more information on this topic read this.

Now instead of directly assigning a lambda function in Apigateway integration request, you can assign lambda alias where alias is a variable. The variable will be resolved from a value from stage variable. For example you configure lambda function in Apigateway as myLamnda:${stageVariables.lambdaAlias} and define lambdaAlias stage variable in each of your Apigateway stages.

Click on the image to zoom
Click on the image to zoom
Click on the image to zoom

With above configurations, when you hit APIs from prod stage ( say /prod/todos), Apigateway will send the request to myLambda:PROD alias for fulfillment. myLambda:PROD points to immutable version. In your development environment (say /dev/todos) Apigateway (stage=dev) will point to myLambda:DEV alias which points to $LATEST version of your lambda function. As a result when you update code for your lambda function, it will update $LATEST version and immediately you can test your API in dev stage of Apigateway (/dev/todos). But it will not impact your prod API as it points to myLambda;PROD alias which behind the scene points to a immutable version.

Click on the image to zoom

Now when time comes to promote your lambda code to production, you create a version of you lambda code (from $LATEST) and update PROD alias to point to new version. That’s it !

One important note?—?when you are using lambda aliases, you need to grant permission to Apigateway for each aliases.

Click on the image to zoom

If you are interested in giving it a try by yourself, I wrote some terraform scripts to help you get started. All the AWS resources you need for this exercise such as lambda function, IAM role, aliases, api gatway resources, states will be created for you just by executing terraform commands from your terminal. Visit my github repo here for detail instructions.

https://medium.com/@just4give/aws-api-gateway-multi-stage-deployment-with-lambda-alias-8d51c7d2d892

 

Build your next app on aws server-less architecture

Don’t spin up servers anymore to deploy your applications. Servers are costly and involves regular maintenance and security patching to keep your servers safe from hackers which means additional pay checks for IT support. This adds up operational cost and burden on startups where fund is limited most of the cases.

Moreover during initial phase of a startup product  ( or a new product from a popular giant) you don’t know how much traffic your product is going to attract. Your product may get occasional traffic through out the day but as you have provisioned your servers, you are paying for 24 hours, 7 days.

Click on the image to zoom

Server-less architecture gives you the flexibility to pay only for the resources used by your application without running a fleet of EC2 containers, Elastic Load Balancers when most of the time they sit idle.

Use Amazon API Gateway which is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. Amazon API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management. Amazon API Gateway has no minimum fees or startup costs. You pay only for the API calls you receive and the amount of data transferred out.

Use AWS Lambda for your backend which lets you run code without provisioning or managing servers. You pay only for the compute time you consume – there is no charge when your code is not running. Lambda supports variety of popular programming languages such as NodeJS, Java, Python, C# and Go.

Use AWS DynamoDB for your storage which is a fully managed NoSQL database for all applications that need consistent, single-digit millisecond latency at any scale. It is a fully managed cloud database and supports both document and key-value store models.

Use AWS S3 to host your static web assets which is highly available and durable object storage. Your assets are automatically replicated to multiple availability zones within same region for high availability. Use AWS CloudFront to serve your static web content from S3 bucket. Amazon CloudFront is a global content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to your viewers with low latency and high transfer speeds. CloudFront offers a simple, pay-as-you-go pricing model with no upfront fees. CloudFront can server up to 10,000 request per seconds.

OfficeBot ( https://officebot.info ) was built entirely on server-less architecture as described in above diagram.