---
title: Configuring an AWS account
---

# Configuring an AWS account {#installing-aws-account}

To ensure OpenShift Container Platform can successfully install and run the cluster in Amazon Web Services (AWS), you must configure an AWS account with the correct identity and permissions before you start the installation.

## Configuring Route 53 {#installation-aws-route53_installing-aws-account}

To install OpenShift Container Platform, the Amazon Web Services (AWS) account you use must have a dedicated public hosted zone in your Route 53 service. This zone must be authoritative for the domain. The Route 53 service provides cluster DNS resolution and name lookup for external connections to the cluster.

**Procedure**

1. Identify your domain, or subdomain, and registrar. You can transfer an existing domain and registrar or obtain a new one through AWS or another source.

   > [!NOTE]
   > If you purchase a new domain through AWS, it takes time for the relevant DNS changes to propagate. For more information about purchasing domains through AWS, see [Registering Domain Names Using Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html) in the AWS documentation.
2. If you are using an existing domain and registrar, migrate its DNS to AWS. See [Making Amazon Route 53 the DNS Service for an Existing Domain](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/MigratingDNS.html) in the AWS documentation.
3. Create a public hosted zone for your domain or subdomain. See [Creating a Public Hosted Zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html) in the AWS documentation.

   Use an appropriate root domain, such as `openshiftcorp.com`, or subdomain, such as `clusters.openshiftcorp.com`.
