• Tested AWS Bill of Materials by reference architecture size
• Available Infrastructure as Code for GitLab Cloud Native Hybrid
  • Two and Three Zone High Availability
  • Streamlined Performance Testing of AWS Quick Start Prepared GitLab Instances
  • AWS GovCloud Support for AWS Quick Start for GitLab CNH on EKS
• AWS PaaS qualified for all GitLab implementations
• GitLab Cloud Native Hybrid on AWS
  • 2K Cloud Native Hybrid on EKS
  • 3K Cloud Native Hybrid on EKS
  • 5K Cloud Native Hybrid on EKS
  • 10K Cloud Native Hybrid on EKS
  • 50K Cloud Native Hybrid on EKS
• Helpful Resources

Provision GitLab Cloud Native Hybrid on AWS EKS

GitLab “Cloud Native Hybrid” is a hybrid of the cloud native technology Kubernetes (EKS) and EC2. While as much of the GitLab application as possible runs in Kubernetes or on AWS services (PaaS), the GitLab service Gitaly must still be run on EC2. Gitaly is a layer designed to overcome limitations of the Git binaries in a horizontally scaled architecture. You can read more here about why Gitaly was built and why the limitations of Git mean that it must currently run on instance compute in Git Characteristics That Make Horizontal Scaling Difficult.

Amazon provides a managed Kubernetes service offering known as Amazon Elastic Kubernetes Service (EKS).

Tested AWS Bill of Materials by reference architecture size

*Cost calculations for actual implementations are a rough guideline with the following considerations:

• Actual choices about instance types should be based on GPT testing of your configuration.
• The first year of actual usage will reveal potential savings due to lower than expected usage, especially for ramping migrations where the full loading takes months, so be careful not to commit to savings plans too early or for too long.
• The cost estimates assume full scale of the Kubernetes cluster nodes 24 x 7 x 365. Savings due to ‘idling scale-in’ are not considered because they are highly dependent on the usage patterns of the specific implementation.
• Costs such as GitLab Runners, data egress and storage costs are not included as they are very dependent on the configuration of a specific implementation and on development behaviors (for example, frequency of committing or frequency of builds).
• These estimates will change over time as GitLab tests and optimizes compute choices.

Available Infrastructure as Code for GitLab Cloud Native Hybrid

The GitLab Environment Toolkit (GET) is an effort made by GitLab to create a multi-cloud, multi-GitLab (Linux package installation + Cloud Native Hybrid) toolkit to provision GitLab. GET is developed by GitLab developers and is open to community contributions. GET is where GitLab is investing its resources as the primary option for Infrastructure as Code, and is being actively used in production as a part of GitLab Dedicated.

For more information about the project, see GitLab Environment Toolkit.

The AWS Quick Start for GitLab Cloud Native Hybrid on EKS is developed by AWS, GitLab, and the community that contributes to AWS Quick Starts, whether directly to the GitLab Quick Start or to the underlying Quick Start dependencies GitLab inherits (for example, EKS Quick Start).

GET is recommended for most deployments. The AWS Quick Start can be used if the IaC language of choice is CloudFormation, integration with AWS services like Control Tower is desired, or preference for a UI-driven configuration experience or when any aspect in the below table is an overriding concern.

Two and Three Zone High Availability

While GitLab Reference Architectures generally encourage three zone redundancy, AWS Quick Starts and AWS Well Architected consider two zone redundancy as AWS Well Architected. Individual implementations should weigh the costs of two and three zone configurations against their own high availability requirements for a final configuration.

Gitaly Cluster uses a consistency voting system to implement strong consistency between synchronized nodes. Regardless of the number of availability zones implemented, there will always need to be a minimum of three Gitaly and three Praefect nodes in the cluster to avoid voting stalemates cause by an even number of nodes.

Streamlined Performance Testing of AWS Quick Start Prepared GitLab Instances

A set of performance testing instructions have been abbreviated for testing a GitLab instance prepared using the AWS Quick Start for GitLab Cloud Native Hybrid on EKS. They assume zero familiarity with GitLab Performance Tool. They can be accessed here: Performance Testing an Instance Prepared using AWS Quick Start for GitLab Cloud Native Hybrid on EKS.

AWS GovCloud Support for AWS Quick Start for GitLab CNH on EKS

