AWS Lambda Multi-Region & Multi-Account Deployments: Use Cases, Management, & Pitfalls to Avoid

When you first start building a serverless application, you would usually do it in a single AWS account and deploy it to one region. More than likely, you will also not have thousands of users working at hundreds of different companies when you start. But there are good reasons for deploying infrastructure in general—and Lambda functions in particular—to multiple regions, and even to different accounts.

In this article, I explore the reasons for multi-region and multi-account deployment, as well as how to best manage these deployments.

Why Deploy Lambda Functions to Multiple Regions?

There are many reasons you should deploy a Lambda function to multiple regions.

1. Redundancy
   Redundancy is the primary reason for deploying to multiple regions. Lambda functions are serverless in the sense that you do not have to set up and maintain servers, but they still run on servers that are set up and maintained by AWS. If one AWS region goes down - and you only deployed your Lambda function to that region - that function will go down too. If you deploy it to multiple regions, the functions hosted in other regions can failover when one region goes down.

2. Unreachable Servers
   If you deploy to one region, but suddenly all servers hosting the Lambda service are no longer reachable, your Lambda function cannot be invoked. And AWS will not run it on Lambda servers hosted in other regions if you did not set it to do so. However, if you deploy to multiple regions and one goes down, you can still redirect your users to the regions that remain.

3. Reducing Latency
   You can also use multi-region deployments to reduce latency. There are many causes that increase a Lambda function's latency, but geographical location can be the biggest one. Got customers in Europe and China? Well then, deploy to Europe and China! Even at the speed of light, it will take some time for a request to make it halfway around the world. The latency of a European deployment is only 20 milliseconds for me here in Germany, but 300 milliseconds for deployment in China. That difference is over an order of magnitude in scale!

4. Compliance
   Finally, there are compliance reasons to consider. Sometimes you have to comply with laws that require you to store data in a specific geographical location. Private data, health-related data, or state secrets should not typically cross borders. If your service does not comply with a country’s data storage laws, you will be prohibited from offering it in that country.

Why Deploy Lambda Functions to Multiple Accounts?

Now, let’s look into why you would need multi-account Lambda deployments.

1. Separating the Data of Multiple Customers
   If you deploy your infrastructure in the cloud, you usually share AWS’ servers with other AWS customers. AWS put a lot of thought into the design of AWS accounts in order to keep them isolated from each other, and to not allow competitors to see each other’s data.
   This isolation, of course, can be used to your company’s advantage as well. If you have multiple customers, you can deploy each customer into an extra AWS account, and ensure that they cannot access each other’s data.

2. Securing Multiple Environments
   Also, if you have multiple environments such as development and production, you will not want a bug in one environment affecting the other one. If you have an account for each environment, this is highly unlikely to happen.

3. Budget Separation
   It also helps with budgeting. If you know who uses which account, you only have to look at the aggregated account bill to see who incurred what costs.

When to Avoid Multi-Region & Multi-Account Deployments

So when might you avoid multi-region and multi-account deployments? Multi-region deployments - and especially multi-account deployments - significantly increase the complexity of your architecture. Many AWS services do not support multi-account or multi-region deployments out of the box, making the integration with Lambda functions that much more difficult.

For multi-account deployments, you will need extra services like AWS Single Sign-On or AWS Organizations to manage the users of all these accounts.

If you’re only considering deploying to multiple regions due to latency issues, a tool like CloudFront can automatically cache your data at AWS’ edge locations around the world. You only need to deploy a single CloudFront distribution to an account in order to lower the latency for users in all regions.

Which Services Help with Multi-Region and Multi-Account Deployments?

• AWS CloudFormation: For infrastructure as code tools, this is the main service used in AWS. It comes with a structure called a stack set, which operates one level above a CloudFormation stack. With stack sets, you can use one CloudFormation template to deploy to multiple regions and accounts. This way, you can keep the configuration of the accounts and regions that should be used for deployment in a central place.

• AWS CodePipeline: This is AWS’ managed CI/CD service, which allows you to define different targets for your delivery pipelines. Given the required permissions, a pipeline can deploy a CloudFormation template to any AWS account. This way, you can build a pipeline that first deploys to a staging account, and later, when someone manually approves the pipeline, it goes on and deploys to production.

• AWS Organizations: If you wander into multi-account territory, this service (as well as AWS Control Tower, discussed below) is your friend. AWS Organizations helps you manage and configure multiple accounts in a centralized fashion. This enables you to pre-configure what a new account in the organization is allowed to do. For example, when laws require that you deploy in a specific region, you can create accounts that only have access to that region. In doing so, you ensure that you never accidentally violate the law. Organizations also helps with cost management, permissions, and security.

• AWS Single Sign-On: This service lets you easily manage inter-account access. After all, if every developer needs to deploy to a staging account, they also have to receive the permissions to do so. Manually playing around with IAM users at an inter-account level is cumbersome.

• AWS Control Tower: This service brings together Organizations and Single Sign-On, and makes it easier to work with the different services required for multi-account architecture.

Summary

Deploying your infrastructure to multiple regions or accounts increases complexity and - in turn - the risk of something going wrong as well. Keep your architecture as simple as possible to avoid mistakes, while noting that keeping it too simple can get you into trouble too. AWS losing the one region you deployed to can cost you a lot of money, so try to distribute the risk around geographical locations with multi-region deployments.

Sometimes multi-region and multi-account deployments are even required. If you need to lower latency - or are forced to comply with local laws - you usually will not be able to get around them.

In particular, B2B SaaS companies can end up with rather extreme isolation requirements when renting out services to different companies. A simple WHERE clause in SQL will not cut it anymore, and two databases running alongside each other in the same account might be too risky.

While not all AWS products work out-of-the-box with multiple regions in mind, AWS offers several services that address the pain points, so that you do not have to start from scratch.

Tech content for tech experts by tech experts. If you think you have what it takes and if you want to be part of the IOD talent network and write articles like this one, contact us.

The original article was posted on IOD Blog.