Empowering AWS Partners to expand their platforms globally

International growth represents a huge potential for HAQM Web Services (AWS) Partners. According to Gartner®, the global software-as-a-service (SaaS) market is projected to reach $286 billion in 2025, and “is forecast to grow at a 15.5% CAGR from 2024 through 2029.”

This post covers technical considerations for partners expanding their services to new geographical regions and explains how AWS can assist. While we focus on SaaS platforms, part of the content is also applicable to all globally hosted services.

There are several compelling reasons for partners to expand their platforms globally, including:

1. Regulatory compliance: Many industries—especially government, healthcare, and finance— have strict data localization laws that require data to be stored and processed within national borders. Expanding into new AWS Regions allows partners to meet these regulatory requirements and tap into previously inaccessible markets.
2. Improved performance and user experience: By deploying services closer to end users, partners can reduce latency and improve application responsiveness and user satisfaction.
3. Data sovereignty assurance: As governments and enterprises become more concerned about data sovereignty, having a local presence demonstrates commitment to data protection and can be a key differentiator in winning contracts.

Each country or geographic jurisdiction has distinct compliance requirements around data residency, operational control, and security (digital sovereignty). These requirements often drive SaaS providers to rethink their architectures: how they manage their hosting, how they store and process data, and how they implement access control and security. This could require providers to implement sovereign control planes rather than a global control plane or adopt specific encryption methods.

In this post, we discuss six key strategies that can empower partners to develop a structured approach to expansion while meeting compliance requirements:

1. Use AWS Global Infrastructure
2. Coordinate with AWS on service availability and capacity
3. Design a flexible platform architecture
4. Manage cross-Region communication effectively
5. Implement security and encryption consistently
6. Navigate compliance requirements and automate evidence collection

1) Use AWS Global Infrastructure

AWS Global Infrastructure includes Regions, sovereign Regions, AWS Local Zones, AWS Dedicated Local Zones, and AWS Outposts. Each of these options provides you with unique capabilities to meet diverse customer needs. AWS Regions and sovereign Regions offer a broad set of services, while Local Zones, Dedicated Local Zones, and Outposts offer a subset of services. Local Zones and Outposts are also available in countries where there are no AWS Regions.

As a partner, the ability to deploy a version of your platform on a Local Zone or an Outposts can help you reach more customers by meeting data sovereignty requirements while using a familiar AWS interface. This can also allow you to implement a pilot until an AWS Region is launched.

The AWS European Sovereign Cloud, set to launch by the end of 2025, will provide partners the capability to meet stringent operational autonomy and data residency requirements in highly regulated industries. The infrastructure for this cloud is wholly located within the European Union (EU) and operated independently from existing Regions.

2) Coordinate with AWS on service availability and capacity

When planning for your platform availability in a new Region, you should consider several points.

First, you should review your AWS service requirements against the list of AWS Services by Region and your generative AI model requirements against the model support by AWS Region in HAQM Bedrock. New Regions launch with a core set of services (listed in Services under Benefits) essential for most workloads, providing a solid foundation for deployment. After launch, we continue to make additional services available based on demand, improving parity between Regions.

Secondly, you should determine dependencies on third-party platforms and APIs by other partners, which might need to be available in the Region first before you can deploy your platforms.

If you have multiple platforms, you should determine an order in which you will make them available, guided by customer demand.

Based on these, we can work with you on a timeline to make your platforms available in the Region. Where there is a dependency on an AWS service or an AWS Partner platform that is unavailable, or there is a large capacity requirement, you should engage early with your AWS account teams so we can capture demand and provide guidance.

For services that are not yet available in a Region, you can consider temporary architectural workarounds or alternative services that provide similar functionality. This might include using cross-Region access where appropriate and compliant, while planning for progressive enhancement as services become available in the Region.

3) Design a flexible platform architecture

Partners typically architect their platforms to be multi-tenant SaaS for agility and operational efficiency. In a SaaS model, a platform has a control plane and an application plane. The control plane is for tasks such as tenant management and onboarding new customers, and it usually contains only metadata rather than actual customer data. The application plane is where the customer data is stored and processed. The following diagram shows this multi-tenant SaaS model.

Figure 1. Diagram showing a multi-tenant SaaS model

You might have architected your control plane to be centralized, while the application plane might be deployed in a Region based on the customer’s data residency requirements. The control plane might be global, for example, in a US Region, or it might be Regional, for example, in an EU Region. As long as the control plane doesn’t store actual customer data and is limited to metadata related to the deployment, this might satisfy the requirements of most customers. However, in highly regulated industries, there might be a requirement to have a sovereign control plane, deployed in the Region where customer data is. The choice of architecture depends on regulatory requirements, customer needs, and industry standards.

Another important design consideration in a SaaS model is tenant isolation. There are multiple ways in which this can be achieved: the silo model, pool model, and bridge model. The silo model is where each tenant is running a fully siloed stack of resources. In the pool model, tenants use infrastructure that is shared by all tenants. The bridge model is a mix of the silo and pool models.