The AWS Quick Start for GitLab Cloud Native Hybrid on EKS has been tested with GovCloud and works with the following restrictions and understandings.

• GovCloud does not have public Route53 hosted zones, so you must set the following parameters:

  CloudFormation Quick Start form field	CloudFormation Parameter	Setting
  Create Route 53 hosted zone	CreatedHostedZone	No
  Request AWS Certificate Manager SSL certificate	CreateSslCertificate	No

• The Quick Start creates public load balancer IPs, so that you can easily configure your local hosts file to get to the GUI for GitLab when deploying tests. However, you may need to manually alter this if public load balancers are not part of your provisioning plan. We are planning to make non-public load balancers a configuration option issue link: Short Term: Documentation and/or Automation for private GitLab instance with no internet Ingress
• As of 2021-08-19, AWS GovCloud has Graviton instances for Amazon RDS PostgreSQL available, but does not for ElastiCache Redis.
• It is challenging to get the Quick Start template to load in GovCloud from the Standard Quick Start URL, so the generic ones are provided here:
  • Launch for New VPC in us-gov-east-1
  • Launch for New VPC in us-gov-west-1

AWS PaaS qualified for all GitLab implementations

For both implementations that used the Linux package or Cloud Native Hybrid implementations, the following GitLab Service roles can be performed by AWS Services (PaaS). Any PaaS solutions that require preconfigured sizing based on the scale of your instance will also be listed in the per-instance size Bill of Materials lists. Those PaaS that do not require specific sizing, are not repeated in the BOM lists (for example, AWS Certification Manager).

These services have been tested with GitLab.

Some services, such as log aggregation, outbound email are not specified by GitLab, but where provided are noted.

GitLab Cloud Native Hybrid on AWS

2K Cloud Native Hybrid on EKS

2K Cloud Native Hybrid on EKS Bill of Materials (BOM)

GPT Test Results

• TBD

Deploy Now Deploy Now links leverage the AWS Quick Start automation and only pre-populate the number of instances and instance types for the Quick Start based on the Bill of Materials below. You must provide appropriate input for all other parameters by following the guidance in the Quick Start documentation’s Deployment steps section.

• Deploy Now: AWS Quick Start for 2 AZs
• Deploy Now: AWS Quick Start for 3 AZs

BOM Total: = Bill of Materials Total - this is what you use when building this configuration

Ref Arch Raw Total: = The totals if the configuration was built on regular VMs with no PaaS services. Configuring on pure VMs generally requires additional VMs for cluster management activities.

Idle Configuration (Scaled-In) = can be used to scale-in during time of low demand and/or for warm standby Geo instances. Requires configuration, testing and management of EKS autoscaling to meet your internal requirements.

3K Cloud Native Hybrid on EKS

3K Cloud Native Hybrid on EKS Bill of Materials (BOM)

GPT Test Results

• 3K Full Fixed Scale GPT Test Results

• 3K AutoScale from 25% GPT Test Results

  Elastic Auto Scale GPT Test Results start with an idle scaled cluster and then start the standard GPT test to determine if the EKS Auto Scaler performs well enough to keep up with performance test demands. In general this is substantially harder ramping than the scaling required when the ramping is driven by standard production workloads.

Deploy Now

Deploy Now links leverage the AWS Quick Start automation and only pre-populate the number of instances and instance types for the Quick Start based on the Bill of Materials below. You must provide appropriate input for all other parameters by following the guidance in the Quick Start documentation’s Deployment steps section.

• Deploy Now: AWS Quick Start for 2 AZs
• Deploy Now: AWS Quick Start for 3 AZs

BOM Total: = Bill of Materials Total - this is what you use when building this configuration

Ref Arch Raw Total: = The totals if the configuration was built on regular VMs with no PaaS services. Configuring on pure VMs generally requires additional VMs for cluster management activities.

Idle Configuration (Scaled-In) = can be used to scale-in during time of low demand and/or for warm standby Geo instances. Requires configuration, testing and management of EKS autoscaling to meet your internal requirements.

Other combinations of node type and quantity can be used to meet the Grand Total. Due to the properties of pods, hosts that are overly small may have significant unused capacity.

5K Cloud Native Hybrid on EKS

5K Cloud Native Hybrid on EKS Bill of Materials (BOM)

GPT Test Results

