AWS secret regions

The following AWS secret partitions are supported:

  • us-isob-east-1 (SC2S)

  • us-iso-east-1 (C2S)

The maximum supported MTU in an AWS SC2S and C2S Regions is not the same as AWS commercial. For more information about configuring MTU during installation, see the Cluster Network Operator configuration object section in Installing a cluster on AWS with network customizations

Installation requirements

Red Hat does not publish a Red Hat Enterprise Linux CoreOS (RHCOS) Amzaon Machine Image for the AWS Secret and Top Secret Regions.

Before you can install the cluster, you must:

  • Upload a custom RHCOS AMI.

  • Manually create the installation configuration file (install-config.yaml).

  • Specify the AWS region, and the accompanying custom AMI, in the installation configuration file.

You cannot use the OpenShift Container Platform installation program to create the installation configuration file. The installer does not list an AWS region without native support for an RHCOS AMI.

You must also define a custom CA certificate in the additionalTrustBundle field of the install-config.yaml file because the AWS API requires a custom CA trust bundle. To allow the installation program to access the AWS API, the CA certificates must also be defined on the machine that runs the installation program. You must add the CA bundle to the trust store on the machine, use the AWS_CA_BUNDLE environment variable, or define the CA bundle in the ca_bundle field of the AWS config file.

Private clusters

You can deploy a private OpenShift Container Platform cluster that does not expose external endpoints. Private clusters are accessible from only an internal network and are not visible to the internet.

Public zones are not supported in Route 53 in an AWS Top Secret Region. Therefore, clusters must be private if they are deployed to an AWS Top Secret Region.

By default, OpenShift Container Platform is provisioned to use publicly-accessible DNS and endpoints. A private cluster sets the DNS, Ingress Controller, and API server to private when you deploy your cluster. This means that the cluster resources are only accessible from your internal network and are not visible to the internet.

To deploy a private cluster, you must:

  • Use existing networking that meets your requirements. Your cluster resources might be shared between other clusters on the network.

  • Deploy from a machine that has access to:

    • The API services for the cloud to which you provision.

    • The hosts on the network that you provision.

    • The internet to obtain installation media.

You can use any machine that meets these access requirements and follows your company’s guidelines. For example, this machine can be a bastion host on your cloud network or a machine that has access to the network through a VPN.

Private clusters in AWS

To create a private cluster on Amazon Web Services (AWS), you must provide an existing private VPC and subnets to host the cluster. The installation program must also be able to resolve the DNS records that the cluster requires. The installation program configures the Ingress Operator and API server for access from only the private network.

The cluster still requires access to internet to access the AWS APIs.

The following items are not required or created when you install a private cluster:

  • Public subnets

  • Public load balancers, which support public ingress

  • A public Route 53 zone that matches the baseDomain for the cluster

The installation program does use the baseDomain that you specify to create a private Route 53 zone and the required records for the cluster. The cluster is configured so that the Operators do not create public records for the cluster and all cluster machines are placed in the private subnets that you specify.


The ability to add public functionality to a private cluster is limited.

  • You cannot make the Kubernetes API endpoints public after installation without taking additional actions, including creating public subnets in the VPC for each availability zone in use, creating a public load balancer, and configuring the control plane security groups to allow traffic from the internet on 6443 (Kubernetes API port).

  • If you use a public Service type load balancer, you must tag a public subnet in each availability zone with kubernetes.io/cluster/<cluster-infra-id>: shared so that AWS can use them to create public load balancers.

About using a custom VPC

In OpenShift Container Platform 4.11, you can deploy a cluster into existing subnets in an existing Amazon Virtual Private Cloud (VPC) in Amazon Web Services (AWS). By deploying OpenShift Container Platform into an existing AWS VPC, you might be able to avoid limit constraints in new accounts or more easily abide by the operational constraints that your company’s guidelines set. If you cannot obtain the infrastructure creation permissions that are required to create the VPC yourself, use this installation option.