The silo model might be required by highly regulated customers, whereas the pool model offers efficiency and optimization. Within the silo model there are also different ways in which isolation is realized, ranging from having separate AWS accounts to separate HAQM Virtual Private Clouds (VPCs) to separate subnets. Combining all of these, tier-based isolation offers different types of isolation to different tenants with different profiles, enabling flexibility in meeting unique requirements.

Tenant Onboarding Best Practices in SaaS covers how to manage tenant onboarding in a tier-based model. Additionally, a cell-based deployment model can help tackle the complexities arising from this.

To assist partners in navigating these architectural decisions and implementing flexible, compliant solutions, AWS offers the SaaS Factory Program. The program helps partners at any stage of their journey, whether you want to build new offerings, migrate existing applications, or optimize SaaS platforms on AWS.

Besides a SaaS delivery model, you can consider other delivery methods such as an HAQM Machine Image or a container image through HAQM Marketplace that can help you enter a market quicker until you make a SaaS version available. These can also make it easier to deploy on a Local Zone or Outposts.

4) Manage cross-Region communication effectively

As SaaS providers expand globally, cross-Region communication requires special attention. This stems from two critical challenges: balancing the need to comply with data residency requirements while delivering a consistent, high-performance experience to all their users.

When designing cross-Region communication strategies, providers need to consider multiple aspects of their architecture:

• How different components of their SaaS platform communicate across Regions, particularly between control planes and application planes.
• How to implement data replication and backup strategies that respect Regional boundaries.
• How to efficiently interact with external systems across different geographic jurisdictions.

Understanding AWS service scope is crucial for effective cross-Region architecture. AWS services operate at three different levels: zonal services within specific Availability Zones, Regional services within an AWS Region, and global services that work across multiple Regions. For example, HAQM Elastic Compute Cloud (HAQM EC2) is zonal, HAQM Simple Storage Service (HAQM S3) is Regional, and HAQM CloudFront is global. This understanding helps architects make informed decisions about service placement and cross-Region communication patterns.

Communications within the SaaS platform

These communications typically fall into two categories: platform management and tenant-related operations, and require careful consideration regarding tenant data handling.

When using a centralized control plane architecture, cross-Region communication becomes essential for tenant management operations. The control plane needs to interact with application planes across Regions for tasks such as tenant provisioning, configuration management, and health monitoring. These interactions usually involve metadata rather than tenant data, allowing for optimization through services such as AWS Global Accelerator and HAQM CloudFront.

For SaaS platforms handling tenant data, cross-Region communication must respect data residency requirements. This means keeping tenant data processing within its designated Region and limiting cross-Region data transfer to essential operations only. Providers must implement strict controls on when and how tenant data can cross Regional boundaries. For example, an EU tenant’s data should typically be processed and stored within EU Regions, with cross-Region communication limited to necessary metadata exchanges with the control plane.

Cross-Region replication and backups

While maintaining data sovereignty, SaaS providers must also provide data durability, service continuity, and disaster recovery capabilities. This often involves cross-Region replication and backups, which must be designed to comply with data residency requirements. AWS offers several services that inherently provide cross-Region replication such as HAQM Aurora Global Database, HAQM DynamoDB, and HAQM S3 Cross-Region Replication (CRR). A further list of services that provide multi-Region capabilities can be found at AWS Multi-Region Capabilities.

Interactions with external systems

SaaS platforms often need to interact with third-party APIs or external services, which can be located in different geographic jurisdictions. To maintain performance and compliance:

• Implement Regional API gateways to manage external API calls. For example, an EU tenant’s data should interact with a payment processor’s EU endpoint through an API Gateway deployed in an EU Region rather than routing through US Regions.
• Use AWS PrivateLink for secure, private connectivity to third-party services. For customer network connectivity, consider options like AWS Direct Connect for dedicated private connections, AWS Site-to-Site VPN for encrypted internet connections, AWS Transit Gateway for centralized network management, or VPC Peering for direct VPC-to-VPC communication.
• Make sure data transformations or anonymization occur before cross-Region transfers when necessary.

Performance considerations

Performance in cross-Region SaaS deployments has to take into account tenant-specific needs. We recommend focusing on these best practices:

• Adopt network traffic routing strategies that are tenant-aware, directing users to the appropriate Regional deployment based on their requirements.
• Wherever possible, process tenant data within their designated Regions to maintain compliance and optimize performance. Be aware that metadata can also contain data that has data residency requirements.
• Implement efficient metadata caching to minimize unnecessary cross-Region calls to the control plane.
• Establish comprehensive monitoring of tenant-specific metrics to make sure you’re meeting performance requirements and SLAs across Regions.

For further guidance on building multi-Region SaaS architectures, refer to Architecting Multi-Region SaaS Solutions on AWS.

5) Implement security and encryption consistently

When expanding a SaaS platform across Regions, security architecture can become increasingly complex. Let’s explore how to maintain a robust security posture while managing multi-Region deployments effectively.