• 5K Full Fixed Scale GPT Test Results

• 5K AutoScale from 25% GPT Test Results

  Elastic Auto Scale GPT Test Results start with an idle scaled cluster and then start the standard GPT test to determine if the EKS Auto Scaler performs well enough to keep up with performance test demands. In general this is substantially harder ramping than the scaling required when the ramping is driven by standard production workloads.

Deploy Now

Deploy Now links leverage the AWS Quick Start automation and only prepopulate the number of instances and instance types for the Quick Start based on the Bill of Materials below. You must provide appropriate input for all other parameters by following the guidance in the Quick Start documentation’s Deployment steps section.

• Deploy Now: AWS Quick Start for 2 AZs
• Deploy Now: AWS Quick Start for 3 AZs

BOM Total: = Bill of Materials Total - this is what you use when building this configuration

Ref Arch Raw Total: = The totals if the configuration was built on regular VMs with no PaaS services. Configuring on pure VMs generally requires additional VMs for cluster management activities.

Idle Configuration (Scaled-In) = can be used to scale-in during time of low demand and/or for warm standby Geo instances. Requires configuration, testing and management of EKS autoscaling to meet your internal requirements.

Other combinations of node type and quantity can be used to meet the Grand Total. Due to the CPU and memory requirements of pods, hosts that are overly small may have significant unused capacity.

10K Cloud Native Hybrid on EKS

10K Cloud Native Hybrid on EKS Bill of Materials (BOM)

GPT Test Results

• 10K Full Fixed Scale GPT Test Results

• 10K Elastic Auto Scale GPT Test Results

  Elastic Auto Scale GPT Test Results start with an idle scaled cluster and then start the standard GPT test to determine if the EKS Auto Scaler performs well enough to keep up with performance test demands. In general this is substantially harder ramping than the scaling required when the ramping is driven by standard production workloads.

Deploy Now

Deploy Now links leverage the AWS Quick Start automation and only prepopulate the number of instances and instance types for the Quick Start based on the Bill of Materials below. You must provide appropriate input for all other parameters by following the guidance in the Quick Start documentation’s Deployment steps section.

• Deploy Now: AWS Quick Start for 3 AZs

BOM Total: = Bill of Materials Total - this is what you use when building this configuration

Ref Arch Raw Total: = The totals if the configuration was built on regular VMs with no PaaS services. Configuring on pure VMs generally requires additional VMs for cluster management activities.

Idle Configuration (Scaled-In) = can be used to scale-in during time of low demand and/or for warm standby Geo instances. Requires configuration, testing and management of EKS autoscaling to meet your internal requirements.

Other combinations of node type and quantity can be used to meet the Grand Total. Due to the CPU and memory requirements of pods, hosts that are overly small may have significant unused capacity.

50K Cloud Native Hybrid on EKS

50K Cloud Native Hybrid on EKS Bill of Materials (BOM)

GPT Test Results

• 50K Full Fixed Scale GPT Test Results

• 50K Elastic Auto Scale GPT Test Results

  Elastic Auto Scale GPT Test Results start with an idle scaled cluster and then start the standard GPT test to determine if the EKS Auto Scaler performs well enough to keep up with performance test demands. In general this is substantially harder ramping than the scaling required when the ramping is driven by standard production workloads.

Deploy Now

Deploy Now links leverage the AWS Quick Start automation and only prepopulate the number of instances and instance types for the Quick Start based on the Bill of Materials below. You must provide appropriate input for all other parameters by following the guidance in the Quick Start documentation’s Deployment steps section.

• Deploy Now: AWS Quick Start for 3 AZs - 1/4 Scale EKS

BOM Total: = Bill of Materials Total - this is what you use when building this configuration

Ref Arch Raw Total: = The totals if the configuration was built on regular VMs with no PaaS services. Configuring on pure VMs generally requires additional VMs for cluster management activities.

Idle Configuration (Scaled-In) = can be used to scale-in during time of low demand and/or for warm standby Geo instances. Requires configuration, testing and management of EKS autoscaling to meet your internal requirements.

Other combinations of node type and quantity can be used to meet the Grand Total. Due to the CPU and memory requirements of pods, hosts that are overly small may have significant unused capacity.

Helpful Resources

• Architecting Kubernetes clusters — choosing a worker node size