--- title: Installing a cluster with compute nodes on AWS Local Zones --- # Installing a cluster with compute nodes on AWS Local Zones {#installing-aws-localzone} You can quickly install an OpenShift Container Platform cluster on Amazon Web Services (AWS) Local Zones by setting the zone names in the edge compute pool of the `install-config.yaml` file, or install a cluster in an existing Amazon Virtual Private Cloud (VPC) with Local Zone subnets. AWS Local Zones is an infrastructure that place Cloud Resources close to metropolitan regions. For more information, see "AWS Local Zones Documentation". ## Infrastructure prerequisites {#aws-zones-prerequisites_installing-aws-localzone} Before you install an OpenShift Container Platform cluster on Amazon Web Services (AWS) Local Zones, you must meet several prerequisites. The following prerequisites must be met: - You reviewed details about [OpenShift Container Platform installation and update](/openshift-docs-markdown/architecture/architecture-installation#architecture-installation) processes. - You are familiar with [Selecting a cluster installation method and preparing it for users](/openshift-docs-markdown/installing/overview/installing-preparing#installing-preparing). - You [configured an AWS account](/openshift-docs-markdown/installing/installing_aws/installing-aws-account#installing-aws-account) to host the cluster. > [!WARNING] > If you have an AWS profile stored on your computer, it must not use a temporary session token that you generated while using a multifactor authentication device. The cluster continues to use your current AWS credentials to create AWS resources for the entire life of the cluster, so you must use key-based, long-term credentials. To generate appropriate keys, see [Managing Access Keys for IAM Users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) in the AWS documentation. You can supply the keys when you run the installation program. - You downloaded the AWS CLI and installed it on your computer. See [Install the AWS CLI Using the Bundled Installer (Linux, macOS, or UNIX)](https://docs.aws.amazon.com/cli/latest/userguide/install-bundle.html) in the AWS documentation. - If you use a firewall, you [configured it to allow the sites](/openshift-docs-markdown/installing/install_config/configuring-firewall#configuring-firewall-module_configuring-firewall) that your cluster must access. - You noted the region and supported [AWS Local Zones locations](https://aws.amazon.com/about-aws/global-infrastructure/localzones/locations) to create the network resources in. - You read the [AWS Local Zones features](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/) in the AWS documentation. - You added permissions for creating network resources that support AWS Local Zones to the Identity and Access Management (IAM) user or role. The following example enables a zone group that can give a user or role access for creating network resources that support AWS Local Zones. ```yaml {title="Example of an additional IAM policy with the ec2:ModifyAvailabilityZoneGroup permission attached to an IAM user or role."} { "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:ModifyAvailabilityZoneGroup" ], "Effect": "Allow", "Resource": "*" } ] } ``` ## Cluster limitations in AWS Local Zones {#cluster-limitations-aws-zone_installing-aws-localzone} Some limitations exist when you try to deploy a cluster with a default installation configuration in an Amazon Web Services (AWS) Local Zone. > [!IMPORTANT] > The following list details limitations when deploying a cluster in a pre-configured AWS zone: > > - The maximum transmission unit (MTU) between an Amazon EC2 instance in a zone and an Amazon EC2 instance in the Region is `1300`. This causes the cluster-wide network MTU to change according to the network plugin that is used with the deployment. > - Network resources such as Network Load Balancer (NLB), Classic Load Balancer, and Network Address Translation (NAT) Gateways are not globally supported. > - For an OpenShift Container Platform cluster on AWS, the AWS Elastic Block Storage (EBS) `gp3` type volume is the default for node volumes and the default for the storage class. This volume type is not globally available on zone locations. By default, the nodes running in zones are deployed with the `gp2` EBS volume. The `gp2-csi` `StorageClass` parameter must be set when creating workloads on zone nodes. If you want the installation program to automatically create Local Zone subnets for your OpenShift Container Platform cluster, specific configuration limitations apply with this method. > [!IMPORTANT] > The following configuration limitation applies when you set the installation program to automatically create subnets for your OpenShift Container Platform cluster: > > - When the installation program creates private subnets in AWS Local Zones, the program associates each subnet with the route table of its parent zone. This operation ensures that each private subnet can route egress traffic to the internet by way of NAT Gateways in an AWS Region. > - If the parent-zone route table does not exist during cluster installation, the installation program associates any private subnet with the first available private route table in the Amazon Virtual Private Cloud (VPC). This approach is valid only for AWS Local Zones subnets in an OpenShift Container Platform cluster. ## About edge compute pools {#edge-machine-pools-aws-local-zones_installing-aws-localzone} The edge compute pool configuration is common between Amazon Web Services (AWS) Local Zones locations. You can use the edge compute pool to create new labels to deploy applications onto Amazon Web Services (AWS) Local Zones nodes. Edge compute nodes are tainted compute nodes that run in AWS Local Zones locations. When deploying a cluster that uses Local Zones, consider the following points: - Amazon EC2 instances in the Local Zones are more expensive than Amazon EC2 instances in the Availability Zones. - The latency is lower between the applications running in AWS Local Zones and the user. A latency impact exists for some workloads if, for example, ingress traffic is mixed between Local Zones and Availability Zones. > [!IMPORTANT] > Generally, the maximum transmission unit (MTU) between an Amazon EC2 instance in a Local Zones and an Amazon EC2 instance in the Region is 1300. The cluster network MTU must be always less than the EC2 MTU to account for the overhead. The specific overhead is determined by the network plugin. For example: OVN-Kubernetes has an overhead of `100 bytes`. > > The network plugin can provide additional features, such as IPsec, that also affect the MTU sizing. OpenShift Container Platform 4.12 introduced a new compute pool, *edge*, that is designed for use in remote zones. The edge compute pool configuration is common between Amazon Web Services (AWS) Local Zones locations. Because of the type and size limitations of resources like EC2 and EBS on Local Zones resources, the default instance type can vary from the traditional compute pool. The default Elastic Block Store (EBS) for Local Zones locations is `gp2`, which differs from the non-edge compute pool. The instance type used for each Local Zones on an edge compute pool also might differ from other compute pools, depending on the instance offerings on the zone. The edge compute pool creates new labels that developers can use to deploy applications onto AWS Local Zones nodes. The new labels are: - `node-role.kubernetes.io/edge=''` - `machine.openshift.io/zone-type=local-zone` - `machine.openshift.io/zone-group=$ZONE_GROUP_NAME` By default, the machine sets for the edge compute pool define the taint of `NoSchedule` to prevent other workloads from spreading on Local Zones instances. Users can only run user workloads if they define tolerations in the pod specification. **Additional resources** {._additional-resources} - [MTU value selection](/openshift-docs-markdown/networking/advanced_networking/changing-cluster-network-mtu#mtu-value-selection_changing-cluster-network-mtu) - [Changing the MTU for the cluster network](/openshift-docs-markdown/networking/advanced_networking/changing-cluster-network-mtu#nw-ovn-ipsec-enable_configuring-ipsec-ovn) - [Understanding taints and tolerations](/openshift-docs-markdown/nodes/scheduling/nodes-scheduler-taints-tolerations#nodes-scheduler-taints-tolerations-about_nodes-scheduler-taints-tolerations) - [Storage classes](/openshift-docs-markdown/storage/understanding-persistent-storage#pvc-storage-class_understanding-persistent-storage) - [Ingress Controller sharding](/openshift-docs-markdown/networking/ingress_load_balancing/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-ingress-controller#nw-ingress-sharding_configuring-ingress-cluster-traffic-ingress-controller) - [How Local Zones work (AWS documentation)](https://docs.aws.amazon.com/local-zones/latest/ug/how-local-zones-work.html) ## Opting in to an AWS Local Zones {#installation-aws-add-zone-locations_installing-aws-localzone} Create a subnet in an Amazon Web Services (AWS) Local Zones when you need workloads to run physically closer to users or data sources than a standard AWS Local Zones. If you plan to create subnets in AWS Local Zones, you must opt in to each zone group separately. **Prerequisites** - You have installed the AWS CLI. - You have determined an AWS Region for where you want to deploy your OpenShift Container Platform cluster. - You have attached a permissive IAM policy to a user or role account that opts in to the zone group. **Procedure** 1. List the zones that are available in your AWS Region by running the following command: ```terminal {title="Example command for listing available AWS Local Zones in an AWS Region"} $ aws --region "" ec2 describe-availability-zones \ --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \ --filters Name=zone-type,Values=local-zone \ --all-availability-zones ``` Depending on the AWS Region, the list of available zones might be long. The command returns the following fields: `ZoneName` : The name of the Local Zones. `GroupName` : The group that comprises the zone. To opt in to the Region, save the name. `Status` : The status of the Local Zones group. If the status is `not-opted-in`, you must opt in the `GroupName` as described in the next step. 2. Opt in to the zone group on your AWS account by running the following command: ```terminal $ aws ec2 modify-availability-zone-group \ --group-name "" \ --opt-in-status opted-in ``` `` : Replace with the name of the group of the Local Zones where you want to create subnets. For example, specify `us-east-1-nyc-1` to use the zone `us-east-1-nyc-1a` (US East New York). ## Obtaining an AWS Marketplace image {#installation-aws-marketplace-subscribe_installing-aws-localzone} If you are deploying an OpenShift Container Platform cluster by using an Amazon Web Services (AWS) Marketplace image, you must first subscribe through AWS. Subscribing to the offer provides you with the Amazon Machine Image (AMI) ID that the installation program uses to deploy compute nodes. > [!NOTE] > You should only modify the RHCOS image for compute machines to use an AWS Marketplace image. Control plane machines and infrastructure nodes do not require an OpenShift Container Platform subscription and use the public RHCOS default image by default, which does not incur subscription costs on your AWS bill. Therefore, you should not modify the cluster default boot image or the control plane boot images. Applying the AWS Marketplace image to them will incur additional licensing costs that cannot be recovered. **Prerequisites** - You have an AWS account to buy the offer. This account does not have to be the same account that you use to install the cluster. **Procedure** 1. Complete the OpenShift Container Platform subscription from the [AWS Marketplace](https://aws.amazon.com/marketplace/fulfillment?productId=59ead7de-2540-4653-a8b0-fa7926d5c845). 2. Record the AMI ID for your specific AWS region. As part of the installation process, you must update the `install-config.yaml` file with this value before deploying the cluster. ```yaml {title="Sample install-config.yaml file with AWS Marketplace compute nodes"} apiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker platform: aws: amiID: ami-06c4d345f7c207239 type: m5.4xlarge replicas: 3 metadata: name: test-cluster platform: aws: region: us-east-2 sshKey: ssh-ed25519 AAAA... pullSecret: '{"auths": ...}' ``` where: `compute.platform.aws.amiID` : Specifies the AMI ID from your AWS Marketplace subscription. `platform.aws.region` : Specifies the `platform.aws.region` parameter. Your AMI ID is associated with a specific AWS region. When creating the installation configuration file, ensure that you select the same AWS region that you specified when configuring your subscription. ## Minimum resource requirements for cluster installation {#installation-minimum-resource-requirements_installing-aws-localzone} To ensure that your OpenShift Container Platform cluster runs as expected, each cluster machine must meet minimum CPU, memory, and storage requirements. **Minimum resource requirements**
Machine Operating system vCPU Virtual RAM Storage Input/Output Per Second (IOPS)
Bootstrap RHCOS 4 16 GB 100 GB 300
Control plane RHCOS 4 16 GB 100 GB 300
Compute RHCOS 2 8 GB 100 GB 300
- One vCPU is equal to one physical core when simultaneous multithreading (SMT), or Hyper-Threading, is not enabled. When enabled, use the following formula to calculate the corresponding ratio: (threads per core × cores) × sockets = vCPUs. - OpenShift Container Platform and Kubernetes are sensitive to disk performance, and Red Hat recommends faster storage, particularly for etcd on the control plane nodes which require a 10 ms p99 fsync duration. On many cloud platforms, storage size and IOPS scale together, so you might need to provision more storage to get enough performance. - As with all user-provisioned installations, if you choose to use RHEL compute machines in your cluster, you take responsibility for all operating system life cycle management and maintenance, including performing system updates, applying patches, and completing all other required tasks. OpenShift Container Platform 4.10 and later do not support RHEL 7 compute machines. > [!NOTE] > In OpenShift Container Platform version 4.22, RHCOS uses RHEL version 9.8, which updates the micro-architecture requirements. Each architecture requires the following minimum instruction set architectures (ISA): > > - x86-64 architecture requires x86-64-v2 ISA > - ARM64 architecture requires ARMv8.0-A ISA > - ppc64le architecture requires IBM(R) Power9 ISA > - s390x architecture requires IBM(R) z14 ISA > > For more information, see [Architectures](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/9.8_release_notes/index#architectures) in the RHEL documentation. If an instance type for your platform meets the minimum requirements for cluster machines, it is supported to use in OpenShift Container Platform. ## Tested instance types for AWS {#installation-aws-tested-machine-types_installing-aws-localzone} To ensure cluster stability and performance, use one of the tested Amazon Web Services (AWS) instance types for your OpenShift Container Platform machines. The following AWS instance types have been tested with OpenShift Container Platform for use with AWS Local Zones. > [!NOTE] > Use the machine types included in the following charts for your AWS instances. If you use an instance type that is not listed in the chart, ensure that the instance size you use matches the minimum resource requirements in "Minimum resource requirements for cluster installation". See the following machine types based on 64-bit x86 architecture for AWS Local Zones: - `c5.*` - `c5d.*` - `m6i.*` - `m5.*` - `r5.*` - `t3.*` **Additional resources** {._additional-resources} - [AWS Local Zones features (AWS documentation)](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/) ## Creating the installation configuration file {#installation-generate-aws-user-infra-install-config_installing-aws-localzone} Generate and customize the installation configuration file that the installation program needs to deploy your cluster. **Prerequisites** - You obtained the OpenShift Container Platform installation program for user-provisioned infrastructure and the pull secret for your cluster. - You checked that you are deploying your cluster to an Amazon Web Services (AWS) Region with an accompanying Red Hat Enterprise Linux CoreOS (RHCOS) AMI published by Red Hat. If you are deploying to an AWS Region that requires a custom AMI, such as an AWS GovCloud Region, you must create the `install-config.yaml` file manually. **Procedure** 1. Create the `install-config.yaml` file. 1. Change to the directory that contains the installation program and run the following command: ```terminal $ ./openshift-install create install-config --dir ``` For ``, specify the directory name to store the files that the installation program creates. > [!IMPORTANT] > Specify an empty directory. Some installation assets, such as bootstrap X.509 certificates have short expiration intervals, so you must not reuse an installation directory. If you want to reuse individual files from another cluster installation, you can copy them into your directory. However, the file names for the installation assets might change between releases. Use caution when copying installation files from an earlier OpenShift Container Platform version. 2. At the prompts, provide the configuration details for your cloud: 1. Optional: Select an SSH key to use to access your cluster machines. > [!NOTE] > For production OpenShift Container Platform clusters on which you want to perform installation debugging or disaster recovery, specify an SSH key that your `ssh-agent` process uses. 2. Select **aws** as the platform to target. 3. If you do not have an AWS profile stored on your computer, enter the AWS access key ID and secret access key for the user that you configured to run the installation program. > [!NOTE] > The AWS access key ID and secret access key are stored in `~/.aws/credentials` in the home directory of the current user on the installation host. You are prompted for the credentials by the installation program if the credentials for the exported profile are not present in the file. Any credentials that you provide to the installation program are stored in the file. 4. Select the AWS Region to deploy the cluster to. 5. Select the base domain for the Route 53 service that you configured for your cluster. 6. Enter a descriptive name for your cluster. 7. Paste the [pull secret from Red Hat OpenShift Cluster Manager](https://console.redhat.com/openshift/install/pull-secret). 2. Optional: Back up the `install-config.yaml` file. > [!IMPORTANT] > The `install-config.yaml` file is consumed during the installation process. If you want to reuse the file, you must back it up now. ## Examples of installation configuration files with edge compute pools {#installation-aws-edge-compute-pools-examples_installing-aws-localzone} See an example `install-config.yaml` file to better understand configurations for edge compute pools. The following examples show `install-config.yaml` files that contain an edge machine pool configuration. ```yaml {title="Configuration that uses an edge pool with a custom instance type"} apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: ipi-edgezone compute: - name: edge platform: aws: type: r5.2xlarge platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA... ``` Instance types differ between locations. To verify availability in the Local Zones in which the cluster runs, see the AWS documentation. ```yaml {title="Configuration that uses an edge pool with a custom Amazon Elastic Block Store (EBS) type"} apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: ipi-edgezone compute: - name: edge platform: aws: zones: - us-west-2-lax-1a - us-west-2-lax-1b - us-west-2-phx-2a rootVolume: type: gp3 size: 120 platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA... ``` Elastic Block Storage (EBS) types differ between locations. Check the AWS documentation to verify availability in the Local Zones in which the cluster runs. ```yaml {title="Configuration that uses an edge pool with custom security groups"} apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: ipi-edgezone compute: - name: edge platform: aws: additionalSecurityGroupIDs: - sg-1 - sg-2 platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA... ``` For the `additionalSecurityGroupIDs` parameter, specify the name of the security group as it is displayed on the Amazon EC2 console. Ensure that you include the `sg` prefix. ## Customizing the cluster network MTU {#installation-aws-cluster-network-mtu_installing-aws-localzone} Before you deploy a cluster on AWS, you can customize the cluster network maximum transmission unit (MTU) for your cluster network to meet the needs of your infrastructure. By default, when you install a cluster with supported Local Zones capabilities, the MTU value for the cluster network is automatically adjusted to the lowest value that the network plugin accepts. > [!IMPORTANT] > Setting an unsupported MTU value for EC2 instances that operate in the Local Zones infrastructure can cause issues for your OpenShift Container Platform cluster. If the Local Zone supports higher MTU values in between EC2 instances in the Local Zone and the AWS Region, you can manually configure the higher value to increase the network performance of the cluster network. You can customize the MTU for a cluster by specifying the `networking.clusterNetworkMTU` parameter in the `install-config.yaml` configuration file. > [!IMPORTANT] > All subnets in Local Zones must support the higher MTU value, so that each node in that zone can successfully communicate with services in the AWS Region and deploy your workloads. ```yaml {title="Example of overwriting the default MTU value"} apiVersion: v1 baseDomain: devcluster.openshift.com metadata: name: edge-zone networking: clusterNetworkMTU: 8901 compute: - name: edge platform: aws: zones: - us-west-2-lax-1a - us-west-2-lax-1b platform: aws: region: us-west-2 pullSecret: '{"auths": ...}' sshKey: ssh-ed25519 AAAA... ``` **Additional resources** {._additional-resources} - [AWS resources supported in Local Zones (AWS documentation)](https://docs.aws.amazon.com/local-zones/latest/ug/how-local-zones-work.html#considerations) ## Cluster installation options for an AWS Local Zones environment {#aws-cluster-installation-options-aws-lzs_installing-aws-localzone} You can install an OpenShift Container Platform cluster on AWS with edge compute nodes defined in Local Zones. Choose one of the following installation options: - Fully automated option: Installing a cluster to quickly extend compute nodes to edge compute pools, where the installation program automatically creates infrastructure resources for the OpenShift Container Platform cluster. - Existing VPC option: Installing a cluster on AWS into an existing VPC, where you supply Local Zones subnets to the `install-config.yaml` file. ## Install a cluster quickly in AWS Local Zones {#installation-cluster-quickly-extend-compute-nodes_installing-aws-localzone} You can quickly install a cluster on Amazon Web Services (AWS) to extend compute nodes to Local Zones locations. By using this installation route, the installation program automatically creates network resources and Local Zones subnets for each zone that you defined in your configuration file. To customize the installation, you must modify parameters in the `install-config.yaml` file before you deploy the cluster. ### Modifying an installation configuration file to use Amazon Web Services (AWS) Local Zones {#install-creating-install-config-aws-edge-zones_installing-aws-localzone} Modify an `install-config.yaml` file to include AWS Local Zones. **Prerequisites** - You have configured an AWS account. - You added your AWS keys and AWS Region to your local AWS profile by running `aws configure`. - You are familiar with the configuration limitations that apply when you specify the installation program to automatically create subnets for your OpenShift Container Platform cluster. - You opted in to the Local Zones group for each zone. - You created an `install-config.yaml` file by using the procedure "Creating the installation configuration file". **Procedure** 1. Modify the `install-config.yaml` file by specifying Local Zones names in the `platform.aws.zones` property of the edge compute pool. ```yaml # ... platform: aws: region: compute: - name: edge platform: aws: zones: - #... ``` where: `platform.aws.region` : Specifies the AWS Region name. `compute.platform.aws.zones` : Specifies the list of Local Zones names to use. The zones must exist in the same AWS Region specified in the `platform.aws.region` field. The following example shows a configuration for installing a cluster in the `us-west-2` AWS Region that extends edge nodes to Local Zones in `Los Angeles` and `Las Vegas` locations: ```yaml apiVersion: v1 baseDomain: example.com metadata: name: cluster-name platform: aws: region: us-west-2 compute: - name: edge platform: aws: zones: - us-west-2-lax-1a - us-west-2-lax-1b - us-west-2-las-1a pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' #... ``` 2. Deploy your cluster. **Additional resources** {._additional-resources} - [Creating the installation configuration file](/openshift-docs-markdown/installing/installing_aws/ipi/installing-aws-localzone#installation-generate-aws-user-infra-install-config_installing-aws-localzone) - [Cluster limitations in AWS Local Zones](/openshift-docs-markdown/installing/installing_aws/ipi/installing-aws-localzone#cluster-limitations-aws-zone_installing-aws-localzone) - [Deploying the cluster](/openshift-docs-markdown/installing/installing_aws/ipi/installing-aws-localzone#installation-launching-installer_installing-aws-localzone) ## Installing a cluster in an existing VPC that has Local Zone subnets {#creating-aws-local-zone-environment-existing_installing-aws-localzone} You can install a cluster into an existing Amazon Virtual Private Cloud (VPC) on Amazon Web Services (AWS). The installation program provisions the rest of the required infrastructure, which you can further customize. To customize the installation, change parameters in the `install-config.yaml` file before you install the cluster. Installing a cluster on AWS into an existing VPC requires extending compute nodes to the edge of the Cloud Infrastructure by using AWS Local Zones. Local Zone subnets extend regular compute nodes to edge networks. Each edge compute nodes runs a user workload. After you create an Amazon Web Service (AWS) Local Zone environment, and you deploy your cluster, you can use edge compute nodes to create user workloads in Local Zone subnets. > [!NOTE] > If you want to create private subnets, you must either change the provided CloudFormation template or create your own template. You can use a provided CloudFormation template to create network resources. Additionally, you can change a template to customize your infrastructure or use the information that they contain to create AWS resources according to your company’s policies. > [!IMPORTANT] > The documentation provides the steps for performing an installer-provisioned infrastructure installation for example purposes only. Installing a cluster in an existing VPC requires that you have knowledge of the cloud provider and the installation process of OpenShift Container Platform. You can use a CloudFormation template to assist you with completing these steps or to help model your own cluster installation. Instead of using the CloudFormation template to create resources, you can decide to use other methods for generating these resources. ### Creating a VPC in Amazon Web Services (AWS) {#installation-creating-aws-vpc-localzone_installing-aws-localzone} You can create a Virtual Private Cloud (VPC), and subnets for all Local Zones locations, in AWS for your OpenShift Container Platform cluster to extend compute nodes to edge locations. You can further customize your VPC to meet your requirements, including a VPN and route tables. You can also add new Local Zones subnets not included at initial deployment. You can use the provided CloudFormation template and a custom parameter file to create a stack of AWS resources that represent the VPC. > [!NOTE] > If you do not use the provided CloudFormation template to create your AWS infrastructure, you must review the provided information and manually create the infrastructure. If your cluster does not initialize correctly, you might have to contact Red Hat support with your installation logs. **Prerequisites** - You configured an AWS account. - You added your AWS keys and AWS Region to your local AWS profile by running `aws configure`. - You opted in to the AWS Local Zones on your AWS account. **Procedure** 1. Create a JSON file that contains the parameter values that the CloudFormation template requires: ```json [ { "ParameterKey": "VpcCidr", "ParameterValue": "10.0.0.0/16" }, { "ParameterKey": "AvailabilityZoneCount", "ParameterValue": "3" }, { "ParameterKey": "SubnetBits", "ParameterValue": "12" } ] ``` where: `VpcCidr` : Specifies the CIDR block for the VPC. Use a CIDR block in the format `x.x.x.x/16-24`. `AvailabilityZoneCount` : Specifies the number of availability zones to deploy the VPC in. Use an integer between `1` and `3`. `SubnetBits` : Specifies the size of each subnet in each availability zone. Use an integer between `5` and `13`, where `5` is `/27` and `13` is `/19`. 2. Go to the section of the documentation named "CloudFormation template for the VPC", and then copy the syntax from the provided template. Save the copied template syntax as a YAML file on your local system. This template describes the VPC that your cluster requires. 3. Launch the CloudFormation template to create a stack of AWS resources that represent the VPC by running the following command: > [!IMPORTANT] > You must enter the command on a single line. ```terminal $ aws cloudformation create-stack --stack-name \ --template-body file://