Because the installation program cannot know what other components are also in your existing subnets, it cannot choose subnet CIDRs and so forth on your behalf. You must configure networking for the subnets that you install your cluster to yourself.

Requirements for using your VPC

The installation program no longer creates the following components:

  • Internet gateways

  • NAT gateways

  • Subnets

  • Route tables

  • VPCs

  • VPC DHCP options

  • VPC endpoints

The installation program requires that you use the cloud-provided DNS server. Using a custom DNS server is not supported and causes the installation to fail.

If you use a custom VPC, you must correctly configure it and its subnets for the installation program and the cluster to use. See Amazon VPC console wizard configurations and Work with VPCs and subnets in the AWS documentation for more information on creating and managing an AWS VPC.

The installation program cannot:

  • Subdivide network ranges for the cluster to use.

  • Set route tables for the subnets.

  • Set VPC options like DHCP.

You must complete these tasks before you install the cluster. See VPC networking components and Route tables for your VPC for more information on configuring networking in an AWS VPC.

Your VPC must meet the following characteristics:

  • The VPC must not use the kubernetes.io/cluster/.*: owned tag.

    The installation program modifies your subnets to add the kubernetes.io/cluster/.*: shared tag, so your subnets must have at least one free tag slot available for it. See Tag Restrictions in the AWS documentation to confirm that the installation program can add a tag to each subnet that you specify.

  • You must enable the enableDnsSupport and enableDnsHostnames attributes in your VPC, so that the cluster can use the Route 53 zones that are attached to the VPC to resolve cluster’s internal DNS records. See DNS Support in Your VPC in the AWS documentation.

    If you prefer to use your own Route 53 hosted private zone, you must associate the existing hosted zone with your VPC prior to installing a cluster. You can define your hosted zone using the platform.aws.hostedZone field in the install-config.yaml file.

A cluster in an SC2S or C2S Region is unable to reach the public IP addresses for the EC2, ELB, and S3 endpoints. Depending on the level to which you want to restrict internet traffic during the installation, the following configuration options are available:

Option 1: Create VPC endpoints

Create a VPC endpoint and attach it to the subnets that the clusters are using. Name the endpoints as follows:

  • elasticloadbalancing.<region>.sc2s.sgov.gov

  • ec2.<region>.sc2s.sgov.gov

  • s3.<region>.sc2s.sgov.gov

  • elasticloadbalancing.<region>.c2s.ic.gov

  • ec2.<region>.c2s.ic.gov

  • s3.<region>.c2s.ic.gov

With this option, network traffic remains private between your VPC and the required AWS services.

Option 2: Create a proxy without VPC endpoints

As part of the installation process, you can configure an HTTP or HTTPS proxy. With this option, internet traffic goes through the proxy to reach the required AWS services.

Option 3: Create a proxy with VPC endpoints

As part of the installation process, you can configure an HTTP or HTTPS proxy with VPC endpoints. Create a VPC endpoint and attach it to the subnets that the clusters are using. Name the endpoints as follows:

  • elasticloadbalancing.<region>.sc2s.sgov.gov

  • ec2.<region>.sc2s.sgov.gov

  • s3.<region>.sc2s.sgov.gov

  • elasticloadbalancing.<region>.c2s.ic.gov

  • ec2.<region>.c2s.ic.gov

  • s3.<region>.c2s.ic.gov

When configuring the proxy in the install-config.yaml file, add these endpoints to the noProxy field. With this option, the proxy prevents the cluster from accessing the internet directly. However, network traffic remains private between your VPC and the required AWS services.

Required VPC components

You must provide a suitable VPC and subnets that allow communication to your machines.

Component AWS type Description


  • AWS::EC2::VPC

  • AWS::EC2::VPCEndpoint

You must provide a public VPC for the cluster to use. The VPC uses an endpoint that references the route tables for each subnet to improve communication with the registry that is hosted in S3.

