Framework for platform expansion to Europe, Middle East and beyond

In a previous post on the Public Sector Blog, we covered six key strategies in which Amazon Web Services (AWS) empowers AWS Partners to expand their platforms globally to reach more customers while meeting requirements such as data residency and sovereignty. These ranged from using AWS Global Infrastructure to AWS services that make it easier for partners to implement requirements consistently. In this post, we consolidate those steps into a framework that can guide partners to plan for expansion, design their architecture, and deploy their platforms into a new AWS Region while navigating critical decisions.

For effective and efficient global expansion, AWS Partners need to design a flexible platform architecture that can meet the requirements of their users in different geographic regions and industries. These requirements typically fall into three categories: performance, compliance, and resilience. The design is a balance between these three dimensions and agility and cost to maintain the platform. The following graphic illustrates this.

Figure 1: Dimensions of a flexible platform architecture

To cover critical design decisions, we use a software-as-a-service (SaaS) platform as a vehicle of discussion, but part of the content will also resonate for other software delivery methods.

Framework

We propose a four-stage framework for partners to expand their platforms successfully into new geographical regions: assessment, design, implementation, and operations. The assessment phase covers market research, cost analysis, compliance requirements, cross-Region dependencies, and analysis of AWS Global Infrastructure and services to guide the delivery method. The design stage involves architecting a flexible platform to reduce speed to market while meeting user requirements in a cost-effective way. This covers SaaS control plane, tenant isolation, data sovereignty, resilience and backup, and security. Implementation is focused on having an efficient deployment and tenant onboarding process, and it includes capacity planning, migration, and testing. Finally, the operations phase is indexed on automating operations. This includes monitoring and observability, compliance and audit reporting, and incident response.

This framework is illustrated in the following graphic.

Figure 2: Framework for expanding globally

Assessment

In our discussions with AWS Partners about Regional expansion, the most-requested help topic is assessing their current environment for Region expansion readiness. Performing a thorough assessment of both technical capabilities and business drivers prior to starting a Regional expansion product avoids surprises along the way and helps justify the level of effort to achieve expansion while meeting business goals. In some cases, it can be beneficial to reconsider how your existing application is built and whether fundamental or minor changes are necessary to deploy and manage your application in multiple geographic areas.

Assessment begins with performing market research to understand the competitive and regulatory requirement differences in your new geographic areas. For example, is your application subject to distinct data residency, know-your-customer, or operational access controls? In addition, do customers in your new market require localized changes such as regional telecom providers for SMS one-time-passwords or payment processors? The assessment phase is also where you will determine your desired timeline for your application build-out against your customer demand. Through proper planning, our aim is to reduce as much as possible the time between your application’s resources generating charges from AWS and onboarding paying customers.

Moving to the technical assessment, your assessment should include an understanding of changes necessary to your deployment methods and any cross-Region dependencies that might arise in a multi-Region deployment. Some partners choose to have completely isolated deployments in geographic regions, whereas others choose to have a global control plane. The choice of a global or Regional control plane can depend on factors such as how customer metadata is managed and the effort required to extend (or not) an existing control plane to multiple Regions.

Additionally, your assessment should evaluate your existing infrastructure requirements compared to the service offerings in your target Regions. The two primary methods of collecting what AWS services and APIs are in use currently is to reference your infrastructure as code (IaC) templates as well as data mining AWS CloudTrail logs. Especially when considering newly available Regions, it’s important to recognize which services are available at the start and which are offered shortly after launch, which is available on the AWS Global Infrastructure Regions and Availability Zones page.

To learn more about available Regions, visit the AWS Capabilities page. You can select target Regions and filter by AWS products to find out the following:

• Services – Regional availability of AWS services
• Features – Specific capabilities within each service
• API operations – Individual API calls and their Regional availability
• AWS CloudFormation resources – IaC resource support such as Amazon Elastic Compute Cloud (Amazon EC2) instance types or Amazon Relational Database Service (Amazon RDS) engine versions

A noteworthy accessibility option in addition to the AWS Capabilities resource is the AWS Knowledge MCP server, which allows large language model (LLM)-based planning solutions to use the same information using the aws___get_regional_availability tool. An example walkthrough of performing a Regional comparison using an agentic workflow is available in Accelerate Region expansion with the AWS Knowledge MCP server on the AWS Blog. This workflow can also be extended to include the AWS Pricing MCP server to assist in regional price comparisons.

