diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2023-12-08 18:12:48 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2023-12-08 18:12:48 +0300 |
commit | f1ce233e6ab6535afef76f10528e104672426710 (patch) | |
tree | 92d9654ae87bf5190db61b8a8736a77680e73a6c /doc/solutions/cloud | |
parent | 249dfd13795b1912f3033c729198f4fdf169920e (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/solutions/cloud')
-rw-r--r-- | doc/solutions/cloud/aws/gitlab_aws_integration.md | 62 | ||||
-rw-r--r-- | doc/solutions/cloud/aws/gitlab_aws_partner_designations.md | 4 | ||||
-rw-r--r-- | doc/solutions/cloud/aws/gitlab_instance_on_aws.md | 53 | ||||
-rw-r--r-- | doc/solutions/cloud/aws/index.md | 46 |
4 files changed, 99 insertions, 66 deletions
diff --git a/doc/solutions/cloud/aws/gitlab_aws_integration.md b/doc/solutions/cloud/aws/gitlab_aws_integration.md index 0a2d5772a56..11add88f7c0 100644 --- a/doc/solutions/cloud/aws/gitlab_aws_integration.md +++ b/doc/solutions/cloud/aws/gitlab_aws_integration.md @@ -11,6 +11,8 @@ Learn how to integrate GitLab and AWS. This content is intended for GitLab team members as well as members of the wider community. +When content that is badged for GitLab SaaS ( **(SAAS)** ) or Self-Managed ( **(SELF)** ) it means that the link applies to only that type of GitLab instance implementation. Unbadged content works for any type of GitLab implementation. + This page attempts to index the ways in which GitLab can integrate with AWS. It does so whether the integration is the result of configuring general functionality, was built in to AWS or GitLab or is provided as a solution. | Text Tag | Configuration / Built / Solution | Support/Maintenance | @@ -21,10 +23,16 @@ This page attempts to index the ways in which GitLab can integrate with AWS. It | `[GitLab Built]` | Built into GitLab by Product Team to Address AWS Integration | GitLab | | `[AWS Solution]` | Built as Solution Example by AWS or AWS Partners | Community/Example | | `[GitLab Solution]` | Built as Solution Example by GitLab or GitLab Partners | Community/Example | -| `[CI Solution]` | Built, at least in part, using GitLab CI and therefore <br />more customer customizable. | Items tagged `[CI Solution will]` <br />also carry one of the other tags <br />that indicates the maintenance status. | +| `[CI Solution]` | Built, at least in part, using GitLab CI and therefore <br />more customer customizable. | Items tagged `[CI Solution]` will <br />also carry one of the other tags <br />that indicate the maintenance status. | + +## Table of Contents + +[TOC] ## Integrations For Development Activities +These integrations have to do with using GitLab to build application workloads and deploy them to AWS. + ### SCM Integrations - **AWS CodeStar Connections** - enables SCM connections to multiple AWS Services. **Currently for GitLab.com SaaS only**. [Configure GitLab](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-create-gitlab.html). [Supported Providers](https://docs.aws.amazon.com/dtconsole/latest/userguide/supported-versions-connections.html). [Supported AWS Services](https://docs.aws.amazon.com/dtconsole/latest/userguide/integrations-connections.html) - each one may have to make updates to support GitLab, so here is the subset that currently support GitLab `[AWS Built]` @@ -51,53 +59,77 @@ This page attempts to index the ways in which GitLab can integrate with AWS. It - **AWS CodeDeploy Integration** - indirectly through CodePipeline support. `[AWS Built]` - [Integrate EKS clusters for application deployment](../../../user/infrastructure/clusters/connect/new_eks_cluster.md). `[GitLab Built]` -## Solutions For Specific Development Frameworks and Ecosystems +## End-to-End Solutions for development and deployment if specific development frameworks and ecosystems Generally solutions demonstrate end-to-end capabilities for the development framework - leveraging all relevant integration techniques to show the art of maximum value for using GitLab and AWS together. -### Serverless Development +### Serverless -- [Serverless Framework Deployment to AWS with GitLab Serverless SAST Scanning and Managed DevOps Environments](https://gitlab.com/guided-explorations/aws/serverless/serverless-framework-aws) - working example code and tutorials. `[GitLab Solution]` `[CI Solution]` +- [Serverless Framework Deployment to AWS with GitLab Serverless SAST Scanning and Lifecycle Managed DevOps Environments](https://gitlab.com/guided-explorations/aws/serverless/serverless-framework-aws) - working example code and tutorials. `[GitLab Solution]` `[CI Solution]` - [Tutorial: Serverless Framework Deployment to AWS with GitLab Serverless SAST Scanning](https://gitlab.com/guided-explorations/aws/serverless/serverless-framework-aws/-/blob/master/TUTORIAL.md) `[GitLab Solution]` `[CI Solution]` - [Tutorial: Secure Serverless Framework Development with GitLab Security Policy Approval Rules and Managed DevOps Environments](https://gitlab.com/guided-explorations/aws/serverless/serverless-framework-aws/-/blob/master/TUTORIAL2-SecurityAndManagedEnvs.md) `[GitLab Solution]` `[CI Solution]` -### Infrastructure as Code +### Terraform -- [Terraform Deployment to AWS with GitLab MR Managed DevOps Environments](https://gitlab.com/guided-explorations/aws/terraform/terraform-web-server-cluster) +- [Terraform Deployment to AWS with GitLab Lifecycle Managed DevOps Environments](https://gitlab.com/guided-explorations/aws/terraform/terraform-web-server-cluster) - [Tutorial: Terraform Deployment to AWS with GitLab IaC SAST Scanning](https://gitlab.com/guided-explorations/aws/terraform/terraform-web-server-cluster/-/blob/prod/TUTORIAL.md) `[GitLab Solution]` `[CI Solution]` - [Terraform Deployment to AWS with GitLab Security Policy Approval Rules and Managed DevOps Environments](https://gitlab.com/guided-explorations/aws/terraform/terraform-web-server-cluster/-/blob/prod/TUTORIAL2-SecurityAndManagedEnvs.md) `[GitLab Solution]` `[CI Solution]` -- [Tutorial: CloudFormation Deployment With GitLab MR Managed DevOps Environments](https://gitlab.com/guided-explorations/aws/cloudformation-deploy) `[GitLab Solution]` `[CI Solution]` -### .Net on AWS +#### CloudFormation + +[CloudFormation Development and Deployment With GitLab Lifecycle Managed DevOps Environments Working Code](https://gitlab.com/guided-explorations/aws/cloudformation-deploy) `[GitLab Solution]` `[CI Solution]` + +### CDK + +- [Building Cross-Account Deployment in GitLab Pipelines Using AWS CDK](https://aws.amazon.com/blogs/apn/building-cross-account-deployment-in-gitlab-pipelines-using-aws-cdk/) `[AWS Solution]` `[CI Solution]` + +### .NET on AWS - [Working Example Code for Scaling .NET Framework 4.x Runners on AWS](https://gitlab.com/guided-explorations/aws/dotnet-aws-toolkit) `[GitLab Solution]` `[CI Solution]` -- [Video Walkthrough of Code and Building a .NET Framework 4.x Project](https://www.youtube.com/watch?v=_4r79ZLmDuo) `[GitLab Solution]` `[CI Solution]` +- [Video Walkthrough of Code and Building a .NET Framework 4.x Project](https://www.youtube.com/watch?v=_4r79ZLmDuo) `[GitLab Solution]` `[CI Solution]` -## Authentication Integration +## System to system integration of GitLab and AWS + +AWS Identity providers (IDP) can be configured to authenticate into GitLab or GitLab can function as an IDP into AWS accounts. + +Top level groups on GitLab.com are also known as "Namespaces" and naming one after your company is the first step to setting up a tenant for your organization on GitLab.com. Namespaces can be configured for special functionality like SSO which then integrates your IDP into GitLab. + +### User authentication and authorization between GitLab and AWS + +- [SAML SSO for GitLab.com groups](../../../user/group/saml_sso/index.md) `[GitLab Configuration]` **(SAAS)** +- [Integrate LDAP with GitLab](../../../administration/auth/ldap/index.md) `[GitLab Configuration]` **(SELF)** + +### Runner workload authentication and authorization integration - [Runner Job Authentication using Open ID & JWT Authentication](../../../ci/cloud_services/aws/index.md). `[GitLab Built]` - [Configure OpenID Connect between GitLab and AWS](https://gitlab.com/guided-explorations/aws/configure-openid-connect-in-aws) `[GitLab Solution]` `[CI Solution]` - [OIDC and Multi-Account Deployment with GitLab and ECS](https://gitlab.com/guided-explorations/aws/oidc-and-multi-account-deployment-with-ecs) `[GitLab Solution]` `[CI Solution]` -## GitLab Instance Compute & Operations Integration +## GitLab infrastructure workloads deployed on AWS + +While GitLab can be deployed on a single box for up to 500 users, when it is horizontally scaled for very large user counts like 50,000 it expands into being a complex, many tiered platform that benefits from deployment to AWS. GitLab is supports and is regularly tested being backed by AWS services. GitLab is deployable to Ec2 for traditional scaling and to AWS EKS in a Cloud Native Hybrid implementation. It is called Hybrid because specific service layers cannot be placed in a container cluster due to the workload shapes that are common to Git (and common to how Git processes behave handles that workload variety). + +### GitLab Instance Compute & Operations Integration - Installing GitLab Self-Managed on AWS + - [AWS Services that can be used when deploying GitLab](gitlab_instance_on_aws.md) - GitLab Single EC2 Instance. `[GitLab Built]` - [Using 5 Seat AWS marketplace subscription](gitlab_single_box_on_aws.md#marketplace-subscription) - [Using Prepared AMIs](gitlab_single_box_on_aws.md#official-gitlab-releases-as-amis) - Bring Your Own License for Enterprise Edition. - GitLab Cloud Native Hybrid Scaled on AWS EKS and Paas. `[GitLab Built]` - - Using GitLab Environment Toolkit (GET) - `[GitLab Solution]` + - [Using GitLab Environment Toolkit (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) - `[GitLab Solution]` - GitLab Instance Scaled on AWS EC2 and PaaS. `[GitLab Built]` - - Using GitLab Environment Toolkit (GET) - `[GitLab Solution]` + - [Using GitLab Environment Toolkit (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) - `[GitLab Solution]` - [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/gitlab-AMG-datasource.html) for GitLab self-managed Prometheus metrics. `[AWS Built]` -## GitLab Runner on AWS Compute +### GitLab Runner on AWS Compute +- [GitLab Runner Autoscaler](https://docs.gitlab.com/runner/runner_autoscale/) - core technology built by GitLab Runner team. `[GitLab Built]` +- [GitLab Runner Infrastructure Toolkit (GRIT)](https://gitlab.com/gitlab-org/ci-cd/runner-tools/grit) - managed infrastructure as code stewarded by the GitLab Runner team. Needed to deploy things like the GitLab Runner Autoscaler. `[GitLab Built]` - [Autoscaling GitLab Runner on AWS EC2](https://docs.gitlab.com/runner/configuration/runner_autoscale_aws/). `[GitLab Built]` - [GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/). `[GitLab Solution]` - Runner vending machine training resources. - - [GitLab EKS Fargate Runners](https://gitlab.com/guided-explorations/aws/eks-runner-configs/gitlab-runner-eks-fargate/-/blob/main/README.md). `[GitLab Solution]` diff --git a/doc/solutions/cloud/aws/gitlab_aws_partner_designations.md b/doc/solutions/cloud/aws/gitlab_aws_partner_designations.md index c48c3f95f9d..076fbec4940 100644 --- a/doc/solutions/cloud/aws/gitlab_aws_partner_designations.md +++ b/doc/solutions/cloud/aws/gitlab_aws_partner_designations.md @@ -17,11 +17,11 @@ This competency validates that GitLab delivers DevOps solutions that work with a ## DevSecOps Specialty Category -[AWS Program Information](https://aws.amazon.com/blogs/apn/aws-devops-competency-expands-to-include-devsecops-category/) [GitLab Announcement](https://about.gitlab.com/blog/2023/09/25/aws-devsecops-competency-partner/) +The DevSecOps qualification is a category of the DevOps Software Competency that demonstrates that GitLab is a substantial solution in helping organizations meet their DevSecOps maturity goals. GitLab was reviewed for meeting these additional qualifications before being granted this designation. [AWS Program Information](https://aws.amazon.com/blogs/apn/aws-devops-competency-expands-to-include-devsecops-category/) [GitLab Announcement](https://about.gitlab.com/blog/2023/09/25/aws-devsecops-competency-partner/) ## Public Sector Partner -This designation indicates that GitLab has been deemed qualified to work with AWS Public Sector customers. In fact, we have an entire organization dedicated to this practice. [AWS Program Information](https://aws.amazon.com/partners/programs/public-sector/) +This designation indicates that GitLab has been deemed qualified to work with AWS Public Sector customers. GitLab has a dedicated organization to address public sector specific needs. [AWS Program Information](https://aws.amazon.com/partners/programs/public-sector/) ## AWS Graviton diff --git a/doc/solutions/cloud/aws/gitlab_instance_on_aws.md b/doc/solutions/cloud/aws/gitlab_instance_on_aws.md index 320c317d446..de0ffcdc259 100644 --- a/doc/solutions/cloud/aws/gitlab_instance_on_aws.md +++ b/doc/solutions/cloud/aws/gitlab_instance_on_aws.md @@ -6,7 +6,7 @@ info: This page is owned by the Solutions Architecture team. {::options parse_block_html="true" /} -# Provision GitLab Instances on AWS EKS **(FREE SELF)** +# Provision GitLab Instances on AWS ## Available Infrastructure as Code for GitLab Instance Installation on AWS @@ -16,7 +16,7 @@ You can use the GitLab Environment Toolkit to deploy a Cloud Native Hybrid envir ### 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. +While GitLab Reference Architectures generally encourage three zone redundancy, the AWS Well Architected framework 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. @@ -28,28 +28,27 @@ 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 Services | AWS PaaS (Tested) | Provided by AWS Cloud <br />Native Hybrid Quick Start | -| ------------------------------------------------------------ | ------------------------------ | ------------------------------------------------------------ | -| <u>Tested PaaS Mentioned in Reference Architectures</u> | | | -| **PostgreSQL Database** | Amazon RDS PostgreSQL | Yes. | -| **Redis Caching** | Redis ElastiCache | Yes. | -| **Gitaly Cluster (Git Repository Storage)**<br />(Including Praefect and PostgreSQL) | ASG and Instances | Yes - ASG and Instances<br />**Note: Gitaly cannot be put into a Kubernetes Cluster.** | -| **All GitLab storages besides Git Repository Storage**<br />(Includes Git-LFS which is S3 Compatible) | AWS S3 | Yes | -| | | | -| <u>Tested PaaS for Supplemental Services</u> | | | -| **Front End Load Balancing** | AWS ELB | Yes | -| **Internal Load Balancing** | AWS ELB | Yes | -| **Outbound Email Services** | AWS Simple Email Service (SES) | Yes | -| **Certificate Authority and Management** | AWS Certificate Manager (ACM) | Yes | -| **DNS** | AWS Route53 (tested) | Yes | -| **GitLab and Infrastructure Log Aggregation** | AWS CloudWatch Logs | Yes (ContainerInsights Agent for EKS) | -| **Infrastructure Performance Metrics** | AWS CloudWatch Metrics | Yes | -| | | | -| <u>Supplemental Services and Configurations (Tested)</u> | | | -| **Prometheus for GitLab** | AWS EKS (Cloud Native Only) | Yes | -| **Grafana for GitLab** | AWS EKS (Cloud Native Only) | Yes | -| **Administrative Access to GitLab Backend** | Bastion Host in VPC | Yes - HA - Preconfigured for Cluster Management. | -| **Encryption (In Transit / At Rest)** | AWS KMS | Yes | -| **Secrets Storage for Provisioning** | AWS Secrets Manager | Yes | -| **Configuration Data for Provisioning** | AWS Parameter Store | Yes | -| **AutoScaling Kubernetes** | EKS AutoScaling Agent | Yes | +| GitLab Services | AWS PaaS (Tested) | +| ------------------------------------------------------------ | ------------------------------ | +| <u>Tested PaaS Mentioned in Reference Architectures</u> | | +| **PostgreSQL Database** | Amazon RDS PostgreSQL | +| **Redis Caching** | Redis ElastiCache | +| **Gitaly Cluster (Git Repository Storage)**<br />(Including Praefect and PostgreSQL) | ASG and Instances | +| **All GitLab storages besides Git Repository Storage**<br />(Includes Git-LFS which is S3 Compatible) | AWS S3 | +| | | +| <u>Tested PaaS for Supplemental Services</u> | | +| **Front End Load Balancing** | AWS ELB | +| **Internal Load Balancing** | AWS ELB | +| **Outbound Email Services** | AWS Simple Email Service (SES) | +| **Certificate Authority and Management** | AWS Certificate Manager (ACM) | +| **DNS** | AWS Route53 (tested) | +| **GitLab and Infrastructure Log Aggregation** | AWS CloudWatch Logs | +| **Infrastructure Performance Metrics** | AWS CloudWatch Metrics | +| | | +| <u>Supplemental Services and Configurations</u> | | +| **Prometheus for GitLab** | AWS EKS (Cloud Native Only) | +| **Grafana for GitLab** | AWS EKS (Cloud Native Only) | +| **Encryption (In Transit / At Rest)** | AWS KMS | +| **Secrets Storage for Provisioning** | AWS Secrets Manager | +| **Configuration Data for Provisioning** | AWS Parameter Store | +| **AutoScaling Kubernetes** | EKS AutoScaling Agent | diff --git a/doc/solutions/cloud/aws/index.md b/doc/solutions/cloud/aws/index.md index 7e9eed235ff..360b4161d49 100644 --- a/doc/solutions/cloud/aws/index.md +++ b/doc/solutions/cloud/aws/index.md @@ -8,20 +8,20 @@ info: This page is owned by the Solutions Architecture team. This documentation covers solutions relating to leveraging GitLab with and on Amazon Web Services (AWS). -- [GitLab partnership certifications and designations from AWS](gitlab_aws_integration.md) -- [GitLab AWS Integration Index](gitlab_aws_partner_designations.md) +- [GitLab partnership certifications and designations from AWS](gitlab_aws_partner_designations.md) +- [GitLab AWS Integration Index](gitlab_aws_integration.md) - [GitLab Instances on AWS EKS](gitlab_instance_on_aws.md) -- [SRE Considerations Gitaly on AWS](gitaly_sre_for_aws.md) +- [SRE Considerations for Gitaly on AWS](gitaly_sre_for_aws.md) - [Provision GitLab on a single EC2 instance in AWS](gitlab_single_box_on_aws.md) ## Cloud platform well architected compliance -Testing-backed architectural qualification is a fundamental concept behind implementation patterns: +Testing-backed architectural qualification is a fundamental concept behind Cloud solution implementations: -- Implementation patterns maintain GitLab Reference Architecture compliance and provide [GitLab Performance Tool](https://gitlab.com/gitlab-org/quality/performance) (GPT) reports to demonstrate adherence to them. -- Implementation patterns may be qualified by and/or contributed to by the technology vendor. For instance, an implementation pattern for AWS may be officially reviewed by AWS. -- Implementation patterns may specify and test Cloud Platform PaaS services for suitability for GitLab. This testing can be coordinated and help qualify these technologies for Reference Architectures. For instance, qualifying compatibility with and availability of runtime versions of top level PaaS such as those for PostgreSQL and Redis. -- Implementation patterns can provided qualified testing for platform limitations, for example, ensuring Gitaly Cluster can work correctly on specific Cloud Platform availability zone latency and throughput characteristics or qualifying what levels of available platform partner local disk performance is workable for Gitaly server to operate with integrity. +- Cloud solution implementations maintain GitLab Reference Architecture compliance and provide [GitLab Performance Tool](https://gitlab.com/gitlab-org/quality/performance) (GPT) reports to demonstrate adherence to them. +- Cloud solution implementations may be qualified by and/or contributed to by the technology vendor. For instance, an implementation pattern for AWS may be officially reviewed by AWS. +- Cloud solution implementations may specify and test Cloud Platform PaaS services for suitability for GitLab. This testing can be coordinated and help qualify these technologies for Reference Architectures. For instance, qualifying compatibility with and availability of runtime versions of top level PaaS such as those for PostgreSQL and Redis. +- Cloud solution implementations can provided qualified testing for platform limitations, for example, ensuring Gitaly Cluster can work correctly on specific Cloud Platform availability zone latency and throughput characteristics or qualifying what levels of available platform partner local disk performance is workable for Gitaly server to operate with integrity. ## AWS known issues list @@ -35,34 +35,36 @@ See the [GitLab AWS known issues list](https://gitlab.com/gitlab-com/alliances/a ## Platform partner specificity -Implementation patterns enable platform-specific terminology, best practice architecture, and platform-specific build manifests: +Cloud solution implementations enable platform-specific terminology, best practice architecture, and platform-specific build manifests: -- Implementation patterns are more vendor specific. For instance, advising specific compute instances / VMs / nodes instead of vCPUs or other generalized measures. -- Implementation patterns are oriented to implementing good architecture for the vendor in view. -- Implementation patterns are written to an audience who is familiar with building on the infrastructure that the implementation pattern targets. For example, if the implementation pattern is for GCP, the specific terminology of GCP is used - including using the specific names for PaaS services. -- Implementation patterns can test and qualify if the versions of PaaS available are compatible with GitLab (for example, PostgreSQL, Redis, etc.). +- Cloud solution implementations are more vendor specific. For instance, advising specific compute instances / VMs / nodes instead of vCPUs or other generalized measures. +- Cloud solution implementations are oriented to implementing good architecture for the vendor in view. +- Cloud solution implementations are written to an audience who is familiar with building on the infrastructure that the implementation pattern targets. For example, if the implementation pattern is for GCP, the specific terminology of GCP is used - including using the specific names for PaaS services. +- Cloud solution implementations can test and qualify if the versions of PaaS available are compatible with GitLab (for example, PostgreSQL, Redis, etc.). -## Platform as a Service (PaaS) specification and usage +## AWS Platform as a Service (PaaS) specification and usage -Platform as a Service options are a huge portion of the value provided by Cloud Platforms as they simplify operational complexity and reduce the SRE and security skilling required to operate advanced, highly available technology services. Implementation patterns can be pre-qualified against the partner PaaS options. +Platform as a Service options are a huge portion of the value provided by Cloud Platforms as they simplify operational complexity and reduce the SRE and security skilling required to operate advanced, highly available technology services. Cloud solution implementations can be pre-qualified against the partner PaaS options. -- Implementation patterns help implementers understand what PaaS options are known to work and how to choose between PaaS solutions when a single platform has more than one PaaS option for the same GitLab role. +- Cloud solution implementations help implementers understand what PaaS options are known to work and how to choose between PaaS solutions when a single platform has more than one PaaS option for the same GitLab role. - For instance, where reference architectures do not have a specific recommendation on what technology is leveraged for GitLab outbound email services or what the sizing should be - a Reference Implementation may advise using a cloud providers Email as a Service (PaaS) and possibly even with specific settings. +You can read more at [AWS services are usable to deploy GitLab infrastruture](gitlab_instance_on_aws.md). + ## Cost optimizing engineering Cost engineering is a fundamental aspect of Cloud Architecture and frequently the savings capabilities available on a platform exert strong influence on how to build out scaled computing. -- Implementation patterns may engineer specifically for the savings models available on a platform provider. An AWS example would be maximizing the occurrence of a specific instance type for taking advantage of reserved instances. -- Implementation patterns may leverage ephemeral compute where appropriate and with appropriate customer guidelines. For instance, a Kubernetes node group dedicated to runners on ephemeral compute (with appropriate GitLab Runner tagging to indicate the compute type). -- Implementation patterns may include vendor specific cost calculators. +- Cloud solution implementations may engineer specifically for the savings models available on a platform provider. An AWS example would be maximizing the occurrence of a specific instance type for taking advantage of reserved instances. +- Cloud solution implementations may leverage ephemeral compute where appropriate and with appropriate customer guidelines. For instance, a Kubernetes node group dedicated to runners on ephemeral compute (with appropriate GitLab Runner tagging to indicate the compute type). +- Cloud solution implementations may include vendor specific cost calculators. ## Actionability and automatability orientation -Implementation patterns are one step closer to specifics that can be used as a source for build instructions and automation code: +Cloud solution implementations are one step closer to specifics that can be used as a source for build instructions and automation code: -- Implementation patterns enable builders to generate a list of vendor specific resources required to implement GitLab for a given Reference Architecture. -- Implementation patterns enable builders to use manual instructions or to create automation to build out the reference implementation. +- Cloud solution implementations enable builders to generate a list of vendor specific resources required to implement GitLab for a given Reference Architecture. +- Cloud solution implementations enable builders to use manual instructions or to create automation to build out the reference implementation. ## Intended audiences and contributors |