Architecting Multi-Region SaaS Solutions on AWS
By Tod Golding, Partner Solutions Architect at AWS
As software-as-a-service (SaaS) organizations grow and begin to extend their global reach, they must consider how their larger geographic footprint will shape and influence the architecture of their systems. Operations, deployment, agility, security, and scale all can be impacted by the move to a geographically distributed SaaS model.
This move to a multi-region model often represents a major shift for SaaS organizations. The more complexity that is added to a system’s operational and deployment profile, the more challenging it becomes to maintain the agility goals that are often associated SaaS delivery models.
This challenge of embracing the need for multi-region distribution while remaining responsive to your market is the focus of this blog post. The goal here is to explore the factors that are often behind a SaaS organization’s adoption of a multi-region strategy. With this motivation as a backdrop, we can dig into the architectural patterns and strategies that are commonly used when building, deploying, and managing multi-region SaaS environments.
Scoping the Multi-Region Problem
The topic of multi-region architecture is very broad, covering a wide range of architectural considerations that can influence many dimensions of your system’s architecture. AWS has a collection of useful resources that provide good general guidance on multi-region architecture. There are blog posts and whitepapers that look at the multi-region capabilities of individual services, networking models, and general failover patterns. A sampling of multi-region reference materials are included at the end of this post.
For the purposes of our discussion, it makes more sense to focus on the nuances and motivations associated with multi-region SaaS environments. This guidance, paired with the broader coverage of multi-region strategies, should equip you with a foundational set of considerations that can be factored into your overall multi-region strategy.
What’s Behind the Move to Multi-Region SaaS?
Before we look at multi-region architecture, let’s start by understanding the dynamics that push some SaaS providers to a multi-region model. In many cases, SaaS ISVs can address basic geographic challenges through classic, edge-based content distribution strategies. Amazon CloudFront, for example, can be used to solve the latency issues that are often associated with geographic distribution.
There is a point at which this problem moves away from static content distribution and becomes more focused on availability, performance, and regional considerations. In these cases, you must introduce new and often custom mechanisms to achieve your multi-region goals. Below is a list of the common factors that often motivate a SaaS provider’s move toward a multi-region model.
- Failover: The ability to withstand regional system failures, enabling part or all of a system to effectively transition load to an alternate region.
- Latency: The need to process and serve non-static data without incurring the overhead of long network hops.
- Compliance: Variations in regional compliance requirements means data and services must be regionally hosted.
Failover is a fairly broad multi-region topic that is often more about adopting a disaster recovery model that can withstand regionalized application issues. In this mode, SaaS providers are often looking at ways to replicate some or all of their environment to another region. In the event of a failure, their system can gracefully redirect traffic to another region.
Failover can be implemented in a number of different models and at varying levels of granularity in your solution. The approach you choose here would be driven by the nature of your architecture and the decomposition of your system. It can also be influenced by the replication capabilities of the various tools and services you are using in your solution. Having a robust failover strategy may be of particular interest to SaaS providers where all of a region’s customers could be hosted in a single, shared infrastructure footprint. In this model, you may opt to for a cross-region model to limit the blast radius of a region-centric application issue.
Latency and compliance, on the other hand, are more common drivers of multi-region adoption by SaaS providers. For some global SaaS providers, the access patterns and general usage models for their applications make housing their solution in a single region challenging. While edge-based content can help, there are some application flows that may not be adequately covered by a content delivery network (CDN). You may have aspects of your application that are transacting data that must be served directly by one or more application services. In these cases, you may quickly reach a tipping point where it becomes natural to deploy some or all of your application directly into a region. If, for example, you were building an ad serving platform that required millisecond rendering of ads, you may find that serving content from a single region may not be adequate.
Compliance is often driven by the regional regulations that govern data privacy. Data sovereignty and General Data Protection Regulation (GDPR) requirements will often impose restrictions that can only be successfully addressed through some flavor of a multi-region strategy. Even in these scenarios, there may be an option to pick and choose those parts of your application that are subject to the regional compliance issues. In these cases, you may find yourself balancing the complexity of deploying and managing a more complex architectural footprint. Typically, in these scenarios, SaaS providers prefer to move their entire solution into a region.
The Impact of a Multi-Region Model
Now that we have a good handle on some of the common themes that can push a SaaS provider toward a multi-region model, let’s look at how the adoption of a multi-region model impacts the design, architecture, operations, and agility of your SaaS solution. The over-arching goal here is to find to a way to introduce the notion of multi-region without completely compromising the agility goals that are fundamental to most SaaS solutions.
The following sections highlight some of the key areas that require consideration as you move to a multi-region SaaS model. This is not a comprehensive list, but it does represent some of the common challenges that are confronted by SaaS organizations.
Tenant Onboarding
Providing a frictionless onboarding experience is essential to SaaS organizations. The goal here is to streamline the process of acquiring and provisioning new customer environments. Of course, if your solution is hosted in multiple regions, this can add a wrinkle to your onboarding process.
Figure 1 provides an illustration of one approach to take when onboarding tenants in a multi-region model. You’ll notice we have a group of new tenants signing up for our SaaS solution in a number of regions. In this model, the tenants provide data during the signup process that distinguishes their target region. A shared onboarding service would then be responsible for orchestrating the provisioning of the new tenants in their designated regions.
This model attempts to centralize the onboarding process in a single region. This simplifies and streamlines the process, but it can also present a challenge in terms of compliance. By collecting a users’ information outside each region, it’s likely you will violate the sovereignty requirements of a given region. However, if you are not facing compliance issues, then you could find the approach appealing.
The alternative to this strategy is to decentralize some aspects of your onboarding process. Figure 2 represents an alternated approach to this problem that distributes the onboarding process to each region.
The basic difference is that the onboarding experience is now hosted in each region, allowing you to ensure any data collected about the tenant is managed within the scope of the region. The main challenge of this model is determining how tenants will be redirected to each regional onboarding experience. In this case, we introduced a landing/routing page that allows users to opt into the region of their choosing. This is just one option, and each solution may take a different approach to landing their tenants in the correct region. They key takeaway is that the actual onboarding and collection of a tenant’s data is localized to a region.
In this more distributed model, you do add some complexity to your deployment model and lose the ability to manage and deploy a centralized experience. Still, if you are deploying into regions with GDPR or general data sovereignty requirements, this is often your only option.
Multi-Region Identity
Once you’ve successfully onboarded a tenant, you still have to decide how your multi-region environment will support authentication. While it would be nice to have a centralized model identity provider for all of your users, the centralization of this data does not align with any of the fundamental data sovereignty requirements that govern the management of personal information.
With this in mind, your approach to identity should focus on the tenant experience and the introduction of a mechanism that can effectively route your identity management to each region. In many respects, the challenges outlined here overlap with the onboarding discussion above. Now, however, you must have a non-invasive model for routing users to a region-centric authentication experience.
Ideally, you would like this to be a relatively seamless experience for your tenants where the routing to a given region is mostly transparent. One common approach to resolving this is to embed tenant context in the URL of your application. Figure 3 provides a sample of what this might look like in practice.
With this model, each tenant is assigned a unique URL that was provisioned as part of their onboarding experience. In this example, we have created subdomains that prepend the tenant scope to the application’s URL. This subdomain uses traditional DNS routing (shown as Amazon Route 53 in Figure 3) to direct each tenant to the appropriate region.
Once you are routed to the appropriate region, your SaaS solution relies on a regionally hosted identity provider to manage and authenticate users of your system. In this case, we’ve shown Amazon Cognito as the identity provider for each region.
While this model adds a configuration element and more moving parts to your tenant provisioning process, it also yields a much more intuitive experience for end users. It’s also important to note the tenant identifier that was prepended to the subdomain should never map directly to any internal representation you might have of your actual tenant identifier. Instead, this surfaces as a unique subdomain that only serves the purpose of routing users to their regions.
There are some scenarios where your application may need to rely on the tenant to select a target region or environment before they can authenticate. This shows up in cases where a user may have the option to have accounts in multiple regions. In these cases, surfacing the region as part of the authentication experience may be unavoidable.
For some solutions, you may be required to support identity portability where a user wants to move their existing identity from one region to another. This, too, may require additional workflows in your user management system to enable transfers of this nature. It also has the potential to challenge compliance regulations.
Management and Monitoring
Even as you distribute customer environments to individual regions, you’d still prefer to have a centralized model for managing and monitoring the overall health of tenants. In fact, as you move to a more distributed multi-region model, the need for robust operational tooling becomes more pronounced. The key is to put in place a mechanism that efficiently scales your operational footprint, allowing you to observe the regional and global health of your SaaS environments through a centralized experience.
There are a number of different approaches that can be taken to centrally aggregate the data from each of your regions. The model you choose will be driven by the stack and tooling that best fits your application. Some solutions, for example, capture data locally then replicates it across regions. Others might stream log data directly to some centralized repository.
Fortunately, the APN Partner community includes a number of different solutions in the management monitoring domain that can simplify your path to multi-region monitoring. Sumologic, New Relic, Datadog, and Dynatrace are among the rich collection of monitoring Partner solutions you may want to consider. Each of these products has its own model for capturing and analyzing multi-region environments.
AWS also has networking constructs that can be useful in building out your management environment. Cross-region VPC peering, for example, is used by some organizations to manage distributed environments. This can add security to your management footprint and may simplify the automation and deployment experience. As you might suspect, you will need to factor GDPR into your monitoring strategy. In some cases, you may need to ensure the data you’re logging is completely sanitized and complies with the requirements outlined in GDPR regulations.
Deployment Automation
Agility is one of the driving forces behind the adoption of a SaaS delivery model. However, as you move to a multi-region footprint, this has the potential to add complexity to your environment and undermine agility goals. Deployment, for example, becomes a much more involved process as you consider the automation and DevOps pipeline implications associated with releasing your product in multiple regions.
The key to maintaining agility in a multi-region model is to limit the amount of variation that is introduced for each deployment. This is really just an extension of core DevOps tenets with additional emphasis on creating automated, repeatable deployment processes that manage all aspects of configuration through code.
Figure 4 provides a conceptual view of a multi-region pipeline. The goal here is to view each regional deployment as a clone of the environment that might have originally been hosted in a single region. As you move to a multi-region model, the pipeline must deploy each change (in this case, each microservice) to the target region with the hope that the service requires minimal region-specific changes. Ultimately, the more universal your footprint across all regions, the more likely you’ll be able to release new features without feeling the multi-region model is hindering your agility.
While our goal here is to minimize variation, it’s also possible that some region-specific requirements could add new elements to your pipeline. It would not be uncommon, for example, to see downstream steps added to your pipeline in each region responsible for performing compliance validation. There may nuances based on AWS service variations that could introduce regional configuration and deployment variations, but the goal would still be to view these as extensions of your overall pipeline.
Billing
Like management and monitoring, billing is a service that should be implemented using a centralized model. Ultimately, you’d like to have one experience that manages SaaS customer accounts, policies, and billing activity. The idea is that metering and activity data needed to generate a SaaS bill should be published from each region to a centralized system that is responsible for aggregating the information and generating a bill. This same system would be responsible for pushing updates to customers’ status, policies, and configuration to each region.
Of course, while this is the preferred state, it is also complicated by compliance and regulations. In situations where you face sovereignty or GDPR requirements, you need to build a more decentralized billing model that prevents customer information from leaving a region. So, while the mechanics of billing would be the same across all regions, you would still be required to have each region generate its own bill. This obviously adds complexity and inefficiency to your billing process but may be unavoidable.
Multi-Region or Multi-Availability Zone
The move to a multi-region model often represents a natural progression for SaaS organizations that face regionalized latency and compliance hurdles. However, when multi-region is adopted purely as a failover strategy, the discussion gets more complicated. In some instances, you may find that a multi-Availability Zone approach will satisfy the failover requirements of your solution without requiring you to absorb the added overhead of a multi-region model.
Ultimately, this comes down to having a firm handle on the factors driving your need for multi-region adoption. As you look at your options, weigh the impact these choices will have on the overall complexity and agility of your solution.
Making the Move
The move to a multi-region model is no trivial undertaking. As you can see from the items covered above, there are a number of factors to consider when thinking about how to deliver SaaS solutions in a multi-region environment. Onboarding, identity, operations—all of these areas require specific architectural strategies that address the requirements imposed by a multi-region model. In making this transition, you must remain focused on creating a seamless experience for customers.
Multi-region environments also have the potential to impact the agility of your organization. It is essential that your multi-region approach places an even higher premium on your ability to automate and manage your solution to ensure you can continue to release features and functionality at a rapid pace.
Additional Resources and Next Steps
About AWS SaaS Factory
AWS SaaS Factory provides AWS Partner Network (APN) Partners with resources that help accelerate and guide their adoption of a SaaS delivery model. SaaS Factory includes reference architectures for building SaaS solutions on AWS; Quick Starts that automate deployments for key workloads on AWS; and exclusive training opportunities for building a SaaS business on AWS. APN Technology Partners who develop SaaS Solutions are encouraged to join the program!
相關推薦
Architecting Multi-Region SaaS Solutions on AWS
By Tod Golding, Partner Solutions Architect at AWS As software-as-a-service (SaaS) organizations grow and begin to extend their global rea
SaaS Solutions on AWS: A New Whitepaper for APN Partners
As building Software as a Service (SaaS) solutions on AWS increasingly becomes an area of focus for APN Partners like you, we want to ensure we’re
Building a Software/SaaS Business on AWS – the ISV Partner Playbook from Splunk
The following is a guest post from our friends at Splunk, an all-in AWS Technology Partner, and AWS SaaS Partner. As AWS increasingly bec
Building Serverless SaaS Applications on AWS
By Tod Golding, Partner Solutions Architect at AWS Software as a service (SaaS) solutions often present architects with a diverse mix of s
「Computer Vision」Notes on Multi-Region CNN
QQ Group: 428014259 Sina Weibo:小鋒子Shawn Tencent E-mail:[email protected] http://blog.csdn.net/dgyuanshaofeng/article/details/83834303 [1]
Identity Federation and SSO for SaaS on AWS
Editor’s note: For the latest information, visit the . By Matt Yanchyshyn, Senior Manager of Partner Solutions Architecture at AWS
Architecting on AWS
This course covers the fundamentals of building IT infrastructure on the AWS platform. Students learn how to optimize the AWS Cloud by u
Modeling SaaS Tenant Profiles on AWS
Editor’s note: For the latest information, visit the . By Tod Golding, Partner Solutions Architect at AWS Most software companies
SaaS on AWS
The breadth and depth of tools and services available on AWS can facilitate a faster time-to-market for SaaS providers. The pace of inno
Advanced Architecting on AWS
アマゾン ウェブ サービスでは人材を募集中です。 アマゾン ウェブ サービス(AWS)は、ダイナミックに成長している Amazon.com のビジネス部門の 1 つです。現在、ソフトウェア開発エンジニア、プロダクトマネージャー、アカウントマネージャー、ソリューションアーキテク
SaaS on AWS – Announcing the Launch of the AWS SaaS Partner Program
Over the past year, a number of leading technology firms declared that that they’re “all-in” on AWS, meaning that AWS is their strategic cloud pla
Using AWS CodePipeline to Perform Multi-Region Deployments
AWS CodePipeline is a fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable application a
Building Connected Vehicle Solutions on the AWS Cloud
In response to massive technological changes that are transforming the global automotive industry, the AWS Solutions team has developed the AWS Co
AWS Training | Instructor-Led | Architecting on AWS
Amazon Web Services is Hiring. Amazon Web Services (AWS) is a dynamic, growing business unit within Amazon.com. We are currently hiring So
使用bedtools提取vcf多個位置的變異(extract multi-region of genotypes by bedtools)
提取 targe intersect doc pre orm mut 生成 dto 1、下載安裝bedtools; 2、生成bed文件;標準的bed文件格式如下: chr7 127471196 127472363 Pos1 0 + 127471196
DevOps on AWS之Cloudformation概念介紹篇
Cloudformation的相關概念 AWS cloudformation是一項典型的(IAC)基礎架構即程式碼服務。。通過編寫模板對亞馬遜雲服務的資源進行呼叫和編排。藉助cloudformation可以極大幫助DevOps提升工作效率,減少重複勞動,配置和部署相關服務的時間,並把更多的精力花在應用程式領
DevOps on AWS之Cloudformation實踐篇
cloudformation入門實踐 AWS cloudformation通過模板對AWS雲資源進行編排和呼叫。並且可以通過模板程式碼層面的修改就可以對現有環境進行升級改造,雲端業務的靈活便捷特點展現無疑。下面我們通過一個入門級的簡單動手案例給大家展示cloudformation是如何使用的。希望大家也動手
DevOps on AWS之Elastic BeanStalk
Elastic BeanStalk相關概念 童話世界中存在著一種魔力beanstalk(豆莢),種在花盆裡可以無限的向上生長,越長越高直達雲端。AWS Elastic Beanstalk也採用類似概念,使用者只需部署程式碼即可自動處理包括容量預置、負載均衡、自動擴充套件和應用程式執行狀況監控在內的部署工作。
DevOps on AWS之OpsWorks初體驗
AWS OpsWorks 是一款配置管理服務,提供 Chef 和 Puppet 的託管EC2虛擬機器例項。Chef 和 Puppet 是自動化平臺,允許使用者使用程式碼來自動配置伺服器。使用者藉助OpsWorks可以使用 Chef或Puppet 自動完成所有 EC2 例項或本地計算環境中的
Building Serverless Apps on AWS 在AWS上構建無伺服器應用程式 Lynda課程中文字幕
Building Serverless Apps on AWS 中文字幕 在AWS上構建無伺服器應用程式 中文字幕Building Serverless Apps on AWS 瞭解如何在Amazon Web Services(AWS)上開發NodeJS無伺服器應用程式 首先,介紹