In some geographies where AWS Regions don’t exist, partners can still consider alternative deployment options, such as using AWS Local Zones, or hybrid options such as AWS Outposts, Amazon EKS Anywhere, or Amazon ECS Anywhere. In these cases, you can operate and host your data and application plane within geographic boundaries while maintaining control plane and deployment orchestration functions within AWS. Carefully evaluate architectural decisions and the trade-offs necessary to support these local deployment options because each has different AWS service support. AWS AI Factories provides fully managed AI infrastructure in AWS customers’ data centers and can help meet data sovereignty requirements. Partners can use this for training models and inference.

At the end of the assessment phase, you should have a clear understanding of your infrastructure requirements, the availability of the target Region to support your technical stack, and any modifications or extensions necessary to support local requirements. For details related to Regions that have not yet been made publicly available or for assistance planning your Regional expansion, work with your AWS account team.

Design

A SaaS platform typically has a control plane and an application plane. The control plane is for tasks such as tenant management and onboarding new tenants, and it usually contains only metadata rather than actual user data. The application plane is where tenant data is stored and processed. As an example, an AWS Partner that is US-based initially deploys both the control plane and application plane of their SaaS platform in a US Region, such as US East (N. Virginia) – us-east-1. When the partner has customers in the UK or Europe, they can use AWS services such as Amazon CloudFront and AWS Global Accelerator to help with performance. If they have customers in regulated industries, these customers typically demand their data to be stored in country. In this case, assuming customers are in the UK or Europe, the partner can deploy an application plane in the Europe (London) eu-west-2 Region or one of the Europe Regions respectively, with the control plane remaining global in US East (N. Virginia) – us-east-1. Each Region is designed to be independent from other Regions, allowing the SaaS platform application plane to continue to operate (existing end customers will not be impacted) even if the SaaS control plane is temporarily impaired (adding new end customers, for example).

AWS European Sovereign Cloud is a separate partition from AWS commercial Regions, meaning not only customer data but also customer metadata such as billing, account, and identity remains in the European Union (EU). Although AWS European Sovereign Cloud has internet connectivity, AWS customers choose it because all data remains in the EU, and it has no critical dependencies on non-EU infrastructure. Therefore, when a partner deploys their SaaS platform into AWS European Sovereign Cloud, they would likely be required by end customers to also have a separate control plane deployed in AWS European Sovereign Cloud.

Although not a common request, partners might also have a similar requirement to have a Regional or single Region control plane even when the SaaS platform is deployed in a commercial AWS Region such as the Europe (London) Region or one of the Europe Regions.

We also see partners offering different tenant isolation options to customers, such as pool, bridge, or silo, in order to meet compliance requirements. For example, for a large customer or a customer community (such as government or national healthcare), the partner might create a separate AWS account to host the application plane, whereas for a smaller customer they might offer a pooled tenant for efficiency and optimization.

Ultimately, we recommend that partners build flexibility into their platforms to be able to offer options to their customers for control plane and tenant isolation based on the type of workload. The following diagram depicts these architecture models.

Figure 3: SaaS architecture models

The second major design consideration when expanding globally is on maintaining data sovereignty. In designing your platform and deploying solutions, you need to be aware of data residency regulations. Different countries have different regulations, and these broadly fall into three categories. Privacy-based regulations define whether personally identifiable information (PII) can travel across borders. Confidentiality-based regulations identify what is nationally critical data, such as oil and gas, manufacturing, or finance. Independence-focused regulations require that data remain within the national borders.

We recommend the following approach to ensure you meet data sovereignty requirements:

• Create versions of the application plane that can run on different AWS infrastructure offerings. Being able to deploy the application plane into Local Zones or to Outposts in addition to Regions can help partners meet more stringent data residency requirements.
• Be aware of AWS service scope. AWS operates three different categories of services based on their fault isolation boundary: zonal, Regional, and global. The AWS European Sovereign Cloud is a separate partition, and it has a partition-wide equivalent of the global services, meaning those services are not global but EU-based.
• Manage cross-Region communication effectively. Handle sensitive data appropriately in communications within the SaaS platform and with external APIs, AWS cross-Region services, and backups.
• Choose the right encryption method. Encryption is a powerful tool in providing assurance to customers that their data can’t be accessed by unauthorized individuals, and it’s often overlooked as a key measure. AWS Key Managed Service (AWS KMS) offers multiple options. AWS KMS managed keys and customer managed keys are suitable for most workloads, but AWS CloudHSM or AWS KMS External Key Store (XKS), which allows keys to be stored externally to AWS, can be critical to satisfying more highly regulated workloads.
• Implement data governance accurately. Work back from data classification and privacy requirements and implement access control based on the principle of least privilege.