Public subnets

  • AWS::EC2::Subnet

  • AWS::EC2::SubnetNetworkAclAssociation

Your VPC must have public subnets for between 1 and 3 availability zones and associate them with appropriate Ingress rules.

Internet gateway

  • AWS::EC2::InternetGateway

  • AWS::EC2::VPCGatewayAttachment

  • AWS::EC2::RouteTable

  • AWS::EC2::Route

  • AWS::EC2::SubnetRouteTableAssociation

  • AWS::EC2::NatGateway

  • AWS::EC2::EIP

You must have a public internet gateway, with public routes, attached to the VPC. In the provided templates, each public subnet has a NAT gateway with an EIP address. These NAT gateways allow cluster resources, like private subnet instances, to reach the internet and are not required for some restricted network or proxy scenarios.

Network access control

  • AWS::EC2::NetworkAcl

  • AWS::EC2::NetworkAclEntry

You must allow the VPC to access the following ports:




Inbound HTTP traffic


Inbound HTTPS traffic


Inbound SSH traffic

1024 - 65535

Inbound ephemeral traffic

0 - 65535

Outbound ephemeral traffic

Private subnets

  • AWS::EC2::Subnet

  • AWS::EC2::RouteTable

  • AWS::EC2::SubnetRouteTableAssociation

Your VPC can have private subnets. The provided CloudFormation templates can create private subnets for between 1 and 3 availability zones. If you use private subnets, you must provide appropriate routes and tables for them.

VPC validation

To ensure that the subnets that you provide are suitable, the installation program confirms the following data:

  • All the subnets that you specify exist.

  • You provide private subnets.

  • The subnet CIDRs belong to the machine CIDR that you specified.

  • You provide subnets for each availability zone. Each availability zone contains no more than one public and one private subnet. If you use a private cluster, provide only a private subnet for each availability zone. Otherwise, provide exactly one public and private subnet for each availability zone.

  • You provide a public subnet for each private subnet availability zone. Machines are not provisioned in availability zones that you do not provide private subnets for.

If you destroy a cluster that uses an existing VPC, the VPC is not deleted. When you remove the OpenShift Container Platform cluster from a VPC, the kubernetes.io/cluster/.*: shared tag is removed from the subnets that it used.

Division of permissions

Starting with OpenShift Container Platform 4.3, you do not need all of the permissions that are required for an installation program-provisioned infrastructure cluster to deploy a cluster. This change mimics the division of permissions that you might have at your company: some individuals can create different resource in your clouds than others. For example, you might be able to create application-specific items, like instances, buckets, and load balancers, but not networking-related components such as VPCs, subnets, or ingress rules.

The AWS credentials that you use when you create your cluster do not need the networking permissions that are required to make VPCs and core networking components within the VPC, such as subnets, routing tables, internet gateways, NAT, and VPN. You still need permission to make the application resources that the machines within the cluster require, such as ELBs, security groups, S3 buckets, and nodes.

Isolation between clusters

If you deploy OpenShift Container Platform to an existing network, the isolation of cluster services is reduced in the following ways:

  • You can install multiple OpenShift Container Platform clusters in the same VPC.

  • ICMP ingress is allowed from the entire network.

  • TCP 22 ingress (SSH) is allowed to the entire network.

  • Control plane TCP 6443 ingress (Kubernetes API) is allowed to the entire network.

  • Control plane TCP 22623 ingress (MCS) is allowed to the entire network.

Internet access for OpenShift Container Platform

In OpenShift Container Platform 4.11, you require access to the internet to install your cluster.

You must have internet access to:

  • Access OpenShift Cluster Manager to download the installation program and perform subscription management. If the cluster has internet access and you do not disable Telemetry, that service automatically entitles your cluster.

  • Access Quay.io to obtain the packages that are required to install your cluster.

  • Obtain the packages that are required to perform cluster updates.

