--- name: satellite-infrastructure-plan title: Planning your environment for Satellite locations description: Learn how to plan your infrastructure environment for IBM Cloud Satellite®, including on-premises data centers, public cloud providers, and edge devices. last-updated: 2026-08-14 --- > ## Documentation Index > The table of contents for this documentation set is at https://cloud.ibm.com/docs/satellite?format=markdown > The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt > Use these files to discover more information as needed. # Planning your environment for Satellite locations {: #infrastructure-plan} Learn how to plan your infrastructure environment for IBM Cloud Satellite®, including on-premises data centers, public cloud providers, and edge devices. {: shortdesc} ## Planning your infrastructure {: #infra-plan-infra} Before you create your location, choose your infrastructure provider, infrastructure zones, and your infrastructure hosts. Your Satellite location starts with your infrastructure, such as a public cloud provider or on-prem. Your infrastructure provides the basis for the hosts and zones that you use to build out your Satellite location. For more information about the different responsibilities for your infrastructure and Satellite resources, see [Your responsibilities](https://cloud.ibm.com/docs/satellite?topic=satellite-responsibilities&format=markdown). ![Concept overview of planning your infrastructure](/images/plan-sat-envirn.svg){: caption="Your Satellite location is built atop the zones and hosts in your infrastructure provider." caption-side="bottom"} ### Plan your infrastructure provider {: #infra-plan-provider} Choose the infrastructure provider that you want to use to create a Satellite location. On-premises : Use a data center with existing infrastructure, or an edge location — such as three racks at one of your company's local sites — that meets the minimum hardware requirements. Supported bare metal servers : You can use a supported bare metal server as a host attached to your Satellite location, including IBM Cloud® Bare Metal Servers for Classic. For more information, see [Bare Metal Server requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-assign-bare-metal&format=markdown#setup-bare-metal). Non-IBM cloud provider : You can use a cloud provider of your choice, such as Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, or Alibaba Cloud. IBM Cloud : [IBM Cloud](https://cloud.ibm.com/docs/satellite?topic=satellite-ibm&format=markdown) is supported for testing purposes. For production environments, the only supported IBM Cloud infrastructure is IBM Cloud® Bare Metal Servers for Classic running Red Hat CoreOS. Other IBM Cloud virtual servers, such as Virtual Servers for VPC, are supported for test environments only. ### Plan for a multizone location {: #infra-plan-multizone} In your infrastructure provider, identify a multizone location that meets the latency requirements. Multizone : A Satellite location requires at least three physically separate zones to distribute hosts evenly for [high availability](https://cloud.ibm.com/docs/satellite?topic=satellite-sat-ha-dr&format=markdown). For example, a cloud provider delivers three different zones within the same region, or an on-premises environment uses three racks with independent networking and power supply systems. Latency between IBM Cloud and the location : The hosts that you want to attach to the Satellite location control plane must have a low latency connection of less than or equal to 200 milliseconds (`<= 200ms`) round trip time (RTT) to the IBM Cloud region that your Satellite location is managed from. As latency increases, you might see impacts to performance, including Satellite Link throughput, Satellite-enabled IBM Cloud service provisioning time, host failure recovery time, and in extreme cases, the availability of resources that run in the Satellite location control plane, such as Red Hat OpenShift cluster masters. For more information, see [Testing the latency between IBM Cloud and the Satellite location control plane hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-host-latency-test&format=markdown#host-latency-mzr). Latency between hosts in your location : Your host infrastructure setup must have a low latency connection of less than or equal to 100 milliseconds (`<= 100ms`) round trip time (RTT) between the hosts that are used for the Satellite location control plane worker nodes and the hosts that are used for other resources in the location, like clusters or [Satellite-enabled IBM Cloud service](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services&format=markdown). For example, in cloud providers such as AWS, this setup typically means that all the hosts in the Satellite location are from the same cloud region, like `us-east-1`. As latency increases, you might see impacts to performance, including provisioning and recovery times, reduced worker nodes in the cluster, Satellite-enabled IBM Cloud service degradation, and in extreme cases, failures in your cluster applications. ### Plan your host systems {: #infra-plan-compatible} In each of the three zones in your infrastructure provider, plan to create compatible hosts to add to Satellite. The host instances in your infrastructure provider become compute hosts for your location control plane or for services running in your Satellite location, filling the same role as worker nodes in a Red Hat OpenShift cluster. - Each host must satisfy the [minimum host requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-host-reqs&format=markdown) for Satellite. - Your hosts must run on [official Red Hat certified hardware](https://catalog.redhat.com/hardware){: external}. To calculate how many hosts you need, see [Sizing your Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-location-sizing&format=markdown). Validate your host setup before attachment using the `satellite-host-check` script. For more information, see [Checking your host setup](https://cloud.ibm.com/docs/satellite?topic=satellite-host-network-check&format=markdown). {: tip} ## Planning your operating system {: #infras-plan-os} Choose your operating system for your hosts. Satellite supports Red Hat Enterprise Linux (RHEL) and Red Hat CoreOS (RHCOS). To use RHCOS hosts for your managed services, create and enable a location for RHCOS support. See [Creating a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-locations&format=markdown). The type of location that you create dictates the type of operating systems that can run on your hosts. If your location is RHCOS enabled, then you can attach hosts that are running either RHEL and RHCOS. If your location isn't RHCOS enabled, then you can attach only hosts that are running RHEL. You can check whether your [location is RHCOS enabled](https://cloud.ibm.com/docs/satellite?topic=satellite-locations&format=markdown#verify-coreos-location). {: note} Red Hat Enterprise Linux 9 : RHEL 9 is a high-performance Linux platform with security and management features to help run your hybrid cloud workloads. Red Hat CoreOS (RHCOS) : RHCOS is a minimal operating system designed for running containerized workloads securely and at scale. Built on RHEL, RHCOS includes automated remote upgrade capabilities that reduce operational overhead. For more information about the key benefits of RHCOS, see [Red Hat Enterprise Linux CoreOS (RHCOS)](https://docs.redhat.com/en/documentation/openshift_container_platform/4.10/html/architecture/architecture-rhcos){: external}. RHCOS is supported for Satellite hosts on Red Hat OpenShift version 4.9 or later. Not all services support RHCOS hosts. For more information, see [Supported Satellite-enabled IBM Cloud services](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services&format=markdown). To attach RHCOS hosts, your location must be [enabled for RHCOS](https://cloud.ibm.com/docs/satellite?topic=satellite-locations&format=markdown#verify-coreos-location). ### Deciding whether to enable Red Hat CoreOS support for your location {: #enable-coreos-loc} When you create a location, you select whether to enable Red Hat CoreOS support. A Red Hat CoreOS-enabled location unlocks more features — including direct link, OpenShift virtualization, and BYOK/KYOK encryption — but requires more infrastructure. A location without Red Hat CoreOS support runs a smaller feature set, but operates at a reduced footprint and supports more clusters per unit of capacity. For a detailed comparison, see [Sizing your Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-location-sizing&format=markdown). The following table shows the features that are available only in Red Hat CoreOS-enabled locations. The table also shows the supported host types that can be used when setting up these features in your Red Hat CoreOS-enabled location. | Feature | Supported host types | | --- | --- | | HTTP proxy for outbound traffic | RHEL or RHCOS hosts | | Bring your own key (BYOK) or keep your own key (KYOK) | RHEL or RHCOS hosts | | Single node cluster topology | RHEL or RHCOS hosts | | Direct link | RHCOS hosts only | | OpenShift virtualization | RHCOS hosts only | {: caption="Supported host types for CoreOS location features" caption-side="bottom"} To verify if you location is enabled for Red Hat CoreOS, see [Is my location enabled for Red Hat CoreOS](https://cloud.ibm.com/docs/satellite?topic=satellite-locations&format=markdown#verify-coreos-location). The bring your own key (BYOK) or keep your own key (KYOK) feature is supported in RHCOS-enabled locations on Red Hat OpenShift on IBM Cloud 4.13 and later, on both RHEL and RHCOS hosts. This feature encrypts cluster secrets only and is not available during cluster or worker pool creation. Enable it after cluster or worker pool creation by running the `ibmcloud oc kms enable` command. This feature cannot be disabled once enabled. {: note} ## Infrastructure credentials {: #sat-infra-creds} For IBM Cloud Satellite to perform actions on your behalf in a cloud provider, you must provide credentials to the cloud provider. ### AWS credentials {: #sat-infra-creds-aws} Retrieve the Amazon Web Services (AWS) credentials that Satellite can use to create Satellite resources in your AWS cloud on your behalf. {: shortdesc} 1. Verify that you have the required [permissions in your AWS account](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-common&format=markdown#permissions-aws) to create a Satellite location from a template. 2. [Create a separate IAM user that is scoped to EC2 access](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html){: external}. 3. [Retrieve the access key ID and secret access key credentials for the IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds.html#access-keys-and-secret-access-keys){: external}. 4. **Optional**: To provide the credentials during the creation of a Satellite location, format the credentials in a JSON file. The `client_id` is the ID of the access key and the `client_secret` is the secret access key that you created for the IAM user in AWS. ```json { "client_id":"string", "client_secret": "string" } ``` {: screen} ### Azure credentials {: #sat-infra-creds-azure} Retrieve the Microsoft Azure credentials that Satellite can use to create Satellite resources in your Azure cloud on your behalf. {: shortdesc} 1. Verify that you have the required [permissions in your Azure account](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-common&format=markdown#permissions-azure) to create a Satellite location from a template. 2. [Sign in to your Azure account](https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli){: external} from the command line. ```sh az login ``` {: pre} 3. List the available subscriptions in your account. ```sh az account list ``` {: pre} 4. Set the subscription to create your Azure resources in. ```sh az account set --subscription="" ``` {: pre} 5. Create a service principal identity with the Contributor role, scoped to your subscription. These credentials are used by IBM Cloud Satellite to provision resources in your Azure account. For more information, see the [Azure documentation](https://learn.microsoft.com/en-us/cli/azure/azure-cli-sp-tutorial-1){: external}. ```sh az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/" -n"" ``` {: pre} 6. In the output, note the values of the `appID`, `password`, and `tenant` fields. ```json { "appId": "", "displayName": "", "name": "http://", "password": "", "tenant": "" } ``` {: screen} 7. **Optional**: To provide the credentials during the creation of a Satellite location, format the credentials in a JSON file. ```json { "app_id":"string", "tenant_id":"string", "password": "string" } ``` {: screen} ### GCP credentials {: #sat-infra-creds-gcp} Retrieve the Google Cloud Platform (GCP) credentials that Satellite can use to create Satellite resources in your GCP cloud on your behalf. {: shortdesc} 1. [Create a service account and service account key](https://docs.cloud.google.com/docs/authentication/client-libraries#creating_a_service_account){: external} with at least the required [GCP permissions](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-common&format=markdown#permissions-gcp). As part of creating the service account, a JSON key file is downloaded to your local machine. 2. Open the JSON key file on your local machine, and verify that the format matches the following example. You can provide this JSON key file as your GCP credentials for actions such as creating a Satellite location. ```json { "type":"string", "project_id":"string", "private_key_id": "string", "private_key": "string", "client_email": "string", "client_id": "string", "auth_uri": "string", "token_uri": "string", "auth_provider_x509_cert_url": "string", "client_x509_cert_url": "string" } ``` {: screen} ### VMWare credentials {: #sat-infra-creds-vmware} Retrieve the VMWare credentials that Satellite can use to create Satellite resources in your VMWare cloud on your behalf. {: shortdesc} 1. Verify that you have the required [permissions in your VMWare account](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-common&format=markdown#permissions-vmware) to create a Satellite location from a template. 2. Identify or [create a user](https://techdocs.broadcom.com/us/en/vmware-cis/cloud-director/vmware-cloud-director/10-6/map-for-vmware-cloud-director-tenant-portal-guide-10-6/managing-users-groups-and-roles-in-vcd-tenant/managing-users-in-your-vcd-tenant-portal-tenant/managing-users-in-your-vcd-tenant-portal-tenant.html){: external} with **Administrator** role. 3. Find your [network information](https://cloud.ibm.com/docs/satellite?topic=satellite-loc-vmware-create-auto&format=markdown#vmware-network). 4. Provide this information on the [VMware Cloud Director template](https://cloud.ibm.com/docs/satellite?topic=satellite-loc-vmware-create-auto&format=markdown#create-auto-vmware).