A well-structured identity and access management (IAM) strategy is crucial for multi-Region SaaS operations. AWS Control Tower and landing zone provide a foundation for multi-account governance that’s particularly valuable when expanding globally. For instance, you might set up separate accounts for development, staging, and production environments in each Region, with additional isolation for security, audit, logging, and compliance-sensitive workloads. Using AWS Organizations with service control policies (SCPs), you can enforce security boundaries not just across Regions but also across these functional accounts. This multi-account strategy, combined with landing zone’s automated account provisioning and guardrails, helps maintain consistent security controls as you scale. For centralized access management, AWS IAM Identity Center integrates with this structure to provide streamlined user access while maintaining security. For example, you could enforce multi-factor authentication (MFA) for all administrative access and implement automatic permission revocation for inactive users across all accounts and Regions.

The following diagram illustrates a multi-account organization structure.

Figure 2. Diagram showing a multi-account organization structure

When designing your network architecture, you need to carefully consider cross-Region connectivity. Rather than managing multiple disconnected VPCs, you can use AWS Transit Gateway with inter-Region peering to create a global network architecture. This means you can maintain consistent security controls while meeting data locality requirements. You might configure route tables so that tenant data is processed only in local Regional services, while allowing global administrative access through the control plane.

AWS provides multiple encryption options to meet varying compliance requirements. Although AWS Key Management Services (AWS KMS) with Regional keys works for most scenarios, highly regulated industries might require additional controls. For these cases, consider using the external key store feature, which allows encryption keys to be stored outside of AWS while still integrating with AWS services. You can also implement multi-Region encryption keys for scenarios requiring cross-Region data replication while maintaining strict control over key management.

Each geographical region might have unique security requirements. We recommend implementing Regional AWS WAF rules aligned with local requirements, enabling HAQM GuardDuty in each Region with centralized monitoring, and using AWS Security Hub for aggregated security posture management and AWS Config for tracking resource compliance across Regions.

In a multi-Region SaaS environment, implementing least privilege becomes more nuanced. Create a hierarchical permission structure that considers global administrative access for platform operations, Regional administrative access for local operations, tenant-specific access scoped to specific Regions, and service-to-service communications within and across Regions.

Managing certificates across Regions requires careful planning. AWS Certificate Manager (ACM) provides Regional certificates, but you’ll need to automate certificate renewal processes across Regions, implement monitoring for certificate expiration, maintain consistency in domain validation, and consider using AWS Private Certificate Authority for internal service communications.

For instance, a healthcare SaaS provider might use:

• Regional AWS KMS keys for standard tenant data encryption
• External key store for specific customers requiring full key ownership
• AWS Certificate Manager for managing Regional SSL or TLS certificates
• AWS Private Certificate Authority for internal service communication

The following diagram shows the architecture for a Landing Zone Accelerator on AWS solution for healthcare.

Figure 3. Diagram showing the architecture for a Landing Zone Accelerator on AWS solution for healthcare

In another example, a financial SaaS platform might implement Regional boundaries where tenant data access is restricted to specific Regions through a combination of AWS Identity and Access Management (IAM) policies, resource tags, and networking controls. Administrative access can be granted through AWS IAM Identity Center with step-up authentication required for cross-Region operations.

6) Navigate compliance requirements and automate evidence collection

In expanding to a new country, partners need to be aware of compliance requirements and make sure their platforms and operations meet those requirements. Meeting these is a shared responsibility between AWS, partners, and customers. For information about our offerings and certifications, visit AWS Compliance. For security and compliance reports, visit AWS Artifact.

The Global Security & Compliance Acceleration on AWS Program (GSCA) can advise you on requirements that apply to a certain country and industry. The program can also recommend partners that can help you navigate and implement the necessary changes.

AWS has local account teams, including solutions architects and security specialists, who have deep expertise and experience in working with customers in regulated industries and can share practical knowledge to help partners.

We recommend you integrate sovereignty controls and compliance checks directly into your development pipeline rather than treating them as post-deployment considerations. Using features such as AWS Config rules, AWS CloudFormation Guard, and custom controls in AWS Control Tower, you can automate compliance validation throughout the development lifecycle. This enables you to meet requirements from the earliest stages of development, reducing the risk of noncompliance and eliminating costly remediation efforts.

We also suggest automating evidence collection using services such as AWS Config, AWS Security Hub, AWS License Manager, AWS Artifact, AWS Control Tower, and AWS CloudTrail, and using AWS Audit Manager to continually audit AWS usage to make risk management and compliance with regulations more efficient. This architecture is illustrated in the following diagram.

Figure 4. Diagram showing automated evidence collection

Conclusion

Expanding your SaaS platform to new geographical regions presents both opportunities and challenges. While this post has outlined critical technical considerations, you don’t have to navigate this journey alone. AWS provides comprehensive support through expertise from AWS solutions architects, funding programs, the AWS SaaS Factory program, and partner development specialists who understand local market needs.

Take the first step toward global expansion today. Contact your AWS account team to develop a customized expansion strategy or visit the AWS SaaS Factory program page.