If your cluster cannot have direct internet access, you can perform a restricted network installation on some types of infrastructure that you provision. During that process, you download the required content and use it to populate a mirror registry with the installation packages. With some installation types, the environment that you install your cluster in will not require internet access. Before you update the cluster, you update the content of the mirror registry.

Uploading a custom RHCOS AMI in AWS

If you are deploying to a custom Amazon Web Services (AWS) region, you must upload a custom Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Image (AMI) that belongs to that region.

  • You configured an AWS account.

  • You created an Amazon S3 bucket with the required IAM service role.

  • You uploaded your RHCOS VMDK file to Amazon S3. The RHCOS VMDK file must be the highest version that is less than or equal to the OpenShift Container Platform version you are installing.

  • You downloaded the AWS CLI and installed it on your computer. See Install the AWS CLI Using the Bundled Installer.

  1. Export your AWS profile as an environment variable:

    $ export AWS_PROFILE=<aws_profile> (1)
  2. Export the region to associate with your custom AMI as an environment variable:

    $ export AWS_DEFAULT_REGION=<aws_region> (1)
  3. Export the version of RHCOS you uploaded to Amazon S3 as an environment variable:

    $ export RHCOS_VERSION=<version> (1)
    1 The RHCOS VMDK version, like 4.11.0.
  4. Export the Amazon S3 bucket name as an environment variable:

    $ export VMIMPORT_BUCKET_NAME=<s3_bucket_name>
  5. Create the containers.json file and define your RHCOS VMDK file:

    $ cat <<EOF > containers.json
       "Description": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64",
       "Format": "vmdk",
       "UserBucket": {
          "S3Bucket": "${VMIMPORT_BUCKET_NAME}",
          "S3Key": "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64.vmdk"
  6. Import the RHCOS disk as an Amazon EBS snapshot:

    $ aws ec2 import-snapshot --region ${AWS_DEFAULT_REGION} \
         --description "<description>" \ (1)
         --disk-container "file://<file_path>/containers.json" (2)
    1 The description of your RHCOS disk being imported, like rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64.
    2 The file path to the JSON file describing your RHCOS disk. The JSON file should contain your Amazon S3 bucket name and key.
  7. Check the status of the image import:

    $ watch -n 5 aws ec2 describe-import-snapshot-tasks --region ${AWS_DEFAULT_REGION}
    Example output
        "ImportSnapshotTasks": [
                "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                "ImportTaskId": "import-snap-fh6i8uil",
                "SnapshotTaskDetail": {
                    "Description": "rhcos-4.7.0-x86_64-aws.x86_64",
                    "DiskImageSize": 819056640.0,
                    "Format": "VMDK",
                    "SnapshotId": "snap-06331325870076318",
                    "Status": "completed",
                    "UserBucket": {
                        "S3Bucket": "external-images",
                        "S3Key": "rhcos-4.7.0-x86_64-aws.x86_64.vmdk"

    Copy the SnapshotId to register the image.

  8. Create a custom RHCOS AMI from the RHCOS snapshot:

    $ aws ec2 register-image \
       --region ${AWS_DEFAULT_REGION} \
       --architecture x86_64 \ (1)
       --description "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ (2)
       --ena-support \
       --name "rhcos-${RHCOS_VERSION}-x86_64-aws.x86_64" \ (3)
       --virtualization-type hvm \
       --root-device-name '/dev/xvda' \
       --block-device-mappings 'DeviceName=/dev/xvda,Ebs={DeleteOnTermination=true,SnapshotId=<snapshot_ID>}' (4)
    1 The RHCOS VMDK architecture type, like x86_64, arm64, s390x, or ppc64le.
    2 The Description from the imported snapshot.
    3 The name of the RHCOS AMI.
    4 The SnapshotID from the imported snapshot.

To learn more about these APIs, see the AWS documentation for