Tensor9 provisions a Google-operated, regional GKE Standard cluster; the exact minor version uses a release channel, surfaced at the build.
#### The managed platform: add-ons and APIs GKE offers managed services alongside Kubernetes: capabilities Google operates that go beyond plain Kubernetes. Its control plane exposes the **Gateway API** through Google's built-in GKE Gateway controller, and Config Connector lets a cluster manage Google Cloud resources as Kubernetes objects. On the operations side, Google ships **Managed Service for Prometheus**, **Backup for GKE**, and the managed persistent-disk and Filestore **CSI drivers** as first-party add-ons, and the cluster autoscaler can grow the fleet through **node auto-provisioning**. These are what GKE makes available; Tensor9 does not switch them on for you. What the translation actually compiles from your EKS definition is the cluster, its node pools, Workload Identity, and VPC-native networking, with the **core EKS add-ons** you rely on (the CNI, CoreDNS, kube-proxy, and the CSI driver) re-provided as GKE's own platform components. A non-core EKS add-on with no GKE analog is dropped and surfaced at the build rather than silently discarded. #### Kubernetes workloads and cloud integrations GKE supports the Kubernetes workload API. Deployments, Services and other standard resources remain usable; review AWS-specific identity annotations, storage classes, ingress controllers and add-ons in manifests and Helm values. #### Nodes and scaling Each EKS node group becomes one GKE **node pool**, and the instance type maps to a Google machine type by a rule that preserves the hardware class: general-purpose (m5) becomes n2 or e2, compute-optimized (c5) becomes c2, Graviton (ARM) becomes t2a, and a GPU node becomes g2 with an L4 accelerator, defaulting to e2-medium when nothing more specific fits. The workload class you chose on AWS is preserved, so a compute-optimized group never quietly lands on a general-purpose machine. Your node-group scaling settings become GKE's **cluster autoscaler** with region-wide minimum and maximum bounds, and Spot or preemptible nodes remain interruptible. Unsupported accelerator requirements fail during the build: an oversized accelerator such as the A100 or H100 classes has no clean machine analog, so the build stops with a clear error rather than substituting a smaller GPU; a lesser GPU swap that does have an analog still reaches you as a surfaced warning, so a change in accelerator class is never silent. #### Identity and authorization (IRSA → GKE Workload Identity) On EKS, **IRSA** (IAM Roles for Service Accounts) does two jobs at once: it gives a pod an AWS **identity** (a role it runs as) and it governs that role's **permissions**. Tensor9 preserves the role identity and evaluates its permissions separately. **Role identity.** Your workload's identity reads (`aws sts get-caller-identity`, `iam:GetRole`) are answered **in-appliance** from the identity injected into the pod, so they return your own role and account (the same account the instance metadata serves) without contacting AWS. On GKE that reflected identity is **bound to a real cloud identity**: Kubernetes ServiceAccount (KSA) is tied to a Google service account (GSA) through GKE **Workload Identity** (the KSA holds the `iam.gke.io/gcp-service-account` annotation), and at boot the appliance **verifies** the pod really runs as that GSA before it serves an identity; an unbound pod fails closed and is pulled from service rather than presenting a role it cannot prove. A migrated EKS-plus-IRSA pod has its `get-caller-identity` answered on real GKE with the pod's own role. **AWS request authorization.** Tensor9 prepares the supported AWS IAM policy rules at build time and evaluates the verified role, requested action and resource inside the appliance. A denial overrides an allowance; policy changes arrive through verified policy delivery. Native Google Cloud permissions are granted separately to the Google service account. Those grants do not replace the AWS policy or supply its role session. The selected STS or EKS Auth adapter separately supplies AWS credentials for supported AWS API calls.
IRSA identity and permissions: your identity is reflected in-appliance and bound to GKE Workload Identity; your AWS IAM policy authorizes supported adapter requests, with deny precedence. Native provider grants remain separate.
#### Limitations Almost everything maps onto the GKE cluster: the Kubernetes workload, the managed control plane, node pools, VPC-native pod networking (alias-IP, with your pod and service secondary ranges), and workload identity bound to a real cloud identity. What has no counterpart is named here and surfaced at the build, never dropped silently. △ Where EKS and GKE diverge * **Fargate serverless nodes have no GKE-Standard analog.** Fargate-selected pods reschedule onto real node pools, and a Fargate-only cluster stops the build rather than pretending to have serverless capacity. * **The Kubernetes version may change.** GKE uses a release channel, so you get a supported version near your requested minor version, surfaced at the build. * **The control-plane endpoint is public.** A private GKE control-plane endpoint is not part of this equivalence; the public endpoint is surfaced rather than assumed. * **The AWS cluster endpoint, ARN, and token have no equivalent.** References are repointed to GKE's own endpoint and certificate authority, or the build stops rather than binding a value that points at nothing. #### Other considerations Account for the following operating requirements. * **Review cloud integrations in manifests.** Standard Kubernetes workload resources remain usable; adapt identity annotations, storage classes and controllers to the selected target. * **Google operates the control plane; you still run the nodes:** upgrades, API-server availability, and control-plane scaling become Google's, while node-pool sizing, capacity, and cost stay yours to set on Google Cloud. * **Migrate persistent data separately:** a PersistentVolume rebinds to GKE's persistent-disk or Filestore CSI, but the durable data behind it is migrated or re-provisioned separately; the cluster otherwise comes up empty of it. * **Account for cluster and node charges:** a regional GKE Standard control plane has an hourly management charge, and you pay for the node pools you size rather than a serverless node fleet, so set the autoscaler bounds for the load you expect. #### Runtime cluster management and credentials With maximum adaptation, the EKS management API handles supported cluster lifecycle requests at runtime on managed Kubernetes targets. A self-managed target continues to use the existing cluster described in its target-specific configuration. The adapter stores accepted cluster, node-group, add-on and pod-identity-association requests. Reconciliation applies the corresponding configuration to the target Kubernetes service. Creation and deletion remain asynchronous: a returned cluster record is not proof that its endpoint is ready, and describes reflect the observed target state. Kubernetes workload requests and AWS credential exchanges are separate from cluster management. Native target workload identity authorizes access to that cloud. An unchanged AWS SDK instead needs the selected STS or EKS Auth adapter to obtain an AWS session for the configured IAM role. Creating a cloud identity alone does not perform that exchange. Confirm the cluster issuer, service-account binding and role trust together, then test the application's actual API calls. ## On Azure | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------- | ------------------ | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------- | | DescribeCluster / ListClusters | EKS management API | Supported | Common | if a workload calls the EKS management API at runtime, it is translated to the target's managed-Kubernetes API | | CreateCluster / DeleteCluster / node pools | Provisioning | Supported | Most usage | Max lifecycle requests reconcile an AKS cluster and node pools; readiness is asynchronous and target settings apply | | Fargate profile | Serverless nodes | Out of scope | Full surface | no AKS analog; pods reschedule onto node pools; Fargate-only cluster stops the build | | In-cluster Kubernetes API (client-go / in-cluster config) | Workload | Supported | Full surface | native AKS API server: standard workload verbs and objects; cloud-specific integrations need target configuration | #### The AKS control plane Tensor9 translates your EKS cluster definition into an **AKS** cluster. Microsoft operates its Kubernetes control plane, including upgrades, availability, and API-server scaling. The cluster uses a system-assigned **managed identity** in Microsoft Entra ID to access Azure resources. Two AKS traits shape this equivalent. Upgrades are **managed**: AKS drives control-plane upgrades and holds you on a supported version, so rather than selecting an exact Kubernetes minor as EKS lets you, the cluster rides AKS's **recommended default** near your requested version, surfaced at the build. And AKS structures nodes as a required **system node pool** (which runs the cluster's own system pods) plus any number of **user node pools** for your workloads, which receive your translated EKS node groups.
Tensor9 provisions a Microsoft-operated AKS cluster with a managed Entra identity; upgrades are managed and the version uses AKS's recommended default, surfaced at the build.
#### The managed platform: add-ons and APIs AKS offers managed add-ons and cluster extensions : first-party capabilities Microsoft operates on top of the control plane. Event-driven autoscaling ships as the managed **KEDA** add-on; **Dapr** and GitOps with Flux are managed cluster extensions; **Azure Policy** enforces guardrails on the cluster; **Container Insights** feeds metrics and logs to Azure Monitor; the Key Vault Secrets Store CSI add-on mounts secrets from Azure Key Vault; and the **application-routing** add-on runs a managed NGINX ingress. AKS also offers a **virtual-node** option that schedules pods onto Azure Container Instances through a virtual kubelet. These are what AKS makes available; Tensor9 does not switch them on for you. What the translation compiles from your EKS definition is the cluster, its system and user node pools, Azure Workload Identity, and native pod networking, with your **core EKS add-ons** (the CNI, CoreDNS, kube-proxy, and the CSI driver) re-provided as AKS's platform components. A non-core EKS add-on with no AKS analog is dropped and surfaced at the build. #### Kubernetes workloads and cloud integrations The target exposes the Kubernetes workload API for Deployments, Services, ConfigMaps, StatefulSets and other supported resources. Review AWS-specific identity annotations, storage classes, ingress controllers and add-ons when adapting manifests and Helm values. Kubernetes conformance does not make those cloud integrations interchangeable. #### Nodes and scaling Each EKS node group becomes an AKS **node pool** (the first is the required system pool, the rest are user pools) and the instance type maps to an Azure VM size by a rule that preserves the hardware class, defaulting to `Standard_D2s_v5` when nothing more specific fits. Your node-group scaling settings become the AKS **cluster autoscaler**, and a spot posture comes across. The **virtual-node** option above is a distinct model, not a drop-in for EKS Fargate: Fargate profiles have no AKS analog and their pods reschedule onto real node pools. An oversized accelerator with no clean VM analog stops the build rather than downgrading silently, so a change in machine class is never silent. #### Identity and authorization (IRSA → Microsoft Entra Workload ID) On EKS, **IRSA** (IAM Roles for Service Accounts) does two jobs at once: it gives a pod an AWS **identity** (a role it runs as) and it governs that role's **permissions**. Tensor9 preserves the role identity and evaluates its permissions separately. **Role identity.** Your workload's identity reads (`aws sts get-caller-identity`, `iam:GetRole`) are answered **in-appliance** from the identity injected into the pod, so they return your own role and account (the same account the instance metadata serves) without contacting AWS. On AKS that reflected identity is **bound to a real cloud identity** through Microsoft Entra Workload ID : the cluster's OIDC issuer is enabled and Kubernetes ServiceAccount is federated to a **user-assigned managed identity** in Entra ID by a federated identity credential (with the `azure.workload.identity` annotations marking the pod), so the pod exchanges its ServiceAccount token for Entra tokens with no long-lived secret. **AWS request authorization.** Tensor9 prepares the supported AWS IAM policy rules at build time and evaluates the verified role, requested action and resource inside the appliance. A denial overrides an allowance; policy changes arrive through verified policy delivery. Native Azure permissions are granted separately to the managed identity. Those grants do not replace the AWS policy or supply its role session. The selected STS or EKS Auth adapter separately supplies AWS credentials for supported AWS API calls.
IRSA identity and permissions: your identity is reflected in-appliance and bound to Microsoft Entra Workload ID; your AWS IAM policy authorizes supported adapter requests, with deny precedence. Native provider grants remain separate.
#### Limitations Almost everything maps onto the AKS cluster: the Kubernetes workload, the managed control plane, system and user node pools, native pod networking, and workload identity bound per workload. What has no counterpart is named here and surfaced at the build, never dropped silently. △ Where EKS and AKS diverge * **Fargate serverless nodes have no AKS analog.** Fargate-selected pods reschedule onto real node pools, and a Fargate-only cluster stops the build rather than pretending to have serverless capacity. * **The Kubernetes version may change.** AKS rides its recommended default, so you get a supported version near your requested minor version, surfaced at the build. * **The control-plane endpoint is public.** A private AKS control-plane endpoint is not part of this equivalence; the public endpoint is surfaced rather than assumed. * **The AWS cluster endpoint, ARN, and token have no equivalent.** References are repointed to the AKS endpoint and certificate authority, or the build stops rather than binding a value that points at nothing. #### Other considerations Account for the following operating requirements. * **Review cloud integrations in manifests.** Standard Kubernetes workload resources remain usable; adapt identity annotations, storage classes and controllers to the selected target. * **Microsoft operates the control plane, and a system node pool is now required.** AKS mandates a system pool for the cluster's own pods alongside your user pools: capacity and cost you did not size on EKS. * **Workload identity is set up per workload:** each ServiceAccount is federated to a user-assigned managed identity in Entra ID, so a migrated pod gets the workload-identity annotations rather than an IRSA role annotation. * **Account for cluster and node charges:** the AKS control plane is free on the base tier (the Uptime-SLA tier is paid), and you pay for the node pools you run including the required system pool; size the autoscaler bounds for expected load. #### Management and credentials on AKS Supported cluster, node-group, add-on and association changes reconcile onto AKS asynchronously. Entra Workload ID grants access only through separately configured Azure permissions; AWS SDK calls need the selected AWS credential exchange. See [cluster management and credential separation](/service-adapters/aws/compute-containers/eks#runtime-cluster-management-and-credentials) for the common model and its managed-target restriction. ## On OCI | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------- | ------------------ | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------- | | DescribeCluster / ListClusters | EKS management API | Supported | Common | if a workload calls the EKS management API at runtime, it is translated to the target's managed-Kubernetes API | | Node-group autoscaling bounds | Node pools | Partial | Most usage | the desired size is applied; cluster-autoscaler min/max is unsupported on the node-pool resource; the build reports its omission | | CreateCluster / DeleteCluster / node pools | Provisioning | Supported | Most usage | Max lifecycle requests reconcile an enhanced OKE cluster and node pools; readiness is asynchronous and target settings apply | | Fargate profile | Serverless nodes | Out of scope | Full surface | no OKE analog; pods reschedule onto node pools; Fargate-only cluster stops the build | | In-cluster Kubernetes API (client-go / in-cluster config) | Workload | Supported | Full surface | native OKE API server: standard workload verbs and objects; cloud-specific integrations need target configuration | #### The OKE control plane On Oracle Cloud the control plane is run by **OKE**, and Tensor9 provisions it as an **enhanced cluster**, OKE's fuller tier, the one that includes the cluster autoscaler, workload identity, and higher node ceilings. Oracle operates the control plane, and its API-server endpoint is **private in this mapping**, so the cluster is reached over your own VCN by default rather than a public address. OKE gives you more than one way to run nodes under that control plane: **managed node pools**, where OKE manages the Kubernetes components on nodes in your tenancy; fully OKE-run virtual nodes , where Oracle runs the node capacity for you; and self-managed nodes. Tensor9 compiles your EKS node groups into **managed node pools**, so the sizing you chose maps directly. On the version, EKS lets you pin an exact minor; OKE selects a **supported patch** of that requested minor version, chosen at plan time and surfaced.
Tensor9 provisions an Oracle-operated enhanced OKE cluster with a private endpoint in this mapping; the version selects a supported patch of your requested minor version, surfaced at the build.
#### The managed platform: add-ons and APIs Tensor9 provisions OKE's **enhanced-cluster** tier. It includes managed cluster add-ons that Oracle operates and version-manages (the cluster autoscaler among them) along with **OKE Workload Identity** and higher node-count ceilings. Under the control plane, OKE lets you run nodes as managed node pools, fully OKE-run virtual nodes, or self-managed nodes, and its API-server endpoint is private in this mapping, reached over your own VCN. These are what the enhanced OKE cluster makes available; what Tensor9 compiles from your EKS definition is the enhanced cluster, its managed node pools on flexible shapes, the OCI-native workload-identity binding, and VCN-native pod networking, with your **core EKS add-ons** re-provided as OKE's platform components. A non-core EKS add-on with no OKE analog is dropped and surfaced at the build. #### Kubernetes workloads and cloud integrations The target exposes the Kubernetes workload API for Deployments, Services, ConfigMaps, StatefulSets and other supported resources. Review AWS-specific identity annotations, storage classes, ingress controllers and add-ons when adapting manifests and Helm values. Kubernetes conformance does not make those cloud integrations interchangeable. #### Nodes and scaling Each EKS node group becomes one OKE **node pool** on an OCI **flexible shape**, which takes your core (OCPU) and memory sizing directly rather than rounding to a fixed instance size. Pod networking is **VCN-native** (pods get IPs from your VCN) matching the routable-pod-IP model EKS gives you. There is one node-pool limit specific to OKE: its cluster-autoscaler minimum and maximum bounds have no node-pool-resource analog, so the desired size is provisioned and the min/max bounds are dropped and surfaced. An oversized accelerator with no clean shape analog stops the build rather than downgrading silently. #### Identity and authorization (IRSA → OCI workload identity) On EKS, **IRSA** (IAM Roles for Service Accounts) does two jobs at once: it gives a pod an AWS **identity** (a role it runs as) and it governs that role's **permissions**. Tensor9 preserves the role identity and evaluates its permissions separately. **Role identity.** Your workload's identity reads (`aws sts get-caller-identity`, `iam:GetRole`) are answered **in-appliance** from the identity injected into the pod, so they return your own role and account (the same account the instance metadata serves) without contacting AWS. On OKE that reflected identity is **bound to a real cloud identity** through OCI workload identity . OCI IAM policies select the workload principal by cluster, namespace and service account. These native grants are separate from the AWS role policy and credential exchange. **AWS request authorization.** Tensor9 prepares the supported AWS IAM policy rules at build time and evaluates the verified role, requested action and resource inside the appliance. A denial overrides an allowance; policy changes arrive through verified policy delivery. Native OCI permissions are granted separately to the workload principal. Those grants do not replace the AWS policy or supply its role session. The selected STS or EKS Auth adapter separately supplies AWS credentials for supported AWS API calls.
IRSA identity and permissions: your identity is reflected in-appliance and bound to OCI workload identity; your AWS IAM policy authorizes supported adapter requests, with deny precedence. Native provider grants remain separate.
#### Limitations Almost everything maps onto the OKE cluster: the Kubernetes workload, the enhanced managed control plane, node pools on flexible shapes, VCN-native pod networking, and a private endpoint in this mapping. What has no counterpart is named here and surfaced at the build, never dropped silently. △ Where EKS and OKE diverge * **Fargate serverless nodes have no OKE analog.** Fargate-selected pods reschedule onto real node pools, and a Fargate-only cluster stops the build rather than pretending to have serverless capacity. * **The Kubernetes version may change.** OKE selects a supported patch of your requested minor version, chosen at plan time and surfaced at the build. * **Cluster-autoscaler bounds have no node-pool analog.** The desired size is kept; the autoscaler minimum and maximum are dropped and surfaced. * **The AWS cluster endpoint, ARN, and token have no equivalent.** References are repointed to the OKE endpoint and certificate authority, or the build stops rather than binding a value that points at nothing. #### Other considerations Account for the following operating requirements. * **Deploy workloads onto the enhanced OKE cluster.** Review OCI identity bindings, storage classes and VCN networking alongside Kubernetes manifests. * **This mapping selects a private control-plane endpoint.** OKE reaches the API server over your own VCN, so cluster administration needs in-VCN reachability (a bastion or private access) rather than a public endpoint. * **Autoscaler bounds have no counterpart:** the desired node count is provisioned, but the cluster-autoscaler minimum and maximum have no node-pool analog, so scaling limits are re-established on OCI after cutover. * **Account for cluster and node charges.** OKE's enhanced tier has a per-cluster charge and you pay for the managed node pools you size on flexible shapes (OCPU and memory directly), rather than an EKS control-plane fee plus fixed instance types. #### Management and credentials on OKE Supported cluster and node-pool changes reconcile onto OKE asynchronously. OCI workload identity and its native grants remain separate from STS or EKS Auth role sessions used for AWS adapter calls. See [cluster management and credential separation](/service-adapters/aws/compute-containers/eks#runtime-cluster-management-and-credentials) for the common model and its managed-target restriction. ## On Private Kubernetes | Operation | Area | Support | Depth | Notes | | --------------------------------------------------------- | ---------------- | ------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Workload identity (IRSA) | Identity | Partial | Full surface | Kubernetes ServiceAccounts and RBAC govern cluster access. The selected STS service adapter supplies supported AWS role sessions; this mapping does not provision a native cloud identity binding. Real external-cloud access requires separately authorized credentials or federation. | | Cluster provisioning (control plane / node groups) | Provisioning | Out of scope | Full surface | not provisioned: you bring the API server and the nodes; Tensor9 emits a reference to your existing cluster's endpoint and auth | | Fargate profile | Serverless nodes | Out of scope | Full surface | no analog; you run the nodes | | In-cluster Kubernetes API (client-go / in-cluster config) | Workload | Supported | Full surface | your existing cluster's API server: standard workload verbs and objects; cloud-specific integrations need target configuration | #### The control plane you run Tensor9 uses an existing Kubernetes cluster in the customer's environment, such as kubeadm, k3s, or kops. It generates references to that cluster's endpoint and authentication; it creates no control plane or node pools. The customer operates the API server, maintains control-plane availability, upgrades Kubernetes, and provisions and replaces nodes. They also supply the capacity your workloads need.
Nothing is provisioned here: the EKS cluster is redirected onto a Kubernetes cluster you already operate, and Tensor9 references its endpoint and authentication.
#### Cluster add-ons The customer installs and operates the cluster's ingress controller, autoscaler, monitoring, secrets driver, and backup service. Tensor9 deploys workloads onto the existing cluster without adding those services. The API server, scheduler, controller-manager, and existing networking (CNI), DNS, and storage (CSI) components stay in place. #### Kubernetes workloads and cloud integrations Deploy the workload onto the existing cluster's Kubernetes API. Match API versions, identity annotations, storage classes and installed controllers to that cluster; AWS-specific integrations may need different manifests or Helm values. #### Node capacity The nodes are yours. There is no machine-type mapping to a cloud instance family and no cloud autoscaler wired for you, because **you own node provisioning and lifecycle**: you decide how nodes are added, sized, and retired, and you run an autoscaler (cluster-autoscaler, Karpenter, or none) if you want one. Tensor9 does not size or scale the fleet; it schedules your workloads onto the capacity you already run. #### Cluster access and AWS credentials **Kubernetes API access.** ServiceAccounts and RBAC govern what workloads may do against the existing cluster's API. They do not by themselves supply AWS credentials. **AWS adapter credentials.** With IRSA (IAM Roles for Service Accounts), the AWS SDK sends a projected service-account token to the selected STS adapter through `AssumeRoleWithWebIdentity`. That exchange supplies a supported AWS role session for calls handled by Tensor9. Pod Identity uses the selected EKS Auth adapter's `AssumeRoleForPodIdentity` exchange. Configure the cluster issuer, service-account binding and IAM role trust for the selected exchange. **Real external-cloud access.** Calls to real external-cloud services need credentials or federation authorized by that cloud. This mapping does not provision a native cloud identity binding; configure that access using the cluster's identity integration or mounted credentials. **AWS adapter permissions.** Tensor9 evaluates the role's AWS policies for API calls handled by its service adapters. An explicit deny overrides an allow. Kubernetes RBAC and the external cloud's own authorization govern their respective APIs.
AWS adapter calls use the selected credential adapter and role policy. Kubernetes RBAC and real external-cloud credentials authorize separate destinations.
#### Limitations Workloads use the existing cluster's Kubernetes API. Review its identity, storage, ingress and installed controllers when adapting manifests; this mapping provisions no control plane or nodes. △ Where EKS and a self-managed cluster diverge * **You run the control plane and nodes.** Nothing is provisioned: no managed control plane, no node pools. Tensor9 references your existing cluster's endpoint and authentication. * **Native cloud identity bindings are not provisioned.** Supported AWS role sessions use the selected STS or EKS Auth adapter. Configure credentials or federation separately for real external-cloud services. * **Fargate serverless nodes have no analog.** You run the nodes, so there is no serverless node capacity to schedule onto. * **No cloud autoscaler or machine mapping is wired for you.** You own node sizing, scaling, and lifecycle. #### Other considerations Account for the following operating requirements. * **Deploy onto the existing cluster:** the build emits a reference to a cluster you already operate and schedules your adapted Kubernetes manifests onto it, so the move is wiring the workloads onto existing capacity, not standing up a cluster. * **Every operational duty stays with you:** control-plane HA, version upgrades, node lifecycle, and any platform layer (ingress, autoscaler, monitoring, backup) are yours to run; a managed target would have operated them. * **Configure each credential path.** Kubernetes RBAC authorizes cluster access. The selected STS or EKS Auth adapter supplies supported AWS sessions; real external-cloud services require separately authorized credentials or federation. * **Budget for cluster capacity and maintenance:** there is no managed control-plane charge, but the cluster's capacity, availability, and upkeep run on infrastructure you own and staff. #### Management and credentials on an existing cluster This target uses your existing cluster; it does not provision a managed Kubernetes service. Cluster RBAC and selected AWS role sessions are separate. External cloud access still requires credentials or federation authorized by that provider. See [cluster management and credential separation](/service-adapters/aws/compute-containers/eks#runtime-cluster-management-and-credentials) for the common model and its managed-target restriction. [Service Catalog](/service-adapters/catalog).