×
THANKS FOR SIGNING UP!
We’ll make sure to share the best materials crafted for you!
5 minutes read
Managing Lambdas Across Regions and Accounts
Written by Serkan Özal
Founder and CTO of Thundra
When working with AWS Lambda functions, the question of region is one of the first you need to answer. As each Lambda function lives in a specific AWS region, and each AWS region has a slightly different set of functionality, you may find yourself having to work with functions in multiple regions on a regular basis.
Managing functions across multiple AWS regions is troublesome enough, but when working with large applications you’re often required not only to manage functions across multiple regions, but also across multiple AWS accounts. In this article we’ll explore tactics for managing AWS Lambda-driven applications that are split across multiple AWS regions and accounts. We’ll review the problem space with an overview of how AWS is structured, discuss what’s available for native tooling, then look at alternatives that can ease the process.
Understanding How AWS Is Set Up
AWS, in order to provide maximum resiliency, is split into a number of global regions. These regions are then further divided into availability zones. These designations—region and availability zone—can determine a lot about the functionality available to you, as not every region will have all of the functionality you need. This means that your functions may need to speak cross-region, particularly if you’re working to optimize your application’s geographic proximity to the users with edge zones.
This is crucial because of the way in which AWS services tend to be billed. Communications from one AWS service to another within the same region are often done at a low cost, while communications that span multiple regions carry a premium. For example, transmission rates between AWS zones can be billed at up to $0.02 per GB. However, when an availability zone has an issue, it often affects all of the services within that zone. That means an entire application can be brought down, and your users are subject to the recovery time that AWS can meet.
Therefore, it’s critical to understand this setup to factor maintainability and sustainability into your serverless application’s architecture. While you can potentially reduce your costs by keeping all of your services within the same AWS region, this adds the risk that your application will be taken down by things outside of your control. Building a cross-region serverless application is the only way to provide resiliency against region outages.
Initial Strategy for Managing Widely Dispersed Lambda Functions
The first place we will look to ease cross-region management is the AWS Command-Line Interface, or CLI. The CLI allows you to quickly manage AWS services from a command line, creating and destroying services as needed with a few commands. These commands can then be added to scripts and shared among developers. The AWS CLI is a good first step in providing reproducible cross-region architecture, but it has a fatal flaw: it operates only on one single authenticated AWS account at a time. This can pose problems when you’re trying to consolidate information from similar functions that span multiple AWS accounts.
Next is AWS CloudFormation, which helps you organize each region’s deployment mechanism. This lets you define the critical infrastructure you need as code and improve maintainability and deployability by reducing your application’s configuration to a set of human-readable configuration files. With a few CloudFormation templates, you can automate your entire application infrastructure, but you’ll still need to maintain multiple configuration files to support your cross-region approach.
AWS SAM is a newer option for pulling your function configuration into a coherent whole. SAM provides a flexible template language you can use to build your AWS application resource specifications at a higher level than with CloudFormation. With AWS SAM, you can define all of the resources needed for your serverless functions, compile them into CloudFormation templates, and execute the deploy—all without touching a user interface component. With this flexibility, you can solve a lot of the problems of cross-region support just by sharing and linking configuration files.
The Shortcomings of the Native Approach
While the native tools approach provides us with some benefits when managing cross-region applications, executing a comprehensive plan to monitor and maintain an application that spans multiple regions still requires a lot of planning and knowledge. You’ll need, for example, to handle multiple deployment processes—one for each region. This can be an error-prone process unless you use tools to generate the configuration. If you do, however, you’ll either have one more application to maintain or you’ll be spending a lot of money on third-party solutions.
Additionally, it can be challenging to discriminate between Lambda functions when you’re troubleshooting from within AWS. If you have the same function available in multiple AWS regions, there is simply no good way to consolidate all of the logs into a cohesive whole, or to determine exactly which version of the function was the source of a given failure. Working with multiple AWS accounts complicates this even further.
Solving Native Pain Points with Third-Party Tools
All of this means that you’ll need to rely on third-party tools to improve your ability to manage your Lambda functions. The design of AWS and its dependent services means there are hard divides between each application. The first divide is at the region level—most AWS tools are designed to work with a single region at a time. While there are some first-party tools that address this issue (AWS SAM, for instance, consolidates deployment of serverless functions into a single template file), they do not offer much insight into your application as a whole.
Applications that span multiple AWS accounts compound this issue. There’s no easy dashboard in AWS that lets you review architectural elements that span multiple accounts. You can modify how the services on each account interact with each other, adding in explicit reporting of cross-account metrics and system health, but this requires deliberate and dedicated effort to implement.
Third-party tools bolster the native functionality provided, building an intermediary layer between the application and the functions that comprise it. This allows third-party tools to provide a view of your application that is simply not possible with the native tool chain. This is most applicable at the deployment and monitoring stages of your project. The holistic view of your application that third-party tools can provide is crucial in building a cross-region/cross-account application that is maintainable, deployable, and dependable.
Building for Maintenance and Observability
To nail down the multi-region/multi-account issue, we’ll take a look at two areas of concern— deployment and observability—and how third-party tools solve them. The first concern we’ll look at is deployment management. When your serverless application spans multiple regions and accounts, your deployment process quickly becomes a mess of random credentials, region names, and endpoints that can be confusing to application maintainers.
Stackery is a third-party tool dedicated to solving this issue by providing a serverless platform that lets you design, develop, and deliver modern applications. With Stackery, you can quickly build a picture of your distributed serverless application that incorporates multiple AWS accounts and AWS regions, creating a comprehensive view of your application’s deployment and resource needs. These definitions can then be incorporated into your build process, allowing you to leverage the infrastructure-as-code pattern to manage your cross-region and cross-account serverless applications.
While Stackery brings stability to your deployment process, it does not fully address the issue of maintenance and observability, the second concern when it comes to multi-region and multi-account AWS applications. Metrics for multiple functions are split across regions and accounts, which leads to challenges when you’re trying to discern the current health of your serverless application. Thundra takes the next step in serverless application monitoring by tying all of your AWS operational resources together into a single interface.
Thundra keeps track of function metadata as your functions execute, building a comprehensive picture of your serverless application independent of AWS region and AWS account. All of your serverless functionality is presented in a single, queryable dashboard that can help you organize and easily find all of your Lambda functions. Thundra, using function metadata, can easily present functions from multiple AWS regions and accounts in a single interface. This allows you to more quickly build a snapshot of your application’s control flow functionality, letting you reduce time to resolution by giving you a clearer picture of what went wrong.
Maintaining Multi-region AWS Serverless Applications Is a Breeze with Thundra
Maintaining serverless applications that span AWS regions and accounts requires careful planning. Native tools can get you pretty far along the path to observability, but they still present challenges when you’re working in a highly distributed serverless environment. Thundra can bring all of your functions under one roof, consolidating them into a single, easy-to-read dashboard with a highly usable interface. With Thundra, you can take maintenance of your multi-region AWS serverless applications to the next level.
When working with AWS Lambda functions, the question of region is one of the first you need to answer. As each Lambda function lives in a specific AWS region, and each AWS region has a slightly different set of functionality, you may find yourself having to work with functions in multiple regions on a regular basis.
Managing functions across multiple AWS regions is troublesome enough, but when working with large applications you’re often required not only to manage functions across multiple regions, but also across multiple AWS accounts. In this article we’ll explore tactics for managing AWS Lambda-driven applications that are split across multiple AWS regions and accounts. We’ll review the problem space with an overview of how AWS is structured, discuss what’s available for native tooling, then look at alternatives that can ease the process.
Understanding How AWS Is Set Up
AWS, in order to provide maximum resiliency, is split into a number of global regions. These regions are then further divided into availability zones. These designations—region and availability zone—can determine a lot about the functionality available to you, as not every region will have all of the functionality you need. This means that your functions may need to speak cross-region, particularly if you’re working to optimize your application’s geographic proximity to the users with edge zones.
This is crucial because of the way in which AWS services tend to be billed. Communications from one AWS service to another within the same region are often done at a low cost, while communications that span multiple regions carry a premium. For example, transmission rates between AWS zones can be billed at up to $0.02 per GB. However, when an availability zone has an issue, it often affects all of the services within that zone. That means an entire application can be brought down, and your users are subject to the recovery time that AWS can meet.
Therefore, it’s critical to understand this setup to factor maintainability and sustainability into your serverless application’s architecture. While you can potentially reduce your costs by keeping all of your services within the same AWS region, this adds the risk that your application will be taken down by things outside of your control. Building a cross-region serverless application is the only way to provide resiliency against region outages.
Initial Strategy for Managing Widely Dispersed Lambda Functions
The first place we will look to ease cross-region management is the AWS Command-Line Interface, or CLI. The CLI allows you to quickly manage AWS services from a command line, creating and destroying services as needed with a few commands. These commands can then be added to scripts and shared among developers. The AWS CLI is a good first step in providing reproducible cross-region architecture, but it has a fatal flaw: it operates only on one single authenticated AWS account at a time. This can pose problems when you’re trying to consolidate information from similar functions that span multiple AWS accounts.
Next is AWS CloudFormation, which helps you organize each region’s deployment mechanism. This lets you define the critical infrastructure you need as code and improve maintainability and deployability by reducing your application’s configuration to a set of human-readable configuration files. With a few CloudFormation templates, you can automate your entire application infrastructure, but you’ll still need to maintain multiple configuration files to support your cross-region approach.
AWS SAM is a newer option for pulling your function configuration into a coherent whole. SAM provides a flexible template language you can use to build your AWS application resource specifications at a higher level than with CloudFormation. With AWS SAM, you can define all of the resources needed for your serverless functions, compile them into CloudFormation templates, and execute the deploy—all without touching a user interface component. With this flexibility, you can solve a lot of the problems of cross-region support just by sharing and linking configuration files.
The Shortcomings of the Native Approach
While the native tools approach provides us with some benefits when managing cross-region applications, executing a comprehensive plan to monitor and maintain an application that spans multiple regions still requires a lot of planning and knowledge. You’ll need, for example, to handle multiple deployment processes—one for each region. This can be an error-prone process unless you use tools to generate the configuration. If you do, however, you’ll either have one more application to maintain or you’ll be spending a lot of money on third-party solutions.
Additionally, it can be challenging to discriminate between Lambda functions when you’re troubleshooting from within AWS. If you have the same function available in multiple AWS regions, there is simply no good way to consolidate all of the logs into a cohesive whole, or to determine exactly which version of the function was the source of a given failure. Working with multiple AWS accounts complicates this even further.
Solving Native Pain Points with Third-Party Tools
All of this means that you’ll need to rely on third-party tools to improve your ability to manage your Lambda functions. The design of AWS and its dependent services means there are hard divides between each application. The first divide is at the region level—most AWS tools are designed to work with a single region at a time. While there are some first-party tools that address this issue (AWS SAM, for instance, consolidates deployment of serverless functions into a single template file), they do not offer much insight into your application as a whole.
Applications that span multiple AWS accounts compound this issue. There’s no easy dashboard in AWS that lets you review architectural elements that span multiple accounts. You can modify how the services on each account interact with each other, adding in explicit reporting of cross-account metrics and system health, but this requires deliberate and dedicated effort to implement.
Third-party tools bolster the native functionality provided, building an intermediary layer between the application and the functions that comprise it. This allows third-party tools to provide a view of your application that is simply not possible with the native tool chain. This is most applicable at the deployment and monitoring stages of your project. The holistic view of your application that third-party tools can provide is crucial in building a cross-region/cross-account application that is maintainable, deployable, and dependable.
Building for Maintenance and Observability
To nail down the multi-region/multi-account issue, we’ll take a look at two areas of concern— deployment and observability—and how third-party tools solve them. The first concern we’ll look at is deployment management. When your serverless application spans multiple regions and accounts, your deployment process quickly becomes a mess of random credentials, region names, and endpoints that can be confusing to application maintainers.
Stackery is a third-party tool dedicated to solving this issue by providing a serverless platform that lets you design, develop, and deliver modern applications. With Stackery, you can quickly build a picture of your distributed serverless application that incorporates multiple AWS accounts and AWS regions, creating a comprehensive view of your application’s deployment and resource needs. These definitions can then be incorporated into your build process, allowing you to leverage the infrastructure-as-code pattern to manage your cross-region and cross-account serverless applications.
While Stackery brings stability to your deployment process, it does not fully address the issue of maintenance and observability, the second concern when it comes to multi-region and multi-account AWS applications. Metrics for multiple functions are split across regions and accounts, which leads to challenges when you’re trying to discern the current health of your serverless application. Thundra takes the next step in serverless application monitoring by tying all of your AWS operational resources together into a single interface.
Thundra keeps track of function metadata as your functions execute, building a comprehensive picture of your serverless application independent of AWS region and AWS account. All of your serverless functionality is presented in a single, queryable dashboard that can help you organize and easily find all of your Lambda functions. Thundra, using function metadata, can easily present functions from multiple AWS regions and accounts in a single interface. This allows you to more quickly build a snapshot of your application’s control flow functionality, letting you reduce time to resolution by giving you a clearer picture of what went wrong.
Maintaining Multi-region AWS Serverless Applications Is a Breeze with Thundra
Maintaining serverless applications that span AWS regions and accounts requires careful planning. Native tools can get you pretty far along the path to observability, but they still present challenges when you’re working in a highly distributed serverless environment. Thundra can bring all of your functions under one roof, consolidating them into a single, easy-to-read dashboard with a highly usable interface. With Thundra, you can take maintenance of your multi-region AWS serverless applications to the next level.
When working with AWS Lambda functions, the question of region is one of the first you need to answer. As each Lambda function lives in a specific AWS region, and each AWS region has a slightly different set of functionality, you may find yourself having to work with functions in multiple regions on a regular basis.
Managing functions across multiple AWS regions is troublesome enough, but when working with large applications you’re often required not only to manage functions across multiple regions, but also across multiple AWS accounts. In this article we’ll explore tactics for managing AWS Lambda-driven applications that are split across multiple AWS regions and accounts. We’ll review the problem space with an overview of how AWS is structured, discuss what’s available for native tooling, then look at alternatives that can ease the process.
Understanding How AWS Is Set Up
AWS, in order to provide maximum resiliency, is split into a number of global regions. These regions are then further divided into availability zones. These designations—region and availability zone—can determine a lot about the functionality available to you, as not every region will have all of the functionality you need. This means that your functions may need to speak cross-region, particularly if you’re working to optimize your application’s geographic proximity to the users with edge zones.
This is crucial because of the way in which AWS services tend to be billed. Communications from one AWS service to another within the same region are often done at a low cost, while communications that span multiple regions carry a premium. For example, transmission rates between AWS zones can be billed at up to $0.02 per GB. However, when an availability zone has an issue, it often affects all of the services within that zone. That means an entire application can be brought down, and your users are subject to the recovery time that AWS can meet.
Therefore, it’s critical to understand this setup to factor maintainability and sustainability into your serverless application’s architecture. While you can potentially reduce your costs by keeping all of your services within the same AWS region, this adds the risk that your application will be taken down by things outside of your control. Building a cross-region serverless application is the only way to provide resiliency against region outages.
Initial Strategy for Managing Widely Dispersed Lambda Functions
The first place we will look to ease cross-region management is the AWS Command-Line Interface, or CLI. The CLI allows you to quickly manage AWS services from a command line, creating and destroying services as needed with a few commands. These commands can then be added to scripts and shared among developers. The AWS CLI is a good first step in providing reproducible cross-region architecture, but it has a fatal flaw: it operates only on one single authenticated AWS account at a time. This can pose problems when you’re trying to consolidate information from similar functions that span multiple AWS accounts.
Next is AWS CloudFormation, which helps you organize each region’s deployment mechanism. This lets you define the critical infrastructure you need as code and improve maintainability and deployability by reducing your application’s configuration to a set of human-readable configuration files. With a few CloudFormation templates, you can automate your entire application infrastructure, but you’ll still need to maintain multiple configuration files to support your cross-region approach.
AWS SAM is a newer option for pulling your function configuration into a coherent whole. SAM provides a flexible template language you can use to build your AWS application resource specifications at a higher level than with CloudFormation. With AWS SAM, you can define all of the resources needed for your serverless functions, compile them into CloudFormation templates, and execute the deploy—all without touching a user interface component. With this flexibility, you can solve a lot of the problems of cross-region support just by sharing and linking configuration files.
The Shortcomings of the Native Approach
While the native tools approach provides us with some benefits when managing cross-region applications, executing a comprehensive plan to monitor and maintain an application that spans multiple regions still requires a lot of planning and knowledge. You’ll need, for example, to handle multiple deployment processes—one for each region. This can be an error-prone process unless you use tools to generate the configuration. If you do, however, you’ll either have one more application to maintain or you’ll be spending a lot of money on third-party solutions.
Additionally, it can be challenging to discriminate between Lambda functions when you’re troubleshooting from within AWS. If you have the same function available in multiple AWS regions, there is simply no good way to consolidate all of the logs into a cohesive whole, or to determine exactly which version of the function was the source of a given failure. Working with multiple AWS accounts complicates this even further.
Solving Native Pain Points with Third-Party Tools
All of this means that you’ll need to rely on third-party tools to improve your ability to manage your Lambda functions. The design of AWS and its dependent services means there are hard divides between each application. The first divide is at the region level—most AWS tools are designed to work with a single region at a time. While there are some first-party tools that address this issue (AWS SAM, for instance, consolidates deployment of serverless functions into a single template file), they do not offer much insight into your application as a whole.
Applications that span multiple AWS accounts compound this issue. There’s no easy dashboard in AWS that lets you review architectural elements that span multiple accounts. You can modify how the services on each account interact with each other, adding in explicit reporting of cross-account metrics and system health, but this requires deliberate and dedicated effort to implement.
Third-party tools bolster the native functionality provided, building an intermediary layer between the application and the functions that comprise it. This allows third-party tools to provide a view of your application that is simply not possible with the native tool chain. This is most applicable at the deployment and monitoring stages of your project. The holistic view of your application that third-party tools can provide is crucial in building a cross-region/cross-account application that is maintainable, deployable, and dependable.
Building for Maintenance and Observability
To nail down the multi-region/multi-account issue, we’ll take a look at two areas of concern— deployment and observability—and how third-party tools solve them. The first concern we’ll look at is deployment management. When your serverless application spans multiple regions and accounts, your deployment process quickly becomes a mess of random credentials, region names, and endpoints that can be confusing to application maintainers.
Stackery is a third-party tool dedicated to solving this issue by providing a serverless platform that lets you design, develop, and deliver modern applications. With Stackery, you can quickly build a picture of your distributed serverless application that incorporates multiple AWS accounts and AWS regions, creating a comprehensive view of your application’s deployment and resource needs. These definitions can then be incorporated into your build process, allowing you to leverage the infrastructure-as-code pattern to manage your cross-region and cross-account serverless applications.
While Stackery brings stability to your deployment process, it does not fully address the issue of maintenance and observability, the second concern when it comes to multi-region and multi-account AWS applications. Metrics for multiple functions are split across regions and accounts, which leads to challenges when you’re trying to discern the current health of your serverless application. Thundra takes the next step in serverless application monitoring by tying all of your AWS operational resources together into a single interface.
Thundra keeps track of function metadata as your functions execute, building a comprehensive picture of your serverless application independent of AWS region and AWS account. All of your serverless functionality is presented in a single, queryable dashboard that can help you organize and easily find all of your Lambda functions. Thundra, using function metadata, can easily present functions from multiple AWS regions and accounts in a single interface. This allows you to more quickly build a snapshot of your application’s control flow functionality, letting you reduce time to resolution by giving you a clearer picture of what went wrong.
Maintaining Multi-region AWS Serverless Applications Is a Breeze with Thundra
Maintaining serverless applications that span AWS regions and accounts requires careful planning. Native tools can get you pretty far along the path to observability, but they still present challenges when you’re working in a highly distributed serverless environment. Thundra can bring all of your functions under one roof, consolidating them into a single, easy-to-read dashboard with a highly usable interface. With Thundra, you can take maintenance of your multi-region AWS serverless applications to the next level.
