Update the AWS Installation documentation

- Move the existing manual install instructions page to a subpage
  and mark it as DEPRECATED in order to clear the 'install/aws'
  URL to be an index to all AWS documentation.
- Created a new 'install/aws/index.md'
  - to give an overview of how the AWS opinionated documentation
    relates to and builds upon the reference architectures.
  - to have an index of sub-pages at the bottom.
- Provides a new sub page for GitLab Cloud Native Hybrid on AWS EKS,
  which provides critical Bill Of Materials lists for the upcoming
  AWS Quick Start for GitLab Cloud Native on EKS.

doc/install/aws/eks_clusters_aws.md

+---
+type: reference, concepts
+stage: Enablement
+group: Alliances
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# EKS cluster provisioning best practices
+
+GitLab can be used to provision an EKS cluster into AWS, however, it necessarily focuses on a basic EKS configuration. Using the AWS tools can help with advanced cluster configuration, automation, and maintenance.
+
+This documentation is not for clusters for deployment of GitLab itself, but instead clusters purpose built for:
+
+- EKS Clusters for GitLab Runners
+- Application Deployment Clusters for GitLab review apps
+- Application Deployment Cluster for production applications
+
+Information on deploying GitLab onto EKS can be found in [Provisioning GitLab Cloud Native Hybrid on AWS EKS](gitlab_hybrid_on_aws.md).
+
+## Use AWS EKS quick start or `eksctl`
+
+Using the EKS Quick Start or `eksctl` enables the following when building an EKS Cluster:
+
+- It can be part of CloudFormation IaC or [CLI (`eksctl`)](https://eksctl.io/) automation
+- You have various cluster configuration options:
+  - Selection of operating system: Amazon Linux 2, Windows, Bottlerocket
+  - Selection of Hardware Architecture: x86, ARM, GPU
+  - Selection of Fargate backend
+- It can deploy high value-add items to the cluster, including:
+  - A bastion host to keep the cluster endpoint private and possible perform performance testing.
+  - Prometheus and Grafana for monitoring.
+- EKS Autoscaler for automatic K8s Node scaling. 
+- 2 or 3 Availability Zones (AZ) spread for balance between High Availability (HA) and cost control.
+- Ability to specify spot compute.
+
+Read more about Amazon EKS architecture quick start guide:
+
+- [Landing page](https://aws.amazon.com/quickstart/architecture/amazon-eks/)
+- [Reference guide](https://aws-quickstart.github.io/quickstart-amazon-eks/)
+- [Reference guide deployment steps](https://aws-quickstart.github.io/quickstart-amazon-eks/#_deployment_steps)
+- [Reference guide parameter reference](https://aws-quickstart.github.io/quickstart-amazon-eks/#_parameter_reference)
+
+## Inject GitLab configuration for integrating clusters
+
+Read more how to [configure an App Deployment cluster](../../user/project/clusters/add_existing_cluster.md) and extract information from it to integrate it into GitLab.
+
+## Provision GitLab Runners using Helm charts
+
+Read how to [use the GitLab Runner Helm Chart](https://docs.gitlab.com/runner/install/kubernetes.html) to deploy a runner into a cluster.
+
+## Runner Cache
+
+Since the EKS Quick Start provides for EFS provisioning, the best approach is to use EFS for runner caching. Eventually we will publish information on using an S3 bucket for runner caching here.

doc/install/aws/gitaly_on_aws.md

+---
+type: reference, concepts
+stage: Enablement
+group: Alliances
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Gitaly SRE Considerations
+
+Gitaly and Gitaly Cluster have been engineered by GitLab to overcome fundamental challenges with horizontal scaling of the open source Git binaries. Here is indepth technical reading on the topic:
+
+## Why Gitaly was built
+
+Below are some links to better understand why Gitaly was built:
+
+- [Git characteristics that make horizontal scaling difficult](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#git-characteristics-that-make-horizontal-scaling-difficult)
+- [Git architectural characteristics and assumptions](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#git-architectural-characteristics-and-assumptions)
+- [Affects on horizontal compute architecture](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#affects-on-horizontal-compute-architecture)
+- [Evidence to back building a new horizontal layer to scale Git](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#evidence-to-back-building-a-new-horizontal-layer-to-scale-git)
+
+## Gitaly and Praefect elections
+
+As part of Gitaly cluster consistency, Praefect nodes will occasionally need to vote on what data copy is the most accurate. This requires an uneven number of Praefect nodes to avoid stalemates. This means that for HA, Gitaly and Praefect require a minimum of three nodes.
+
+## Gitaly performance monitoring
+
+Complete performance metrics should be collected for Gitaly instances for identification of bottlenecks, as they could have to do with disk IO, network IO or memory.
+
+Gitaly must be implemented on instance compute.
+
+## Gitaly EBS volume sizing guidelines
+
+Gitaly storage is expected to be local (not NFS of any type including EFS).
+Gitaly servers also need disk space for building and caching Git pack files.
+
+Background:
+
+- When not using provisioned EBS IO, EBS volume size determines the IO level, so provisioning volumes that are much larger than needed can be the least expensive way to improve EBS IO.
+- Only use nitro instance types due to higher IO and EBS optimization.
+- Use Amazon Linux 2 to ensure the best disk and memory optimizations (for example, ENA network adapters and drivers).
+- If GitLab backup scripts are used, they need a temporary space location large enough to hold 2 times the current size of the Git File system. If that will be done on Gitaly servers, separate volumes should be used. 
+
+## Gitaly HA in EKS quick start
+
+The AWS EKS quick start for GitLab Cloud Native implements Gitaly as a multi-zone, self-healing infrastructure. It has specific code for reestablishing a Gitaly node when one fails, including AZ failure.
+
+## Gitaly long term management
+
+Gitaly node disk sizes will need to be monitored and increased to accommodate Git repository growth and Gitaly temporary and caching storage needs. The storage configuration on all nodes should be kept identical.