4. Extract the new authoritative name servers from the hosted zone records. See [Getting the Name Servers for a Public Hosted Zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/GetInfoAboutHostedZone.html) in the AWS documentation.
5. Update the registrar records for the AWS Route 53 name servers that your domain uses. For example, if you registered your domain to a Route 53 service in a different accounts, see the following topic in the AWS documentation: [Adding or Changing Name Servers or Glue Records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-name-servers-glue-records.html#domain-name-servers-glue-records-procedure).
6. If you are using a subdomain, add its delegation records to the parent domain. This gives Amazon Route 53 responsibility for the subdomain. Follow the delegation procedure outlined by the DNS provider of the parent domain. See [Creating a subdomain that uses Amazon Route 53 as the DNS service without migrating the parent domain](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) in the AWS documentation for an example high level procedure.

### Ingress Operator endpoint configuration for AWS Route 53 {#nw-endpoint-route53_installing-aws-account}

Configure Ingress Operator endpoints for OpenShift Container Platform clusters in Amazon Web Services (AWS) GovCloud (US) regions. Verifying these settings helps to ensure that your cluster connects to the correct API endpoints.

If you install in either AWS GovCloud (US) US-West or US-East region, the Ingress Operator uses `us-gov-west-1` region for Route53 and tagging API clients.

The Ingress Operator uses `https://tagging.us-gov-west-1.amazonaws.com` as the tagging API endpoint if a tagging custom endpoint is configured that includes the string 'us-gov-east-1'.

For more information on AWS GovCloud (US) endpoints, see the [Service Endpoints](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/using-govcloud-endpoints.html) in the AWS documentation about GovCloud (US).

> [!IMPORTANT]
> Private, disconnected installations are not supported for AWS GovCloud when you install in the `us-gov-east-1` region.

```yaml {title="Example Route 53 configuration"}
platform:
  aws:
    region: us-gov-west-1
    serviceEndpoints:
    - name: ec2
      url: https://ec2.us-gov-west-1.amazonaws.com
    - name: elasticloadbalancing
      url: https://elasticloadbalancing.us-gov-west-1.amazonaws.com
    - name: route53
      url: https://route53.us-gov.amazonaws.com
    - name: tagging
      url: https://tagging.us-gov-west-1.amazonaws.com
```

where:

`https://route53.us-gov.amazonaws.com`
:   Defaults to `https://route53.us-gov.amazonaws.com` for both AWS GovCloud (US) regions.

`https://tagging.us-gov-west-1.amazonaws.com`
:   Only the US-West region has endpoints for tagging. Omit this parameter if your cluster is in another region.

## AWS account limits {#installation-aws-limits_installing-aws-account}

The OpenShift Container Platform cluster uses several Amazon Web Services (AWS) components, and the default service limits affect your ability to install OpenShift Container Platform clusters.

If you use certain cluster configurations, deploy your cluster in certain AWS regions, or run multiple clusters from your account, you might need to request additional resources for your AWS account.

The following table summarizes the AWS  components whose limits can impact your ability to install and run OpenShift Container Platform clusters.

<table>
<thead>
<tr>
  <th>Component</th>
  <th>Number of clusters available by default</th>
  <th>Default AWS limit</th>
  <th>Description</th>
</tr>
</thead>
<tbody>
<tr>
  <td>Instance Limits</td>
  <td>Varies</td>
  <td>Varies</td>
  <td>By default, each cluster creates the following instances:<br><br><ul><li>One bootstrap machine, which is removed after installation</li><li>Three control plane nodes</li><li>Three worker nodes</li></ul>These instance type counts are within a new account's default limit. To deploy more worker nodes, enable autoscaling, deploy large workloads, or use a different instance type, review your account limits to ensure that your cluster can deploy the machines that you need.<br><br>In most regions, the worker machines use an <code>m6i.large</code> instance and the bootstrap and control plane machines use <code>m6i.xlarge</code> instances. In some regions, including all regions that do not support these instance types, <code>m5.large</code> and <code>m5.xlarge</code> instances are used instead.</td>
</tr>
<tr>
  <td>Elastic IPs (EIPs)</td>
  <td>0 to 1</td>
  <td>5 EIPs per account</td>
  <td>To provision the cluster in a highly available configuration, the installation program creates a public and private subnet for each availability zone within a region. Each private subnet requires a NAT gateway, and each NAT gateway requires a separate elastic IP. Review the AWS region map to determine how many availability zones are in each region. To take advantage of the default high availability, install the cluster in a region with at least three availability zones. To install a cluster in a region with more than five availability zones, you must increase the EIP limit.<br><br><dl class="db-admonition db-admonition-important"><dt>Important</dt><dd>To use the <code>us-east-1</code> region, you must increase the EIP limit for your account.</dd></dl></td>
</tr>
<tr>
  <td>Virtual Private Clouds (VPCs)</td>
  <td>5</td>
  <td>5 VPCs per region</td>
  <td>Each cluster creates its own VPC.</td>
</tr>
<tr>
  <td>Elastic Load Balancing (ELB/NLB)</td>
  <td>3</td>
  <td>20 per region</td>
  <td>By default, each cluster creates internal and external network load balancers for the master API server and a single Classic Load Balancer for the router. Deploying more Kubernetes <code>Service</code> objects with type <code>LoadBalancer</code> will create additional load balancers.</td>
</tr>
<tr>
  <td>NAT Gateways</td>
  <td>5</td>
  <td>5 per availability zone</td>
  <td>The cluster deploys one NAT gateway in each availability zone.</td>
</tr>
<tr>
  <td>Elastic Network Interfaces (ENIs)</td>
  <td>At least 12</td>
  <td>350 per region</td>
  <td>The default installation creates 21 ENIs and an ENI for each availability zone in your region. For example, the <code>us-east-1</code> region contains six availability zones, so a cluster that is deployed in that zone uses 27 ENIs. Review the AWS region map to determine how many availability zones are in each region.<br><br>Additional ENIs are created for additional machines and ELB load balancers that are created by cluster usage and deployed workloads.</td>
</tr>
<tr>
  <td>VPC Gateway</td>
  <td>20</td>
  <td>20 per account</td>
  <td>Each cluster creates a single VPC Gateway for S3 access.</td>
</tr>
<tr>
  <td>S3 buckets</td>
  <td>99</td>
  <td>100 buckets per account</td>
  <td>Because the installation process creates a temporary bucket and the registry component in each cluster creates a bucket, you can create only 99 OpenShift Container Platform clusters per AWS account.</td>
</tr>
<tr>
  <td>Security Groups</td>
  <td>250</td>
  <td>2,500 per account</td>
  <td>Each cluster creates 10 distinct security groups.</td>
</tr>
<tr>
  <td>Security Groups on network interfaces</td>
  <td>Varies</td>
  <td>5 per network interface</td>
  <td>By default, AWS allows 5 security groups per network interface. The installation program creates 2 security groups for compute machines and 3 security groups for control plane machines. If you are installing a cluster into a shared VPC, there are three scenarios in which you must increase this quota:<br><br><ul><li>You specified 4 or more custom security groups for compute machines using the <code>compute.platform.aws.additionalSecurityGroupIDs</code> parameter in the <code>install-config.yaml</code> file.</li><li>You specified 3 or more custom security groups for control plane machines using the <code>controlPlane.platform.aws.additionalSecurityGroupIDs</code> parameter in the <code>install-config.yaml</code> file.</li><li>You specified 3 or more custom security groups for all machines using the <code>platform.aws.defaultMachinePlatform</code> parameter in the <code>install-config.yaml</code> file.</li></ul>You must increase the quota of security groups per network interface to a number greater than or equal to <code>3 + (number of control plane custom security groups OR number of default machine platform custom security groups)</code>, or <code>2 + (number of compute custom security groups OR number of default machine platform custom security groups)</code>, whichever is higher. If you do not specify a sufficient quota, the installation will succeed, but it will generate <code>SecurityGroupsPerInterfaceLimitExceeded</code> errors in the installation log, and the additional security groups will not be applied. The maximum allowed quota is 16 and the maximum number of user-specified security groups is 10.</td>
</tr>
</tbody>
</table>

**Additional resources**
{._additional-resources}

- [Service Limits (AWS documentation)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
- [Regions and Zones (AWS documentation)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)
- [NAT Gateways (AWS documentation)](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)
- [Elastic IP Addresses (AWS documentation)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)
- [Region map (AWS documentation)](https://aws.amazon.com/about-aws/global-infrastructure)
- [Elastic load balancing (AWS documentation)](https://aws.amazon.com/elasticloadbalancing)

## Required AWS permissions for the IAM user {#installation-aws-permissions_installing-aws-account}

To deploy all components of an OpenShift Container Platform cluster, you must grant all the required permissions to the IAM user that you create in Amazon Web Services (AWS).

> [!NOTE]
> Your IAM user must have the permission `tag:GetResources` in the region `us-east-1` to delete the base cluster resources. As part of the AWS API requirement, the OpenShift Container Platform installation program performs various actions in this region.

When you attach the `AdministratorAccess` policy to the IAM user that you create in AWS, you grant that user all of the required permissions. To deploy all components of an OpenShift Container Platform cluster, the IAM user requires the following permissions:

**Required EC2 permissions for installation**

- `ec2:AttachNetworkInterface`
- `ec2:AuthorizeSecurityGroupEgress`
- `ec2:AuthorizeSecurityGroupIngress`
- `ec2:CopyImage`
- `ec2:CreateNetworkInterface`
- `ec2:CreateSecurityGroup`
- `ec2:CreateTags`
- `ec2:CreateVolume`
- `ec2:DeleteSecurityGroup`
- `ec2:DeleteSnapshot`
- `ec2:DeleteTags`
- `ec2:DeregisterImage`
- `ec2:DescribeAccountAttributes`
- `ec2:DescribeAddresses`
- `ec2:DescribeAvailabilityZones`
- `ec2:DescribeDhcpOptions`
- `ec2:DescribeImages`
- `ec2:DescribeInstanceAttribute`
- `ec2:DescribeInstanceCreditSpecifications`
- `ec2:DescribeInstances`
- `ec2:DescribeInstanceTypes`
- `ec2:DescribeInstanceTypeOfferings`
- `ec2:DescribeInternetGateways`
- `ec2:DescribeKeyPairs`
- `ec2:DescribeNatGateways`
- `ec2:DescribeNetworkAcls`
- `ec2:DescribeNetworkInterfaces`
- `ec2:DescribePrefixLists`
- `ec2:DescribePublicIpv4Pools` (only required if you specify `publicIpv4Pool` in `install-config.yaml`)
- `ec2:DescribeRegions`
- `ec2:DescribeRouteTables`
- `ec2:DescribeSecurityGroupRules`
- `ec2:DescribeSecurityGroups`
- `ec2:DescribeSubnets`
- `ec2:DescribeTags`
- `ec2:DescribeVolumes`
- `ec2:DescribeVpcAttribute`
- `ec2:DescribeVpcClassicLink`
- `ec2:DescribeVpcClassicLinkDnsSupport`
- `ec2:DescribeVpcEndpoints`
- `ec2:DescribeVpcs`
- `ec2:DisassociateAddress` (only required if you specify `publicIpv4Pool` in `install-config.yaml`)
- `ec2:GetEbsDefaultKmsKeyId`
- `ec2:ModifyInstanceAttribute`
- `ec2:ModifyNetworkInterfaceAttribute`
- `ec2:RevokeSecurityGroupEgress`
- `ec2:RevokeSecurityGroupIngress`
- `ec2:RunInstances`
- `ec2:TerminateInstances`

**Required permissions for creating network resources during installation**

- `ec2:AllocateAddress`
- `ec2:AssociateAddress`
- `ec2:AssociateDhcpOptions`
- `ec2:AssociateRouteTable`
- `ec2:AttachInternetGateway`
- `ec2:CreateDhcpOptions`
- `ec2:CreateInternetGateway`
- `ec2:CreateNatGateway`
- `ec2:CreateRoute`
- `ec2:CreateRouteTable`
- `ec2:CreateSubnet`
- `ec2:CreateVpc`
- `ec2:CreateVpcEndpoint`
- `ec2:ModifySubnetAttribute`
- `ec2:ModifyVpcAttribute`

> [!NOTE]
> If you use an existing Virtual Private Cloud (VPC), your account does not require these permissions for creating network resources.

**Required Elastic Load Balancing permissions (ELB) for installation**

- `elasticloadbalancing:AddTags`
- `elasticloadbalancing:ApplySecurityGroupsToLoadBalancer`
- `elasticloadbalancing:AttachLoadBalancerToSubnets`
- `elasticloadbalancing:ConfigureHealthCheck`
- `elasticloadbalancing:CreateListener`
- `elasticloadbalancing:CreateLoadBalancer`
- `elasticloadbalancing:CreateLoadBalancerListeners`
- `elasticloadbalancing:CreateTargetGroup`
- `elasticloadbalancing:DeleteLoadBalancer`
- `elasticloadbalancing:DeregisterInstancesFromLoadBalancer`
- `elasticloadbalancing:DeregisterTargets`
- `elasticloadbalancing:DescribeInstanceHealth`
- `elasticloadbalancing:DescribeListeners`
- `elasticloadbalancing:DescribeLoadBalancerAttributes`
- `elasticloadbalancing:DescribeLoadBalancers`
- `elasticloadbalancing:DescribeTags`
- `elasticloadbalancing:DescribeTargetGroupAttributes`
- `elasticloadbalancing:DescribeTargetHealth`
- `elasticloadbalancing:ModifyLoadBalancerAttributes`
- `elasticloadbalancing:ModifyTargetGroup`
- `elasticloadbalancing:ModifyTargetGroupAttributes`
- `elasticloadbalancing:RegisterInstancesWithLoadBalancer`
- `elasticloadbalancing:RegisterTargets`
- `elasticloadbalancing:SetLoadBalancerPoliciesOfListener`
- `elasticloadbalancing:SetSecurityGroups`

> [!IMPORTANT]
> OpenShift Container Platform uses both the ELB and ELBv2 API services to provision load balancers. The permission list shows permissions required by both services. A known issue exists in the AWS web console where both services use the same `elasticloadbalancing` action prefix but do not recognize the same actions. You can ignore the warnings about the service not recognizing certain `elasticloadbalancing` actions.

**Required IAM permissions for installation**

- `iam:AddRoleToInstanceProfile`
- `iam:CreateInstanceProfile`
- `iam:CreateRole`
- `iam:DeleteInstanceProfile`
- `iam:DeleteRole`
- `iam:DeleteRolePolicy`
- `iam:GetInstanceProfile`
- `iam:GetRole`
- `iam:GetRolePolicy`
- `iam:GetUser`
- `iam:ListInstanceProfilesForRole`
- `iam:ListRoles`
- `iam:ListUsers`
- `iam:PassRole`
- `iam:PutRolePolicy`
- `iam:RemoveRoleFromInstanceProfile`
- `iam:SimulatePrincipalPolicy`
- `iam:TagInstanceProfile`
- `iam:TagRole`

> [!NOTE]
> - If you specify an existing IAM role in the `install-config.yaml` file, the following IAM permissions are not required: `iam:CreateRole`,`iam:DeleteRole`, `iam:DeleteRolePolicy`, and `iam:PutRolePolicy`.
> - If you have not created a load balancer in your AWS account, the IAM user also requires the `iam:CreateServiceLinkedRole` permission.

**Required Route 53 permissions for installation**

- `route53:ChangeResourceRecordSets`
- `route53:ChangeTagsForResource`
- `route53:CreateHostedZone`
- `route53:DeleteHostedZone`
- `route53:GetChange`
- `route53:GetHostedZone`
- `route53:ListHostedZones`
- `route53:ListHostedZonesByName`
- `route53:ListResourceRecordSets`
- `route53:ListTagsForResource`
- `route53:UpdateHostedZoneComment`

**Required Amazon Simple Storage Service (S3) permissions for installation**

- `s3:CreateBucket`
- `s3:DeleteBucket`
- `s3:GetAccelerateConfiguration`
- `s3:GetBucketAcl`
- `s3:GetBucketCors`
- `s3:GetBucketLocation`
- `s3:GetBucketLogging`
- `s3:GetBucketObjectLockConfiguration`
- `s3:GetBucketPolicy`
- `s3:GetBucketRequestPayment`
- `s3:GetBucketTagging`
- `s3:GetBucketVersioning`
- `s3:GetBucketWebsite`
- `s3:GetEncryptionConfiguration`
- `s3:GetLifecycleConfiguration`
- `s3:GetReplicationConfiguration`
- `s3:ListBucket`
- `s3:PutBucketAcl`
- `s3:PutBucketPolicy`
- `s3:PutBucketTagging`
- `s3:PutEncryptionConfiguration`

**S3 permissions that cluster Operators require**

- `s3:DeleteObject`
- `s3:GetObject`
- `s3:GetObjectAcl`
- `s3:GetObjectTagging`
- `s3:GetObjectVersion`
- `s3:PutObject`
- `s3:PutObjectAcl`
- `s3:PutObjectTagging`

**Required permissions to delete base cluster resources**

- `autoscaling:DescribeAutoScalingGroups`
- `ec2:DeleteNetworkInterface`
- `ec2:DeletePlacementGroup`
- `ec2:DeleteVolume`
- `elasticloadbalancing:DeleteTargetGroup`
- `elasticloadbalancing:DescribeTargetGroups`
- `iam:DeleteAccessKey`
- `iam:DeleteUser`
- `iam:DeleteUserPolicy`
- `iam:ListAttachedRolePolicies`
- `iam:ListInstanceProfiles`
- `iam:ListRolePolicies`
- `iam:ListUserPolicies`
- `s3:DeleteObject`
- `s3:ListBucketVersions`
- `tag:GetResources`

**Required permissions to delete network resources**

- `ec2:DeleteDhcpOptions`
- `ec2:DeleteInternetGateway`
- `ec2:DeleteNatGateway`
- `ec2:DeleteRoute`
- `ec2:DeleteRouteTable`
- `ec2:DeleteSubnet`
- `ec2:DeleteVpc`
- `ec2:DeleteVpcEndpoints`
- `ec2:DetachInternetGateway`
- `ec2:DisassociateRouteTable`
- `ec2:ReleaseAddress`
- `ec2:ReplaceRouteTableAssociation`

> [!NOTE]
> If you use an existing VPC, your account does not require these permissions to delete network resources. Instead, your account only requires the `tag:UntagResources` permission to delete network resources.

**Optional permissions for installing a cluster with a custom Key Management Service (KMS) key**

- `kms:CreateGrant`
- `kms:Decrypt`
- `kms:DescribeKey`
- `kms:Encrypt`
- `kms:GenerateDataKey`
- `kms:GenerateDataKeyWithoutPlainText`
- `kms:ListGrants`
- `kms:RevokeGrant`

> [!NOTE]
> If you use an Amazon Machine Image (AMI) encrypted with a customer-managed key, you must grant the `kms:ReEncrypt*` permissions in addition to these permissions.

**Required permissions to delete a cluster with shared instance roles**

- `iam:UntagRole`

**Required permissions to delete a cluster with shared instance profiles**

- `tag:UntagResources`

**Additional IAM and S3 permissions required to create manifests**

- `iam:GetUserPolicy`
- `iam:ListAccessKeys`
- `iam:PutUserPolicy`
- `iam:TagUser`
- `s3:AbortMultipartUpload`
- `s3:GetBucketPublicAccessBlock`
- `s3:ListBucket`
- `s3:ListBucketMultipartUploads`
- `s3:PutBucketPublicAccessBlock`
- `s3:PutLifecycleConfiguration`

> [!NOTE]
> If you are managing your cloud provider credentials with mint mode, the IAM user also requires the `iam:CreateAccessKey` and `iam:CreateUser` permissions.

**Optional permissions for instance and quota checks for installation**

- `servicequotas:ListAWSDefaultServiceQuotas`

**Optional permissions for the cluster owner account when installing a cluster on a shared VPC**

- `sts:AssumeRole`

**Required permissions for enabling Bring your own public IPv4 addresses (BYOIP) feature for installation**

- `ec2:DescribePublicIpv4Pools`
- `ec2:DisassociateAddress`

**Required permissions to install a cluster with dual-stack networking**

- `ec2:DescribeEgressOnlyInternetGateways`
- `ec2:CreateEgressOnlyInternetGateway`

**Required permissions to delete a cluster with dual-stack networking**

- `ec2:DeleteEgressOnlyInternetGateway`

## Creating an IAM user {#installation-aws-iam-user_installing-aws-account}

Before you install OpenShift Container Platform, you must create a secondary IAM administrative user and assign permissions to create the cluster.

Each Amazon Web Services (AWS) account contains a root user account that is based on the email address you used to create the account.

> [!IMPORTANT]
> This is a highly-privileged account, and it is recommended to use it for only initial account and billing configuration, creating an initial set of users, and securing the account.

As you complete the [Creating an IAM User in Your AWS Account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) procedure in the Amazon Web Services (AWS) documentation, set the following options:

**Procedure**

1. Specify the IAM user name and select `Programmatic access`.
2. Attach the `AdministratorAccess` policy to ensure that the account has sufficient permission to create the cluster. This policy provides the cluster with the ability to grant credentials to each OpenShift Container Platform component. The cluster grants the components only the credentials that they require.

   > [!NOTE]
   > While it is possible to create a policy that grants the all of the required AWS permissions and attach it to the user, this is not the preferred option. The cluster will not have the ability to grant additional credentials to individual components, so the same credentials are used by all components.
3. Optional: Add metadata to the user by attaching tags.
4. Confirm that the user name that you specified is granted the `AdministratorAccess` policy.
5. Record the access key ID and secret access key values. You must use these values when you configure your local machine to run the installation program.

   > [!IMPORTANT]
   > You cannot use a temporary session token that you generated while using a multi-factor authentication device to authenticate to AWS when you deploy a cluster. 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.

## IAM Policies and AWS authentication {#iam-policies-and-aws-authentication_installing-aws-account}

You can specify your own IAM roles if required. By default, the installation program creates instance profiles for the bootstrap, control plane, and compute instances with the necessary permissions for the cluster to operate.

> [!NOTE]
> To enable pulling images from the Amazon Elastic Container Registry (ECR) as a postinstallation task in a single-node OpenShift cluster, you must add the `AmazonEC2ContainerRegistryReadOnly` policy to the IAM role associated with the cluster’s control plane role.

However, you can create your own IAM roles and specify them as part of the installation process. You might need to specify your own roles to deploy the cluster or to manage the cluster after installation. For example:

- Your organization’s security policies require that you use a more restrictive set of permissions to install the cluster.
- After the installation, the cluster is configured with an Operator that requires access to additional services.

If you choose to specify your own IAM roles, you can take the following steps:

- Begin with the default policies and adapt as required. For more information, see "Default permissions for IAM instance profiles".
- To create a policy template that is based on the cluster’s activity, see "Using AWS IAM Analyzer to create policy templates".

### Default permissions for IAM instance profiles {#installation-aws-permissions-iam-roles_installing-aws-account}

To ensure your cluster operates with the correct security permissions in OpenShift Container Platform, review the default IAM instance profiles created by the installation program.

By default, the installation program creates IAM instance profiles for the bootstrap, control plane, and compute instances with the necessary permissions for the cluster to operate.

The following list specifies the default IAM role permissions for control plane instance profiles:

- `ec2:AttachVolume`
- `ec2:AuthorizeSecurityGroupIngress`
- `ec2:CreateSecurityGroup`
- `ec2:CreateTags`
- `ec2:CreateVolume`
- `ec2:DeleteSecurityGroup`
- `ec2:DeleteVolume`
- `ec2:Describe*`
- `ec2:DetachVolume`
- `ec2:ModifyInstanceAttribute`
- `ec2:ModifyVolume`
- `ec2:RevokeSecurityGroupIngress`
- `elasticloadbalancing:AddTags`
- `elasticloadbalancing:AttachLoadBalancerToSubnets`
- `elasticloadbalancing:ApplySecurityGroupsToLoadBalancer`
- `elasticloadbalancing:CreateListener`
- `elasticloadbalancing:CreateLoadBalancer`
- `elasticloadbalancing:CreateLoadBalancerPolicy`
- `elasticloadbalancing:CreateLoadBalancerListeners`
- `elasticloadbalancing:CreateTargetGroup`
- `elasticloadbalancing:ConfigureHealthCheck`
- `elasticloadbalancing:DeleteListener`
- `elasticloadbalancing:DeleteLoadBalancer`
- `elasticloadbalancing:DeleteLoadBalancerListeners`
- `elasticloadbalancing:DeleteTargetGroup`
- `elasticloadbalancing:DeregisterInstancesFromLoadBalancer`
- `elasticloadbalancing:DeregisterTargets`
- `elasticloadbalancing:Describe*`
- `elasticloadbalancing:DetachLoadBalancerFromSubnets`
- `elasticloadbalancing:ModifyListener`
- `elasticloadbalancing:ModifyLoadBalancerAttributes`
- `elasticloadbalancing:ModifyTargetGroup`
- `elasticloadbalancing:ModifyTargetGroupAttributes`
- `elasticloadbalancing:RegisterInstancesWithLoadBalancer`
- `elasticloadbalancing:RegisterTargets`
- `elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer`
- `elasticloadbalancing:SetLoadBalancerPoliciesOfListener`
- `kms:DescribeKey`

The following list specifies the default IAM permissions for compute instance profiles:

- `ec2:DescribeInstances`
- `ec2:DescribeRegions`

### Specifying an existing IAM role {#specify-an-existing-iam-role_installing-aws-account}

Instead of allowing the installation program to create IAM instance profiles with the default permissions, you can use the `install-config.yaml` file to specify an existing IAM role for control plane and compute instances.

**Prerequisites**

- You have an existing `install-config.yaml` file.

**Procedure**

1. Update `compute.platform.aws.iamRole` with an existing role for the compute machines.

   ```yaml {title="Sample install-config.yaml file with an IAM role for compute instances"}
   compute:
   - hyperthreading: Enabled
     name: worker
     platform:
       aws:
         iamRole: ExampleRole
   ```
2. Update `controlPlane.platform.aws.iamRole` with an existing role for the control plane machines.

   ```yaml {title="Sample install-config.yaml file with an IAM role for control plane instances"}
   controlPlane:
     hyperthreading: Enabled
     name: master
     platform:
       aws:
         iamRole: ExampleRole
   ```
3. Save the file and reference it when installing the OpenShift Container Platform cluster.

   > [!NOTE]
   > To change or update an IAM account after the cluster has been installed, see [RHOCP 4 AWS cloud-credentials access key is expired](https://access.redhat.com/solutions/4284011) (Red Hat Knowledgebase).

**Additional resources**
{._additional-resources}

- [Deploying the cluster](/openshift-docs-markdown/installing/installing_aws/ipi/installing-aws-customizations#installation-launching-installer_installing-aws-customizations)

### Using AWS IAM Analyzer to create policy templates {#create-custom-permissions-for-iam-instance-profiles_installing-aws-account}

To reduce security risk, you can use AWS IAM Access Analyzer and CloudTrail to generate and apply minimal, fine-grained IAM policies for cluster control plane and compute instance profiles.

The minimal set of permissions that the control plane and compute instance profiles require depends on how the cluster is configured for its daily operation.

One way to determine which permissions the cluster instances require is to use the AWS Identity and Access Management Access Analyzer (IAM Access Analyzer) to create a policy template:

- A policy template contains the permissions the cluster has used over a specified period of time.
- You can then use the template to create policies with fine-grained permissions.

**Procedure**

1. Ensure that CloudTrail is enabled. CloudTrail records all of the actions and events in your AWS account, including the API calls that are required to create a policy template. For more information, see the AWS documentation for [working with CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-getting-started.html).
2. Create an instance profile for control plane instances and an instance profile for compute instances. Be sure to assign each role a permissive policy, such as PowerUserAccess. For more information, see the AWS documentation for [creating instance profile roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html).
3. Install the cluster in a development environment and configure it as required. Be sure to deploy all of applications the cluster will host in a production environment.
4. Test the cluster thoroughly. Testing the cluster ensures that all of the required API calls are logged.
5. Use the IAM Access Analyzer to create a policy template for each instance profile. For more information, see the AWS documentation for [generating policies based on the CloudTrail logs](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html).
6. Create and add a fine-grained policy to each instance profile.
7. Remove the permissive policy from each instance profile.
8. Deploy a production cluster using the existing instance profiles with the new policies.

   > [!NOTE]
   > You can add [IAM Conditions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) to your policy to make it more restrictive and compliant with your organization security requirements.

## Supported AWS Marketplace regions {#installation-aws-marketplace_installing-aws-account}

Installing an OpenShift Container Platform cluster using an AWS Marketplace image is available to customers who purchase the offer in North America.

While the offer must be purchased in North America, you can deploy the cluster to any of the following supported partitions:

- Public
- GovCloud

> [!NOTE]
> Deploying a OpenShift Container Platform cluster using an AWS Marketplace image is not supported for the AWS secret regions or China regions.

## Supported AWS regions {#installation-aws-regions_installing-aws-account}

You can deploy an OpenShift Container Platform cluster to the following regions.

> [!NOTE]
> Your IAM user must have the permission `tag:GetResources` in the region `us-east-1` to delete the base cluster resources. As part of the AWS API requirement, the OpenShift Container Platform installation program performs various actions in this region.

### AWS public regions {#installation-aws-public_installing-aws-account}

The following AWS public regions are supported:

- `af-south-1` (Cape Town)
- `ap-east-1` (Hong Kong)
- `ap-east-2` (Taipei)
- `ap-northeast-1` (Tokyo)
- `ap-northeast-2` (Seoul)
- `ap-northeast-3` (Osaka)
- `ap-south-1` (Mumbai)
- `ap-south-2` (Hyderabad)
- `ap-southeast-1` (Singapore)
- `ap-southeast-2` (Sydney)
- `ap-southeast-3` (Jakarta)
- `ap-southeast-4` (Melbourne)
- `ap-southeast-5` (Malaysia)
- `ap-southeast-6` (New Zealand)
- `ap-southeast-7` (Thailand)
- `ca-central-1` (Central Canada)
- `ca-west-1` (Calgary)
- `eu-central-1` (Frankfurt)
- `eu-central-2` (Zurich)
- `eu-north-1` (Stockholm)
- `eu-south-1` (Milan)
- `eu-south-2` (Spain)
- `eu-west-1` (Ireland)
- `eu-west-2` (London)
- `eu-west-3` (Paris)
- `il-central-1` (Tel Aviv)
- `me-central-1` (UAE)
- `me-south-1` (Bahrain)
- `mx-central-1` (Central Mexico)
- `sa-east-1` (São Paulo)
- `us-east-1` (N. Virginia)
- `us-east-2` (Ohio)
- `us-west-1` (N. California)
- `us-west-2` (Oregon)

### AWS EUSC region {#installation-aws-eusc_region_installing-aws-account}

> [!IMPORTANT]
> European Sovereign Cloud (EUSC) region is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
>
> For more information about the support scope of Red Hat Technology Preview features, see [Technology Preview Features Support Scope](https://access.redhat.com/support/offerings/techpreview/).

Installing an OpenShift Container Platform cluster into the AWS European Sovereign Cloud (EUSC) region helps maximize the sovereignty of your data and satisfy your organization’s regulatory requirements. The AWS EUSC is separate and independent from other AWS regions. The infrastructure is located wholly within the European Union (EU). For more information, see [Establishing a European trust service provider for the AWS European Sovereign Cloud](https://aws.amazon.com/blogs/security/establishing-a-european-trust-service-provider-for-the-aws-european-sovereign-cloud/) in the AWS documentation.

The following AWS EUSC region is supported:

- `eusc-de-east-1` (Brandenburg)

> [!IMPORTANT]
> The following list outlines the limitations that apply to installing an OpenShift Container Platform cluster into the AWS EUSC region:
>
> - Only one region, `eusc-de-east-1`, and two zones in that region are available.
> - The Amazon Machine Images (AMIs) for public Red Hat Enterprise Linux CoreOS (RHCOS) are not yet available in the EUSC region. As a workaround, until the AMI publication for RHCOS is extended to the EUSC region, you must edit your `install-config.yaml` file to specify a custom AMI in the `amiID` field.
> - Support is not yet provided for the AWS Security Token Service (STS).
> - Support is not yet provided for installing a cluster into a shared Virtual Private Cloud (VPC) with a cross-account private hosted zone.

### AWS GovCloud regions {#installation-aws-govcloud_installing-aws-account}

The following AWS GovCloud regions are supported:

- `us-gov-west-1`
- `us-gov-east-1`

### AWS SC2S and C2S secret regions {#installation-aws-c2s_installing-aws-account}

The following AWS secret regions are supported:

- `us-isob-east-1` Secret Commercial Cloud Services (SC2S)
- `us-iso-east-1` Commercial Cloud Services (C2S)

### AWS China regions {#installation-aws-china_installing-aws-account}

The following AWS China regions are supported:

- `cn-north-1` (Beijing)
- `cn-northwest-1` (Ningxia)

**Additional resources**
{._additional-resources}

- [Quickly install a cluster](/openshift-docs-markdown/installing/installing_aws/ipi/installing-aws-default#installing-aws-default)
- [Install a cluster with cloud customizations on installer-provisioned infrastructure](/openshift-docs-markdown/installing/installing_aws/ipi/installing-aws-customizations#installing-aws-customizations)
- [Installing a cluster on user-provisioned infrastructure in AWS by using CloudFormation templates](/openshift-docs-markdown/installing/installing_aws/upi/installing-aws-user-infra#installing-aws-user-infra)