The following diagram shows the key data sovereignty considerations covering infrastructure, AWS service scope, cross-Region communication, encryption, and data governance.

Figure 4: SaaS data sovereignty considerations

The final recommendation for platform design is to manage security and compliance consistently across your AWS accounts to meet requirements specific to countries and industries. For this, we suggest using AWS Organizations to create an organization hierarchy by geographical region and country, and potentially by industry and regulation. Under the organization root, you create multiple organizational units (OUs) that contain AWS accounts. A separate management account is used for multi-account governance, centralized security and compliance, and implementing digital sovereignty controls using AWS Control Tower across all accounts. And you can implement controls specific to OUs using service control policies (SCPs).

Figure 5: Consistent security and compliance management

Implementation

In the implementation phase, you begin the process of deploying your infrastructure, performing final readiness tests, and possibly performing customer migrations between Regions. Ensure your capacity plans and existing AWS service quotas are sufficient to meet your initial infrastructure needs. One method to do so is cell-based architectures. Cell-based architectures provide both granular fault-isolation boundaries as well as a method for controlling resource contention by limiting the maximum number of tenants within a standardized set of infrastructure resources. Using a standardized cell-resources specification per number of onboarded customers makes quota management much easier to request.

At the limit of the cell-based approach, each AWS Region can be deployed as a single cell. Typically, the tenant placement within cells is managed through the control plane. Often, SaaS providers will use a global control plane to manage all cell deployments in all Regions. However, when considering expansion to geographic regions with data residency requirements, it might be advantageous to move some of the control plane actions inside the cell boundary. The added complexity might be necessary if certain geographies require customer metadata to remain local.

The following diagram illustrates two models of cell-based architectures.

Figure 6: Cell-based architecture

Operations

In the operations phase, you focus on your monitoring and observability, compliance and auditing, and incident response. Here, we focus on the governance challenge of maintaining centralized oversight when your infrastructure is distributed worldwide.

A common governance challenge during Regional expansion is understanding which AWS services operate globally versus Regionally. AWS Security Hub, AWS Resilience Hub, and AWS Audit Manager each address this by providing centralized governance across multi-Region architectures.

AWS Security Hub prioritizes your critical security issues. Its cross-Region, cross-account aggregation designates a home Region where findings from Amazon GuardDuty, Amazon Inspector, Amazon Macie, and AWS Config are consolidated. Through AWS Organizations integration, it enables centralized policy management, providing consistent security standards across your global footprint without per-Region configuration.

AWS Resilience Hub is a central location in the AWS Management Console for you to manage and improve your resilience posture on AWS. It provides centralized assessment of applications spanning multiple Regions, validating that Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets are achievable during Regional failures by identifying cross-Region dependencies and continuously evaluating recovery capabilities.

AWS Audit Manager is for you to continually audit your AWS usage to simplify risk and compliance assessment. It automatically collects evidence from Security Hub, AWS Config, and CloudTrail across all Regions, aggregating it into unified compliance assessments, eliminating Region-by-Region evidence gathering and producing audit-ready reports.

These services form an interconnected governance framework. Security Hub findings become evidence in Audit Manager assessments, Resilience Hub validates that security controls won’t compromise recovery objectives, and Audit Manager proves both security and resilience policies are consistently applied. Without this centralized approach, each new Region multiplies governance complexity. Aggregating into a central control plane simplifies governance and reduces the validation time needed to onboard customers in new Regions.

The following image illustrates the structure of the operational governance control plane.

Figure 7: Operational governance control plane

Next steps

As a next step, we recommend the following concrete actions:

• Plan your global expansion with your AWS account team. Get an up-to-date roadmap of AWS infrastructure releases to make sure you’re using the most suitable offering for your use case and customers. Conduct a well-architected review of your platform to identify changes and improvements required ahead of getting a customer opportunity. Navigate AWS programs that can provide technical, business, funding support.
• Take advantage of the AWS New Region Launch Partner Program, which provides strategic partners who are committed to driving year 1 customer adoption in new AWS Regions funding and support.
• Receive tailored support from the AWS Global Passport program to respond better to strategic, operational, technical, and go-to-market challenges and grow your business internationally.
• Participate in the AWS Business Outcomes Xcelerator (BOX) Program, which brings together software, consulting, and local partners across the globe to accelerate multi-partner solutions for line-of-business buyers.
• Engage with AWS security and compliance specialists in your target areas, who can share valuable expertise on regulations and real customer examples to help meet your requirements.