// Module included in the following assemblies:
//
// * installing/installing_aws/ipi/installing-aws-outposts.adoc

:_mod-docs-content-type: REFERENCE
[id="aws-outposts-requirements-limitations_{context}"]
= AWS Outposts on {product-title} requirements and limitations

You can manage the resources on your AWS Outpost similarly to those on a cloud-based AWS cluster if you configure your {product-title} cluster to accommodate the following requirements and limitations:

* To extend an {product-title} cluster on AWS into an Outpost, you must have installed the cluster into an existing Amazon Virtual Private Cloud (VPC).

* The infrastructure of an Outpost is tied to an availability zone in an AWS region and uses a dedicated subnet.
Edge compute machines deployed into an Outpost must use the Outpost subnet and the availability zone that the Outpost is tied to.

* When the AWS Kubernetes cloud controller manager discovers an Outpost subnet, it attempts to create service load balancers in the Outpost subnet.
AWS Outposts do not support running service load balancers.
To prevent the cloud controller manager from creating unsupported services in the Outpost subnet, you must include the `kubernetes.io/cluster/unmanaged` tag in the Outpost subnet configuration.
This requirement is a workaround in {product-title} version {product-version}.
For more information, see link:https://issues.redhat.com/browse/OCPBUGS-30041[OCPBUGS-30041].

* {product-title} clusters on AWS include the `gp3-csi` and `gp2-csi` storage classes.
These classes correspond to Amazon Elastic Block Store (EBS) gp3 and gp2 volumes.
{product-title} clusters use the `gp3-csi` storage class by default, but AWS Outposts does not support EBS gp3 volumes.

* This implementation uses the `node-role.kubernetes.io/outposts` taint to prevent spreading regular cluster workloads to the Outpost nodes.
To schedule user workloads in the Outpost, you must specify a corresponding toleration in the `Deployment` resource for your application.
Reserving the AWS Outpost infrastructure for user workloads avoids additional configuration requirements, such as updating the default CSI to `gp2-csi` so that it is compatible.

* To create a volume in the Outpost, the CSI driver requires the Outpost Amazon Resource Name (ARN).
The driver uses the topology keys stored on the `CSINode` objects to determine the Outpost ARN.
To ensure that the driver uses the correct topology values, you must set the volume binding mode to `WaitForConsumer` and avoid setting allowed topologies on any new storage classes that you create.

* When you extend an AWS VPC cluster into an Outpost, you have two types of compute resources.
The Outpost has edge compute nodes, while the VPC has cloud-based compute nodes.
The cloud-based AWS Elastic Block volume cannot attach to Outpost edge compute nodes, and the Outpost volumes cannot attach to cloud-based compute nodes.
+
As a result, you cannot use CSI snapshots to migrate applications that use persistent storage from cloud-based compute nodes to edge compute nodes or directly use the original persistent volume.
To migrate persistent storage data for applications, you must perform a manual backup and restore operation.

* AWS Outposts does not support AWS Network Load Balancers or AWS Classic Load Balancers.
You must use AWS Application Load Balancers to enable load balancing for edge compute resources in the AWS Outposts environment.
+
To provision an Application Load Balancer, you must use an Ingress resource and install the AWS Load Balancer Operator.
If your cluster contains both edge and cloud-based compute instances that share workloads, additional configuration is required.
+
For more information, see "Using the AWS Load Balancer Operator in an AWS VPC cluster extended into an Outpost".
