Data residency and high availability
- Tier: Ultimate
- Offering: GitLab Dedicated
GitLab Dedicated offers enterprise-grade infrastructure and performance in a secure and reliable deployment.
Data residency
During onboarding, you select the AWS region for your instance deployment and data storage.
Some AWS regions have limited features and may not be available for production instances.
Available AWS regions
GitLab Dedicated is available in select AWS regions that meet specific requirements, including support for io2 volumes.
The following regions are verified for use:
| Region | Code |
|---|---|
| Asia Pacific (Mumbai) | ap-south-1 |
| Asia Pacific (Seoul) | ap-northeast-2 |
| Asia Pacific (Singapore) | ap-southeast-1 |
| Asia Pacific (Sydney) | ap-southeast-2 |
| Asia Pacific (Tokyo) | ap-northeast-1 |
| Canada (Central) | ca-central-1 |
| Europe (Frankfurt) | eu-central-1 |
| Europe (Ireland) | eu-west-1 |
| Europe (London) | eu-west-2 |
| Europe (Stockholm) | eu-north-1 |
| US East (Ohio) | us-east-2 |
| US East (N. Virginia) | us-east-1 |
| US West (N. California) | us-west-1 |
| US West (Oregon) | us-west-2 |
| Middle East (Bahrain) | me-south-1 |
For more information about selecting low emission regions, see Choose Region based on both business requirements and sustainability goals.
If you’re interested in a region not listed here, contact your account representative or GitLab Support to inquire about availability.
Secondary regions with limited support
When setting up GitLab Dedicated, you select a secondary region to host a failover instance for disaster recovery. Some AWS regions are available only as secondary regions because they do not fully support certain AWS features that GitLab Dedicated relies on. If GitLab initiates a failover to your secondary region during a disaster recovery event or test, these limitations may impact available features.
The following regions are verified for use as a secondary region but with known limitations:
| Region | Code | io2 volume support | AWS SES support |
|---|---|---|---|
| Africa (Cape Town) | af-south-1 | No | Yes |
| Asia Pacific (Hong Kong) | ap-east-1 | Yes | No |
| Asia Pacific (Osaka) | ap-northeast-3 | No | Yes |
| Asia Pacific (Hyderabad) | ap-south-2 | No | No |
| Asia Pacific (Jakarta) | ap-southeast-3 | No | Yes |
| Asia Pacific (Melbourne) | ap-southeast-4 | No | No |
| Asia Pacific (Malaysia) | ap-southeast-5 | No | No |
| Asia Pacific (Thailand) | ap-southeast-7 | No | No |
| Canada West (Calgary) | ca-west-1 | No | No |
| Europe (Zurich) | eu-central-2 | No | No |
| Europe (Milan) | eu-south-1 | No | Yes |
| Europe (Spain) | eu-south-2 | No | No |
| Europe (Paris) | eu-west-3 | No | Yes |
| Israel (Tel Aviv) | il-central-1 | No | Yes |
| Middle East (UAE) | me-central-1 | No | No |
| Mexico (Central) | mx-central-1 | No | No |
| South America (São Paulo) | sa-east-1 | No | Yes |
These limitations may affect your service in the following ways:
No io2 volume support: Regions without io2 volume support use gp3 volumes instead, which offer lower data durability (99.8-99.9% compared to 99.999% for io2), potentially longer RTO and RPO recovery times, and may affect failover capabilities if rebuilding is necessary.
No SES support: Regions without AWS Simple Email Service (SES) support cannot send email notifications using the default configuration. To maintain email functionality in these regions, you must set up your own external SMTP mail service.
During onboarding, regions with these limitations are clearly marked. You must acknowledge the associated risks before selecting one as your secondary region.
Data isolation
As a single-tenant SaaS solution, GitLab Dedicated provides infrastructure-level isolation:
- Your environment is in an AWS account that is separate from other tenants.
- All necessary infrastructure required to host the GitLab application is contained in the account.
- Your data remains within the account boundary.
- Tenant environments are isolated from GitLab.com.
You administer the application while GitLab manages the underlying infrastructure.
Availability and scalability
GitLab Dedicated uses modified versions of the Cloud Native Hybrid reference architectures with high availability.
During onboarding, GitLab matches you to the closest reference architecture size based on the number of users.
While the reference architectures serve as a foundation for GitLab Dedicated environments, they are not exhaustive. Additional cloud provider services beyond the standard reference architectures are used to enhance security and stability. As a result, GitLab Dedicated costs differ from standard reference architecture costs.
For more information, see the Current Service Level Objective.
Disaster recovery
During onboarding, you specify a secondary AWS region for data storage and recovery. Regular backups of all GitLab Dedicated datastores (including databases and Git repositories) are taken, tested, and stored in your chosen secondary region.
Some secondary regions have limited support for AWS features. These limitations may affect disaster recovery time frames and certain features in your failover instance.
You can also opt to store backup copies in a separate cloud region for increased redundancy.
For more information, including Recovery Point Objective (RPO) and Recovery Time Objective (RTO) targets, see the disaster recovery plan.
Docs
Edit this page to fix an error or add an improvement in a merge request.
Create an issue to suggest an improvement to this page.
Product
Create an issue if there's something you don't like about this feature.
Propose functionality by submitting a feature request.
Feature availability and product trials
View pricing to see all GitLab tiers and features, or to upgrade.
Try GitLab for free with access to all features for 30 days.
Get help
If you didn't find what you were looking for, search the docs.
If you want help with something specific and could use community support, post on the GitLab forum.
For problems setting up or using this feature (depending on your GitLab subscription).
Request support
