Data residency and high availability
- Tier: Ultimate
- Offering: GitLab Dedicated
GitLab Dedicated provides data residency control and high availability capabilities through your choice of AWS regions. You control where your data is stored and processed, enabling you to meet regulatory requirements while maintaining enterprise-grade uptime.
Your GitLab Dedicated environment runs in a dedicated AWS account, completely isolated from other tenants and GitLab.com. This single-tenant architecture gives you full control over data location while GitLab manages the underlying infrastructure and ensures high availability through proven reference architectures.
GitLab Dedicated uses a modified version of the Cloud Native Hybrid reference architecture with high availability. Within your selected region, GitLab distributes your infrastructure across multiple availability zones for redundancy. During onboarding, you can let GitLab automatically select availability zones (recommended), or specify custom availability zone IDs to align with your existing AWS infrastructure.
GitLab Dedicated uses additional cloud provider services beyond the standard reference architectures to enhance security and stability. As a result, costs for GitLab Dedicated differ from standard reference architecture costs.
Region selection
When you create your GitLab Dedicated instance, you select AWS regions for your primary deployment, disaster recovery, and backups. Your region choices control where your data lives, how you meet compliance requirements, and how you protect against regional outages.
- Primary region
- Your main deployment where your instance runs and users access GitLab. This is where your data is stored and must meet your data residency requirements.
- Secondary region
- An optional AWS region for Geo-based disaster recovery. If your primary region becomes unavailable, you can fail over to your secondary region.
- Backup region
- An optional AWS region where backups are replicated for additional redundancy. This can be the same as your primary or secondary region, or a different region for increased redundancy.
Consider these factors when selecting regions:
Data residency and compliance: Your primary region is where your data is stored. Choose regions that meet your regulatory requirements. For example, GDPR compliance may require data to remain in the EU, while HIPAA compliance may require specific AWS regions.
High availability and disaster recovery: Select secondary and backup regions to protect against regional outages. If your primary region becomes unavailable, you can fail over to your secondary region.
Feature availability: Some GitLab Dedicated features like ClickHouse Cloud and AWS SES are only available in specific regions.
Performance and latency: Select regions geographically close to your users and infrastructure to minimize latency and improve performance.
Sustainability: If your organization has sustainability commitments, you can consider the carbon emissions of different regions. For low-emission region guidance, see how to choose a region based on both business requirements and sustainability goals.
Regions with limitations are clearly marked, and you must acknowledge the associated risks before selecting them.
Supported regions
The following table shows all AWS regions supported by GitLab Dedicated. Any region in this table can be used as your primary, secondary, or backup region.
AWS hosts global identity and access management (IAM) services in the us-east-1 region.
An outage in us-east-1 prevents GitLab from performing operations on tenants, including failover to secondary regions.
Tenants with us-east-1 as their primary region experience downtime that GitLab cannot mitigate during an outage.
Consider selecting a different primary region to reduce this risk.
You can deploy your instance in the following AWS regions:
| Region | Code | ClickHouse Cloud | AWS SES |
|---|---|---|---|
| Africa (Cape Town) | af-south-1 | Yes | Yes |
| Asia Pacific (Hyderabad) | ap-south-2 | No | Yes |
| Asia Pacific (Jakarta) | ap-southeast-3 | No | Yes |
| Asia Pacific (Melbourne) | ap-southeast-4 | No | No |
| Asia Pacific (Mumbai) | ap-south-1 | Yes | Yes |
| Asia Pacific (Osaka) | ap-northeast-3 | No | Yes |
| Asia Pacific (Seoul) | ap-northeast-2 | Yes | Yes |
| Asia Pacific (Singapore) | ap-southeast-1 | Yes | Yes |
| Asia Pacific (Sydney) | ap-southeast-2 | Yes | Yes |
| Asia Pacific (Tokyo) | ap-northeast-1 | Yes | Yes |
| Asia Pacific (Hong Kong) | ap-east-1 | No | No |
| Canada (Central) | ca-central-1 | Yes | Yes |
| Europe (Frankfurt) | eu-central-1 | Yes | Yes |
| Europe (Ireland) | eu-west-1 | Yes | Yes |
| Europe (London) | eu-west-2 | Yes | Yes |
| Europe (Milan) | eu-south-1 | No | Yes |
| Europe (Spain) | eu-south-2 | No | No |
| Europe (Paris) | eu-west-3 | No | Yes |
| Europe (Stockholm) | eu-north-1 | Yes | Yes |
| Europe (Zurich) | eu-central-2 | No | Yes |
| Israel (Tel Aviv) | il-central-1 | No | Yes |
| Middle East (UAE) | me-central-1 | No | No |
| Middle East (Bahrain) | me-south-1 | No | Yes |
| South America (São Paulo) | sa-east-1 | Yes | Yes |
| US East (N. Virginia) | us-east-1 | Yes | Yes |
| US East (Ohio) | us-east-2 | Yes | Yes |
| US West (N. California) | us-west-1 | No | Yes |
| US West (Oregon) | us-west-2 | Yes | Yes |
If you need a region that is not listed, contact your account representative or GitLab Support.
ClickHouse Cloud
Advanced analytical features are only available in regions that support ClickHouse Cloud. Check the supported regions table for ClickHouse availability.
What’s included:
- A ClickHouse Cloud database deployed in your tenant’s primary region
- AWS PrivateLink connectivity (not publicly accessible)
- Data encrypted in transit and at rest using AES 256 keys and transparent data encryption
- Automatic endpoint allowlisting when you filter outbound requests
Limitations:
- Customer-managed encryption keys are not supported.
- No SLAs apply. Recovery time objective (RTO) and recovery point objective (RPO) are best efforts.
AWS SES
AWS Simple Email Service (SES) is used to send emails from your GitLab instance. Check the supported regions table for SES availability in each region.
For regions without AWS SES support, you must set up an external SMTP mail service.