> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/v1/dataos-operator/provision-data-plane/aws-ui.md).
# AWS (UI)
Use the guided Provision BYOC Dataplane flow in the DataOS UI to provision a Data Plane on an existing Amazon Elastic Kubernetes Service (EKS) cluster. Complete five short screens, and then DataOS assembles, validates, and applies the Data Plane configuration.
{% hint style="info" %}
To create a Data Plane through the DataOS CLI, follow the [AWS provisioning guide](/operate/v1/dataos-operator/provision-data-plane/aws.md).
{% endhint %}
### Before you begin
You need an existing **DataOS Instance** and **Super User** and **Operator access** to the Tenant where you want to provision the Data Plane.
### Provision the Data Plane
1. Sign in to your DataOS Instance.
2. Go to **Instance Admin → Dataplanes**.
3. Select **+ Provision Dataplane**.
The provisioning wizard consists of the following steps:
1. Prerequisites
2. Identity
3. Cluster Access
4. Node Pool
5. PostgreSQL
#### 1. Prerequisites
The first screen provides a checklist of the infrastructure and access required to provision the Data Plane. Ensure that the following are available before continuing.
**Kubernetes cluster**
* A dedicated Kubernetes cluster to host the Data Plane.
* Administrative access to the cluster.
* Sufficient node-pool capacity for the DataOS components.
* A kubeconfig for the cluster.
The kubeconfig must be base64-encoded before you provide it in the **Cluster Access** step.
Generate the kubeconfig
If you already have a valid kubeconfig with the required cluster access, you can use it directly.
For an Amazon EKS cluster, you can generate or update the kubeconfig using the AWS CLI:
```bash
aws sts get-caller-identity
aws eks update-kubeconfig --region --name
```
Verify that the resulting kubeconfig can access the cluster:
```bash
kubectl get nodes
```
The identity used by the kubeconfig must have the required Kubernetes RBAC permissions to access the cluster. For EKS, this access can be configured through an EKS access entry or `aws-auth`, as applicable to your cluster configuration.
Encode the kubeconfig
Encode the kubeconfig as a single-line Base64 value before pasting it into the UI.
The encoding command differs by operating system, because `base64` takes different flags on each and Windows has no `base64` at all. Run the one that matches the machine you are working from.
kubectl config view --minify --flatten | base64 | tr -d '\n'kubectl config view --minify --flatten | base64 -w 0\[Convert]::ToBase64String( \[Text.Encoding]::UTF8.GetBytes( (kubectl config view --minify --flatten | Out-String) ))
Copy the output as a single line, with no line breaks. This value gives the DataOS Instance access to the EKS API, so treat it as a secret.
**PostgreSQL**
Provide an existing PostgreSQL server with the required databases already created.
The current flow requires two databases:
* **System Health database:** Used for Data Plane health tracking.
* **Vesta database:** Used as the Vesta state store.
Keep the connection details and credentials for both databases ready. You provide them in Step 5.
**Cloud credentials**
For AWS Data Planes, provide:
* `AWS_ACCESS_KEY_ID`
* `AWS_SECRET_ACCESS_KEY`
These credentials are used for AWS API operations associated with the Data Plane.
{% hint style="warning" %}
**Security.** Treat kubeconfig files and cloud credentials as sensitive infrastructure credentials. Do not commit them to source control. Use your organization's approved secret-management mechanism to store and manage them.
{% endhint %}
Select **Next**.
### 2. Identity
Define the identity of the Data Plane.
* **Data Plane ID:** The stable identifier for the Data Plane across DataOS.
* Required. Maximum 30 characters.
* Must remain stable after creation. It generates Data Plane domain names.
* Use `--dp-01`, such as `pacific-aws-dp-01`.
* **Description:** A short description of the Data Plane's purpose or environment.
* Required. Maximum 200 characters.
* Example: `Production Data Plane for the analytics environment`.
Select **Next**.
### 3. Cluster Access
Provide the information required for DataOS to access your existing Kubernetes cluster.
* **Cloud Service Provider:** `AWS`
* **Network Type:** `Tunnel`. This setting is fixed. The Data Plane creates an outbound encrypted connection to the DataOS Instance. No inbound cluster connection is required.
#### Cloud-specific configuration
For AWS, provide:
* **AWS Region:** Must match the EKS cluster region.
* **AWS Access Key ID:** Use the credential from [Step 1](#id-1-prerequisites).
* **AWS Secret Access Key:** Use the credential from [Step 1](#id-1-prerequisites).
#### Kubeconfig
Paste the Base64-encoded kubeconfig prepared in [Step 1](#id-1-prerequisites).
{% hint style="warning" %}
**Security.** A kubeconfig can contain credentials that provide access to your Kubernetes cluster. Do not commit it to source control or share it through unsecured channels.
{% endhint %}
Select **Next**.
### 4. Node Pool
Specify the node selector labels used to schedule DataOS components on the appropriate nodes.
The default selector is `dataos.io/purpose: core-kernel`.
Keep this selector unchanged unless your DataOS deployment requirements specify otherwise. The DataOS installer uses this selector when scheduling the core kernel components. If the selector does not match the labels available on the target nodes, the affected pods may remain in the `Pending` state.
If your cluster requires additional selector labels, use **+ Add** to provide them.
Select **Next**.
### 5. PostgreSQL
Provide the connection details for the PostgreSQL server, then the name, username, and password for each of the two databases from [Step 1](#id-1-prerequisites).
* **Connection:** Host and Port. Port defaults to `5432`.
* **System Health database:** Database Name, Username, and Password.
* **Vesta database:** Database Name, Username, and Password.
Select **Create Dataplane** to start provisioning.
***
## What happens during provisioning
After you submit the configuration, DataOS validates the submitted information and starts the Data Plane installation.
The current provisioning flow performs the following operations:
1. The DataOS Instance uses the supplied kubeconfig to establish access to the Kubernetes API and installs `dataos-manager` on the cluster.
2. `dataos-manager` retrieves the required installation manifests and installs the DataOS components.
3. A tunnel client running in the cluster establishes an outbound encrypted connection to the DataOS Instance through the configured network path.
4. Once the connection is established, the DataOS Instance registers and manages the Data Plane through the tunnel.
The kubeconfig is used for the DataOS Instance-to-cluster management path and is not part of Data Plane data traffic.
## Verify the Data Plane
After provisioning starts, the Data Plane appears on the Dataplanes page with its current provisioning status.
You can also verify the Data Plane using the CLI:
```bash
dataos-ctl domain get -a
```
{% hint style="info" %}
For environments where the CLI is not already authenticated, provide the required authentication values according to your environment's CLI authentication procedure.
{% endhint %}
For deeper installation troubleshooting, inspect the `dataos-manager` logs from the Kubernetes cluster:
```bash
kubectl logs -n -0-dsm dataos-manager-0 -f
```
***
## Troubleshooting
Authentication or cluster-access failure
If provisioning fails because the DataOS Instance cannot access the Kubernetes cluster:
* Verify that the kubeconfig is valid.
* Confirm that the associated identity has the required Kubernetes RBAC permissions.
* For EKS, verify the relevant EKS access entry or `aws-auth` configuration.
* Verify that the Kubernetes API endpoint is reachable from the DataOS Instance.
Kubeconfig validation fails
The provisioning flow expects a Base64-encoded kubeconfig, not the raw YAML file.
Regenerate the encoded value and ensure that the value is pasted without unintended line breaks.
Pods remain Pending
Verify that:
* The target nodes have the required `dataos.io/purpose: core-kernel` label.
* The node pool has sufficient capacity.
* The configured node selectors match the labels on the target nodes.
Database connection errors
Confirm that both databases already exist on the PostgreSQL server, that the supplied users can connect to them, and that the cluster's egress reaches the host and port.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://v2.dataos.info/operate/v1/dataos-operator/provision-data-plane/aws-ui.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.