Your task definition and service are compiled into native Kubernetes on GKE at the build; afterward Google's own load balancer and runtime carry every request.
#### The task definition and service A **task definition** describes a main container and any helper containers (sidecars). Tensor9 translates them into a multi-container **Pod** and copies the image to your registry during the build. Fargate expresses compute as a CPU value in \{0.25 … 16} vCPU with tied memory bands; on GKE that becomes Pod `requests` and `limits`, which are not restricted to Fargate's fixed size combinations. Requested resources must fit node capacity, scheduler rules and quota. An ECS service keeps a **desired count** of tasks always on. That maps directly to a Deployment's `replicas`, the desired replica count, not a guaranteed number of ready pods; scale-to-zero is not the default and is added only if you want it. **Application Auto Scaling** becomes a **HorizontalPodAutoscaler** on CPU, memory, or a custom metric, and a rolling update maps to the Deployment's own `RollingUpdate` with `maxSurge` and `maxUnavailable`. For other ECS operations, the **DAEMON** strategy becomes a **DaemonSet** (one Pod per node), and **ECS Exec** becomes `kubectl exec` into the Pod.
The task definition becomes a Pod spec and the service becomes a Deployment: containers and sizing land as requests and limits, desiredCount sets replicas, the DAEMON strategy becomes a DaemonSet, and ECS Exec becomes kubectl exec.
#### Networking, discovery, and load balancing ECS's **awsvpc** mode gives each task its own routable IP and security group. A **VPC-native** GKE cluster offers the same model: every Pod gets its own individually-addressable IP, and a per-task security group maps to a **NetworkPolicy** (enforced by GKE Dataplane V2) to preserve network isolation between tasks. **Service discovery** by name, whether Cloud Map or DNS, is repointed at the build to a Kubernetes **Service** with cluster DNS, which is exactly ECS's name-based model. The service's `loadBalancer` block (the ALB or NLB target group its tasks register into) becomes a Kubernetes **Service** of type LoadBalancer (which provisions Google Cloud Load Balancing) plus an **Ingress** or a Gateway for host and path routing, with the target-group health check becoming the Pod's readiness probe. For supported routing rules, weights and certificates, see the [Application Load Balancer](/service-adapters/aws/networking-traffic/application-load-balancer) and [Network Load Balancer](/service-adapters/aws/networking-traffic/network-load-balancer) articles. This page places the Pod fleet behind that load balancer. For **ECS Service Connect**, a Service gives you name-based discovery, but Service Connect's injected mesh proxy and its built-in metrics are partial and need an added service mesh (Istio or Linkerd), which you configure separately. #### The GKE control plane This mapping selects a regional **GKE Standard** cluster: Google operates the control plane, and you configure node pools. **Autopilot** is a native alternative, not the selected adapter mapping; Google sizes its nodes and its workload billing model differs. On Standard, configured **node auto-provisioning** creates and resizes node pools to fit pending Pod requests, so an ECS **capacity provider** maps to that node-pool and cluster-autoscaler layer, and a `FARGATE_SPOT` preference maps to a spot (preemptible) node pool. Node upgrades and control-plane patching are Google's to run. GKE offers **managed integrations** that you enable and configure for the translated ECS workload; they are not all installed by selecting this adapter. The managed **GKE Gateway controller** implements the Gateway API with weighted routes, so a weighted blue-green or canary split has a managed path rather than a hand-rolled one (automated canary analysis still uses Argo Rollouts or Flagger). Managed Service for Prometheus collects metrics, including a service mesh's when you add one for Service Connect; **Config Connector** lets the cluster manage Google Cloud resources as Kubernetes objects; **Backup for GKE** covers workload and volume backup; and the Compute Engine, Filestore, and Cloud Storage **CSI drivers** back any volumes your task declares. Identity uses GKE Workload Identity, covered in the next section.
The selected mapping uses regional GKE Standard and configured node pools. Autopilot is a native alternative. Gateway routing, monitoring, resource controllers, backups and storage drivers require the corresponding integration settings.
#### Pod identity: the task role An ECS task's **task role** is the same idea as EKS's IRSA: the identity the app's own code assumes, delivered as scoped cloud credentials with no static secret. On Kubernetes that shape is a **ServiceAccount federated to a cloud identity through the cluster's OIDC provider**, and on GKE that provider is **GKE Workload Identity**, which binds a Kubernetes ServiceAccount to a **Google service account** through the cluster's workload-identity pool (an IAM binding plus the `iam.gke.io/gcp-service-account` annotation), with the Pod reading its credentials from the **GKE metadata server**, no key to mount or rotate. The AWS role and the Google identity stay consistent through a startup check: at boot the appliance fetches the Pod's real GKE workload identity and checks that the declared AWS task role is bound to it, failing closed if it does not. Inside the appliance the IAM surface then **reflects** that identity, so `aws sts get-caller-identity` and `iam:GetRole` answer as the task's own role, and calls to other AWS services use the Tensor9 adapters with that role. The **execution role** (the one ECS itself used to pull the image, fetch secrets, and write logs) is not needed, because GKE owns image pull and log delivery with its own identity.
The task role is ECS's EKS-IRSA equivalent: a Kubernetes ServiceAccount federated to a Google service account through the cluster's workload-identity pool, so the pod gets scoped credentials from the metadata server with no static secret.
#### AWS request authorization The task role's AWS IAM policy supplies authorization rules for supported **AWS API** requests handled by Tensor9. The build prepares the declared rules, including supported action and resource wildcards. At runtime, the adapter evaluates the verified caller's role, requested action and resource; a denial overrides an allowance. Policy changes are delivered with integrity verification to the appliance. Native Google Cloud permissions are granted separately to the Google service account. GKE Workload Identity supplies that identity; selecting it does not grant access to every Google resource or replace the AWS task-role policy. #### Secrets and logging The container's `environment` variables are kept as-is, and its `secrets` references resolve from **Google Secret Manager** (often via the External Secrets Operator), the same store the SSM equivalence uses. The `awslogs` log driver becomes **Cloud Logging**, with stdout and stderr delivered automatically; a custom FireLens log router can run as a sidecar; configure its destination and credentials for the target logging service. #### Limitations Review the remaining service, deployment and networking differences below. △ Where it diverges * **ECS Service Connect's mesh is partial:** a Service handles name-based discovery, but the injected mesh proxy and its built-in metrics need an added service mesh (Istio / Linkerd); its metrics can then flow into Managed Service for Prometheus. * **Weighted blue-green or canary releases require extra tooling:** a plain rolling update is native; weighted traffic splitting is handled by the managed GKE Gateway controller (Gateway API), and automated canary analysis uses Argo Rollouts or Flagger. * **Capacity providers and Fargate Spot are the cluster's own:** the cluster owns capacity via its node pools, so a capacity-provider strategy maps to node pools / node auto-provisioning and a Spot preference to a spot (preemptible) node pool. * **The task-metadata endpoint is served read-only.** `169.254.170.2` (`ECS_CONTAINER_METADATA_URI_V4`), the ECS task-metadata API, is served read-only; other AWS calls use their corresponding adapters. #### Other considerations Plan persistent storage, cluster capacity, logging, and secret access before deployment. * **Migrate mounted volumes separately:** a task definition and service hold no data, and the image is already a container image pulled into your own registry at the build, so adoption is a redeploy; any volume a task mounts (EFS, EBS) moves under its own service card. * **Plan node-pool capacity.** ECS on Fargate exposed no nodes, but on Google Cloud the workload lands on a GKE cluster whose selected Standard node pools require capacity planning, while Google operates and patches the control plane. * **Costs include continuously running nodes.** `desiredCount` becomes always-on replicas billed as running nodes in the selected GKE Standard deployment, so capacity is sized for steady state rather than metered per Fargate task. * **Telemetry and secrets move to Google Cloud's stores:** logs land in Cloud Logging and `secrets` resolve from Google Secret Manager, so dashboards, alerts, and secret access follow the target services. #### Runtime task execution The runtime ECS adapter accepts task-definition and task-lifecycle calls from the AWS SDK. It translates supported task definitions into Kubernetes workload configuration and maps RunTask, DescribeTasks, ListTasks and StopTask to the corresponding task state and execution. Registering a definition does not start its containers; a task can be pending while images are pulled or capacity is unavailable. Check task status and container exit information separately from API acceptance. Service deployment, scaling, task execution and workload credentials are distinct concerns. The target cluster schedules and runs the containers. The selected identity integration must provide credentials for calls made by those containers; a Kubernetes ServiceAccount does not by itself supply AWS credentials. Review task and service features against their specific rows, including network policy, Service Connect, storage and execution settings. ## On Azure | Operation | Area | Support | Depth | Notes | | ------------------------------------------------- | --------------- | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Capacity providers / FARGATE\_SPOT | Cluster | Out of scope | Full surface | the cluster owns capacity via its node pools; FARGATE\_SPOT maps to a Spot node pool | | Identity: task role | Identity | Supported | Common | taskRoleArn → Azure Workload Identity (a per-workload user-assigned managed identity + federated credential), keyless; the execution role is not needed | | Secrets and environment | Identity | Supported | Common | environment variables are set as-is; secrets map to Azure Key Vault | | Load balancer: service LB block | Load balancer | Supported | Common | ALB / NLB target group → a Service (type=LoadBalancer) plus Ingress / Gateway; See the load-balancer adapter pages for individual routing-rule support. | | Logging: awslogs | Logging | Supported | Common | awslogs → Azure Monitor / Log Analytics; a FireLens sidecar stays a logging sidecar | | Networking: awsvpc (per-task IP + security group) | Networking | Supported | Common | per-task ENI + security group → per-Pod IP (Azure CNI) + NetworkPolicy: individually addressable, with network isolation between pods | | Networking: service discovery / Service Connect | Networking | Partial | Most usage | a Service + cluster DNS gives discovery natively; the injected mesh proxy and its metrics need an added service mesh (Istio / Linkerd) | | ECS Exec | Runtime | Supported | Most usage | ECS Exec's interactive shell → kubectl exec into the Pod | | Task-metadata endpoint (runtime) | Runtime | Supported | Common | 169.254.170.2 / ECS\_CONTAINER\_METADATA\_URI\_V4 served read-only, the ECS task-metadata API | | Scheduling: DAEMON strategy | Service | Supported | Full surface | one copy per host → a DaemonSet, one Pod per node | | Service: autoscaling | Service | Supported | Most usage | Application Auto Scaling → a HorizontalPodAutoscaler on CPU / memory / custom | | Service: deployment controller | Service | Partial | Most usage | rolling update is native (maxSurge / maxUnavailable); weighted blue-green / canary requires release-management tooling (Gateway API / Argo Rollouts / Flagger) | | Service: desired count | Service | Supported | Common | desiredCount → Deployment desired replicas; ready count depends on scheduling and health | | Task definition: containers / sidecars | Task definition | Supported | Common | multi-container task → a Pod with a main container plus sidecars, native | | Task definition: cpu / memory | Task definition | Supported | Common | Fargate \{0.25 … 16 vCPU} with tied memory bands → Pod requests / limits: values within node capacity and quota, without Fargate fixed-size combinations | | Task definition: image | Task definition | Supported | Common | Copies the container image to your registry during the build. | #### How it works On AWS your service runs as an **ECS service**: a task definition describes the container image and its sizing, and the service keeps a desired number of copies running on Fargate behind a load balancer. Tensor9 reads that task definition and service and, at the build, turns them into native Kubernetes on **AKS**: a **Deployment** (or a **DaemonSet** for the DAEMON strategy) plus a **Service**, on a control plane that Microsoft operates. Kubernetes schedules the same container image. After deployment, clients reach your container through the target load balancer or cluster DNS. Tensor9 translates the stack during the build and does not proxy application traffic.
Your task definition and service are compiled into native Kubernetes on AKS at the build; afterward Azure's own load balancer and runtime carry every request.
#### The task definition and service A **task definition** describes a main container and any helper containers (sidecars). Tensor9 translates them into a multi-container **Pod** and copies the image to your registry during the build. Fargate expresses compute as a CPU value in \{0.25 … 16} vCPU with tied memory bands; on AKS that becomes Pod `requests` and `limits`, which are not restricted to Fargate's fixed size combinations. Requested resources must fit node capacity, scheduler rules and quota. An ECS service keeps a **desired count** of tasks always on. That maps directly to a Deployment's `replicas`, the desired replica count, not a guaranteed number of ready pods; scale-to-zero is not the default and is added only if you want it (AKS ships a managed way to, covered below). **Application Auto Scaling** becomes a **HorizontalPodAutoscaler** on CPU, memory, or a custom metric, and a rolling update maps to the Deployment's own `RollingUpdate` with `maxSurge` and `maxUnavailable`. For other ECS operations, the **DAEMON** strategy becomes a **DaemonSet** (one Pod per node), and **ECS Exec** becomes `kubectl exec` into the Pod.
The task definition becomes a Pod spec and the service becomes a Deployment: containers and sizing become requests and limits, desiredCount becomes replicas, the DAEMON strategy becomes a DaemonSet, and ECS Exec becomes kubectl exec.
#### Networking, discovery, and load balancing ECS's **awsvpc** mode gives each task its own routable IP and security group. On AKS **Azure CNI** provides the same natively: every Pod gets its own individually-addressable VNet IP, and a per-task security group maps to a **NetworkPolicy** to preserve network isolation between tasks. **Service discovery** by name, whether Cloud Map or DNS, is repointed at the build to a Kubernetes **Service** with cluster DNS, which is exactly ECS's name-based model. The service's `loadBalancer` block (the ALB or NLB target group its tasks register into) becomes a Kubernetes **Service** of type LoadBalancer (which provisions an Azure Load Balancer) plus an **Ingress** for host and path routing, with the target-group health check becoming the Pod's readiness probe. For supported routing rules, weights and certificates, see the [Application Load Balancer](/service-adapters/aws/networking-traffic/application-load-balancer) and [Network Load Balancer](/service-adapters/aws/networking-traffic/network-load-balancer) articles. This page places the Pod fleet behind that load balancer. For **ECS Service Connect**, a Service provides name-based discovery, but Service Connect's injected mesh proxy and its built-in metrics are partial and need an added service mesh (Istio or Linkerd), surfaced rather than silently skipped. #### The AKS control plane Microsoft operates the control plane, and nodes come as **system and user node pools** of different VM sizes with a cluster autoscaler; a capacity provider maps to that node-pool layer, and a `FARGATE_SPOT` preference maps to a **Spot node pool**. Node image upgrades and control-plane patching are Microsoft's to run. Beyond fixed nodes, AKS can burst Pods onto **virtual nodes** backed by **Azure Container Instances**, a serverless capacity tier with the same elastic, pay-per-pod character as the origin's own on-demand compute. AKS offers **managed add-ons and cluster extensions**. The managed KEDA addon adds scale-to-zero and event-driven autoscaling as a managed option; the **Application Routing** addon provides a managed NGINX ingress for the Service-plus-Ingress mapping; the **Azure Key Vault Provider for Secrets Store CSI Driver** mounts Key Vault secrets into Pods; and **Container Insights** is the managed Azure Monitor path for container logs and metrics. As cluster extensions, **Dapr**, **GitOps with Flux**, and Azure Policy are available too. Identity federates to Microsoft Entra Workload ID, covered in the next section.
AKS runs the control plane over system and user node pools, with virtual-node burst to a serverless capacity tier, and ships managed addons the ECS workload can use: managed KEDA, Application Routing, the Key Vault CSI addon, Container Insights, Dapr, Flux, and Azure Policy.
#### Pod identity: the task role An ECS task's **task role** is the same idea as EKS's IRSA: the identity the app's own code assumes, delivered as scoped cloud credentials with no static secret. On Kubernetes that shape is a **ServiceAccount federated to a cloud identity through the cluster's OIDC provider**, and on AKS that provider is **Microsoft Entra Workload ID**: the cluster's **AKS OIDC issuer** and a **federated identity credential** federate a Kubernetes ServiceAccount to a **user-assigned managed identity** (or an Entra app registration), the mutating admission webhook injects a token into the Pod, and the app exchanges it for a scoped Entra token, with no key to mount or rotate. The AWS role and the Entra identity stay consistent through a startup check: at boot the appliance fetches the Pod's real AKS workload identity and checks that the declared AWS task role is bound to it, failing closed if it does not. Inside the appliance the IAM surface then **reflects** that identity, so `aws sts get-caller-identity` and `iam:GetRole` answer as the task's own role, and calls to other AWS services use the Tensor9 adapters with that role. The **execution role** (the one ECS itself used to pull the image, fetch secrets, and write logs) is not needed, because AKS owns image pull and log delivery with its own identity.
The task role is ECS's EKS-IRSA equivalent: a Kubernetes ServiceAccount federated through the AKS OIDC issuer to a Microsoft Entra identity, so the pod exchanges its ServiceAccount token for a scoped Entra token with no static secret.
#### AWS request authorization For supported AWS API calls, Tensor9 evaluates the task role's IAM policy against the verified caller, action and resource; a denial overrides an allowance. See [AWS request authorization](/service-adapters/aws/compute-containers/ecs#aws-request-authorization) for policy preparation, wildcard support and verified policy delivery. Native Azure permissions are granted separately to the managed identity in Azure. Entra Workload ID supplies identity tokens, not the resource grants or an AWS role session. #### Secrets and logging The container's `environment` variables are set as-is, and its `secrets` references resolve from **Azure Key Vault** (through the managed Key Vault Secrets Store CSI addon or the External Secrets Operator), the same store the SSM equivalence uses. The `awslogs` log driver becomes **Azure Monitor / Log Analytics** (Container Insights), with stdout and stderr delivered automatically; a custom FireLens log router can run as a sidecar; configure its destination and credentials for the target logging service. #### Limitations Review the remaining service, deployment and networking differences below. △ Where it diverges * **ECS Service Connect's mesh is partial:** a Service provides name-based discovery, but the injected mesh proxy and its built-in metrics need an added service mesh (Istio / Linkerd). * **Weighted blue-green or canary releases require extra tooling:** a plain rolling update is native; a weighted traffic split uses Gateway API, Argo Rollouts, or Flagger. * **Capacity providers and Fargate Spot are the cluster's own:** the cluster owns capacity via its node pools, so a capacity-provider strategy maps to node pools (or virtual-node burst to Azure Container Instances) and a Spot preference to a Spot node pool. * **The task-metadata endpoint is served read-only.** `169.254.170.2` (`ECS_CONTAINER_METADATA_URI_V4`), the ECS task-metadata API, is served read-only; other AWS calls use their corresponding adapters. #### Other considerations Plan persistent storage, cluster capacity, logging, and secret access before deployment. * **Migrate mounted volumes separately:** a task definition and service hold no data, and the image is already a container image pulled into your own registry at the build, so adoption is a redeploy; any volume a task mounts (EFS, EBS) moves under its own service card. * **Plan node-pool capacity.** The origin exposed no nodes, but on AKS the workload lands on a cluster whose node pools (or a serverless virtual-node burst tier) are an operational surface, while Microsoft operates and patches the control plane. * **Costs include continuously running nodes.** `desiredCount` becomes always-on replicas billed as running nodes, so the node pool is sized for steady state rather than metered per Fargate task. * **Telemetry and secrets move to Azure's stores:** logs land in Container Insights and `secrets` resolve from Azure Key Vault, so dashboards, alerts, and secret access follow the target services. #### Runtime tasks on AKS AKS schedules the translated tasks on configured node pools. Task acceptance, container readiness and exit status remain separate; native Azure grants and AWS task-role credentials also remain separate. See [runtime task execution](/service-adapters/aws/compute-containers/ecs#runtime-task-execution) for supported task-definition and task-lifecycle calls. ## On OCI | Operation | Area | Support | Depth | Notes | | ------------------------------------------------- | --------------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Capacity providers / FARGATE\_SPOT | Cluster | Out of scope | Full surface | the cluster owns capacity via its node pools; FARGATE\_SPOT maps to a preemptible node pool | | Identity: task role | Identity | Partial | Common | taskRoleArn → OKE Workload Identity, the OCI-native analog: IAM policies selecting a workload principal by cluster, namespace and service account; the execution role is not needed | | Secrets and environment | Identity | Supported | Common | environment variables are set as-is; secrets map to OCI Vault | | Load balancer: service LB block | Load balancer | Supported | Common | ALB / NLB target group → a Service (type=LoadBalancer) plus Ingress / Gateway; See the load-balancer adapter pages for individual routing-rule support. | | Logging: awslogs | Logging | Supported | Common | awslogs → OCI Logging; a FireLens sidecar stays a logging sidecar | | Networking: awsvpc (per-task IP + security group) | Networking | Supported | Common | per-task ENI + security group → per-Pod IP (VCN-native) + NetworkPolicy: individually addressable, with network isolation between pods | | Networking: service discovery / Service Connect | Networking | Partial | Most usage | a Service + cluster DNS gives discovery natively; the injected mesh proxy and its metrics need an added service mesh (Istio / Linkerd) | | ECS Exec | Runtime | Supported | Most usage | ECS Exec's interactive shell → kubectl exec into the Pod | | Task-metadata endpoint (runtime) | Runtime | Supported | Common | 169.254.170.2 / ECS\_CONTAINER\_METADATA\_URI\_V4 served read-only, the ECS task-metadata API | | Scheduling: DAEMON strategy | Service | Supported | Full surface | one copy per host → a DaemonSet, one Pod per node | | Service: autoscaling | Service | Supported | Most usage | Application Auto Scaling → a HorizontalPodAutoscaler on CPU / memory / custom | | Service: deployment controller | Service | Partial | Most usage | rolling update is native (maxSurge / maxUnavailable); weighted blue-green / canary requires release-management tooling (Gateway API / Argo Rollouts / Flagger) | | Service: desired count | Service | Supported | Common | desiredCount → Deployment desired replicas; ready count depends on scheduling and health | | Task definition: containers / sidecars | Task definition | Supported | Common | multi-container task → a Pod with a main container plus sidecars, native | | Task definition: cpu / memory | Task definition | Supported | Common | Fargate \{0.25 … 16 vCPU} with tied memory bands → Pod requests / limits: values within node capacity and quota, without Fargate fixed-size combinations | | Task definition: image | Task definition | Supported | Common | Copies the container image to your registry during the build. | #### How it works On AWS your service runs as an **ECS service**: a task definition describes the container image and its sizing, and the service keeps a desired number of copies running on Fargate behind a load balancer. Tensor9 reads that task definition and service and, at the build, turns them into native Kubernetes on **OKE**: a **Deployment** (or a **DaemonSet** for the DAEMON strategy) plus a **Service**, on an enhanced OKE control plane that Oracle operates, with VCN-native pod networking. Kubernetes schedules the same container image. After deployment, clients reach your container through the target load balancer or cluster DNS. Tensor9 translates the stack during the build and does not proxy application traffic.
Your task definition and service are compiled into native Kubernetes on OKE at the build; afterward OCI's own load balancer and runtime carry every request.
#### The task definition and service A **task definition** describes a main container and any helper containers (sidecars). Tensor9 translates them into a multi-container **Pod** and copies the image to your registry during the build. Fargate expresses compute as a CPU value in \{0.25 … 16} vCPU with tied memory bands; on OKE that becomes Pod `requests` and `limits`, which are not restricted to Fargate's fixed size combinations. Requested resources must fit node capacity, scheduler rules and quota. An ECS service keeps a **desired count** of tasks always on. That maps directly to a Deployment's `replicas`, the desired replica count, not a guaranteed number of ready pods; scale-to-zero is not the default and is added only if you want it. **Application Auto Scaling** becomes a **HorizontalPodAutoscaler** on CPU, memory, or a custom metric, and a rolling update maps to the Deployment's own `RollingUpdate` with `maxSurge` and `maxUnavailable`. For other ECS operations, the **DAEMON** strategy becomes a **DaemonSet** (one Pod per node), and **ECS Exec** becomes `kubectl exec` into the Pod.
The task definition becomes a Pod spec and the service becomes a Deployment: containers and sizing land as requests and limits, desiredCount sets replicas, the DAEMON strategy becomes a DaemonSet, and ECS Exec becomes kubectl exec.
#### Networking, discovery, and load balancing ECS's **awsvpc** mode gives each task its own routable IP and security group. OKE offers the same model through **VCN-native pod networking** (`OCI_VCN_IP_NATIVE`): every Pod gets its own individually-addressable VCN IP, and a per-task security group maps to a **NetworkPolicy** to preserve network isolation between tasks. **Service discovery** by name, whether Cloud Map or DNS, is repointed at the build to a Kubernetes **Service** with cluster DNS, which is exactly ECS's name-based model. The service's `loadBalancer` block (the ALB or NLB target group its tasks register into) becomes a Kubernetes **Service** of type LoadBalancer (which provisions an OCI Load Balancer) plus an **Ingress** for host and path routing, with the target-group health check becoming the Pod's readiness probe. For supported routing rules, weights and certificates, see the [Application Load Balancer](/service-adapters/aws/networking-traffic/application-load-balancer) and [Network Load Balancer](/service-adapters/aws/networking-traffic/network-load-balancer) articles. This page places the Pod fleet behind that load balancer. For **ECS Service Connect**, a Service gives you name-based discovery, but Service Connect's injected mesh proxy and its built-in metrics are partial and need an added service mesh (Istio or Linkerd), which you configure separately. #### The OKE control plane Oracle operates an **enhanced cluster** control plane, and nodes come three ways: **managed node pools** (Oracle manages the node lifecycle on your compute), serverless **virtual node pools**, and **self-managed nodes**, with a cluster autoscaler. An ECS **capacity provider** maps to that node-pool layer, and a `FARGATE_SPOT` preference maps to a preemptible node pool . Control-plane patching is Oracle's to run. Oracle manages **cluster add-ons** through the OKE add-ons API: the **cluster autoscaler** scales node pools, the **OCI Native Ingress Controller** backs the Service-plus-Ingress mapping with an OCI Load Balancer, and the **VCN-native pod-networking CNI** is what gives each Pod its routable VCN IP. Enhanced clusters are also what include OKE Workload Identity, the identity binding covered in the next section. A weighted blue-green or canary split still uses a progressive-delivery layer you add (Argo Rollouts or Flagger); a plain rolling update is native.
OKE runs an enhanced control plane over managed, virtual, or self-managed node pools, and manages cluster addons through its addons API: the cluster autoscaler, the OCI Native Ingress Controller, and the VCN-native pod-networking CNI.
#### Pod identity: the task role The ECS task role identifies the application's AWS API calls. The Max credential path supplies the corresponding AWS role session. Native OCI access uses [OKE workload identity](https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contenggrantingworkloadaccesstoresources.htm): IAM policies match a workload principal's cluster, namespace and service account. This is separate from dynamic groups used for compute-instance principals. The AWS role and the OCI identity still stay consistent through a startup check: at boot the appliance fetches the Pod's real OKE workload identity and proves the declared AWS task role binds to it, failing closed if it does not. Inside the appliance the IAM surface then **reflects** that identity, so `aws sts get-caller-identity` and `iam:GetRole` answer as the task's own role, and calls to other AWS services use the Tensor9 adapters with that role. The **execution role** (the one ECS itself used to pull the image, fetch secrets, and write logs) is not needed, because OKE owns image pull and log delivery with its own identity.
Native OCI permissions use workload-principal policies; AWS adapter requests use the configured task role.
#### AWS request authorization For supported AWS API calls, Tensor9 evaluates the task role's IAM policy against the verified caller, action and resource; a denial overrides an allowance. See [AWS request authorization](/service-adapters/aws/compute-containers/ecs#aws-request-authorization) for policy preparation, wildcard support and verified policy delivery. Native OCI permissions are granted separately through OCI workload-principal policies. OKE workload identity selects the principal; it does not replace the AWS task-role policy or its credential exchange. #### Secrets and logging The container's `environment` variables are kept as-is, and its `secrets` references resolve from **OCI Vault** (often via the External Secrets Operator), the same store the SSM equivalence uses. The `awslogs` log driver becomes **OCI Logging**, with stdout and stderr delivered automatically; a custom FireLens log router remains a sidecar, with its destination and credentials configured for the target. #### Limitations Review the remaining service, deployment and networking differences below. △ Where it diverges * **Native OCI access uses workload-principal policies.** Scope those permissions to the cluster, namespace and service account separately from the AWS task-role policy. * **ECS Service Connect's mesh is partial:** a Service handles name-based discovery, but the injected mesh proxy and its built-in metrics need an added service mesh (Istio / Linkerd). * **Weighted blue-green or canary releases require extra tooling:** a plain rolling update is native; a weighted traffic split uses Argo Rollouts or Flagger. * **Capacity providers and Fargate Spot are the cluster's own:** the cluster owns capacity via its node pools, so a capacity-provider strategy maps to node pools and a Spot preference to a preemptible node pool. * **The task-metadata endpoint is served read-only.** `169.254.170.2` (`ECS_CONTAINER_METADATA_URI_V4`), the ECS task-metadata API, is served read-only; other AWS calls use their corresponding adapters. #### Other considerations Plan persistent storage, cluster capacity, logging, and secret access before deployment. * **Migrate mounted volumes separately:** a task definition and service hold no data, and the image is already a container image pulled into your own registry at the build, so adoption is a redeploy; any volume a task mounts (EFS, EBS) moves under its own service card. * **Plan node-pool capacity.** ECS on Fargate exposed no nodes, but on Oracle Cloud the workload lands on an OKE cluster whose managed, virtual, or self-managed node pools are an operational surface, while Oracle operates and patches the enhanced control plane. * **Costs include continuously running nodes.** `desiredCount` becomes always-on replicas billed as running nodes (or serverless virtual nodes), so capacity is sized for steady state rather than metered per Fargate task. * **Telemetry and secrets move to OCI's stores:** logs land in OCI Logging and `secrets` resolve from OCI Vault, so dashboards, alerts, and secret access follow the target services. #### Runtime tasks on OKE OKE schedules tasks on the selected node pools. OCI workload-principal policy controls native OCI access; it does not replace AWS task-role credentials or remove pending-image and capacity conditions. See [runtime task execution](/service-adapters/aws/compute-containers/ecs#runtime-task-execution) for supported task-definition and task-lifecycle calls. ## On Private Kubernetes | Operation | Area | Support | Depth | Notes | | ------------------------------------------------- | --------------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Capacity providers / FARGATE\_SPOT | Cluster | Out of scope | Full surface | the cluster owns capacity via its node pools; FARGATE\_SPOT maps to the cluster's spot node pools | | Identity: task role | Identity | Supported | Common | taskRoleArn → the target's workload identity, keyless; execution role is not needed | | Secrets and environment | Identity | Supported | Common | environment variables are set as-is; secrets map to the target's secret store | | Load balancer: service LB block | Load balancer | Supported | Common | ALB / NLB target group → the cluster's own LB backend; See the load-balancer adapter pages for individual routing-rule support. | | Logging: awslogs | Logging | Supported | Common | awslogs → the target's logging; a FireLens sidecar stays a logging sidecar | | Networking: Service Connect | Networking | Partial | Most usage | a Service gives discovery natively; the injected mesh proxy and its metrics need an added service mesh (Istio / Linkerd) | | Networking: awsvpc (per-task IP + security group) | Networking | Supported | Common | per-task ENI + security group → per-Pod IP + NetworkPolicy: individually addressable, with network isolation between pods; Cloud Map name → the cluster's own Service name | | ECS Exec | Runtime | Supported | Most usage | ECS Exec's interactive shell → kubectl exec into the Pod | | Task-metadata endpoint (runtime) | Runtime | Supported | Common | 169.254.170.2 / ECS\_CONTAINER\_METADATA\_URI\_V4 served read-only, the ECS task-metadata API | | DAEMON scheduling strategy | Service | Supported | Full surface | one copy per host → a DaemonSet, one Pod per node | | Service: autoscaling | Service | Supported | Most usage | Application Auto Scaling → a HorizontalPodAutoscaler on CPU / memory / custom | | Service: deployment controller | Service | Partial | Most usage | rolling update is native (maxSurge / maxUnavailable); weighted blue-green / canary requires release-management tooling (Gateway API / Argo Rollouts / Flagger / service mesh) | | Service: desired count | Service | Supported | Common | desiredCount → Deployment desired replicas; HPA minimum is configured separately | | Task definition: containers / sidecars | Task definition | Supported | Common | multi-container task → main container plus sidecars, native on every target | | Task definition: cpu / memory | Task definition | Supported | Common | Fargate \{0.25 … 16 vCPU} with tied memory bands → Pod requests / limits: values within node capacity and quota, without Fargate fixed-size combinations | | Task definition: image | Task definition | Supported | Common | Copies the container image to your registry during the build. | #### How it works On AWS your service runs as an **ECS service**: a task definition describes the container image and its sizing, and the service keeps a desired number of copies running on Fargate behind a load balancer. Tensor9 reads that task definition and service and, at the build, turns them into native Kubernetes on **a cluster you already operate**: a **Deployment** (or a **DaemonSet** for the DAEMON strategy) plus a **Service**. Kubernetes schedules the same container image. After deployment, clients reach your container through the target load balancer or cluster DNS. Tensor9 translates the stack during the build and does not proxy application traffic.
Your task definition and service are compiled into native Kubernetes on a cluster you operate at the build; afterward the cluster's own load balancer and runtime carry every request.
#### The task definition and service A **task definition** describes a main container and any helper containers (sidecars). Tensor9 translates them into a multi-container **Pod** and copies the image to your registry during the build. Fargate expresses compute as a CPU value in \{0.25 … 16} vCPU with tied memory bands; on the target cluster that becomes Pod `requests` and `limits`, which are not restricted to Fargate's fixed size combinations. Requested resources must fit node capacity, scheduler rules and quota. An ECS service keeps a **desired count** of tasks always on. That maps directly to a Deployment's `replicas`, the desired replica count, not a guaranteed number of ready pods; scale-to-zero is not the default and is added only if you want it (KEDA or Knative). **Application Auto Scaling** becomes a **HorizontalPodAutoscaler** on CPU, memory, or a custom metric, and a rolling update maps to the Deployment's own `RollingUpdate` with `maxSurge` and `maxUnavailable`. For other ECS operations, the **DAEMON** strategy becomes a **DaemonSet** (one Pod per node), and **ECS Exec** becomes `kubectl exec` into the Pod.
The task definition becomes a Pod spec and the service becomes a Deployment: containers and sizing become requests and limits, desiredCount becomes replicas, the DAEMON strategy becomes a DaemonSet, and ECS Exec becomes kubectl exec.
#### Networking, discovery, and load balancing ECS's **awsvpc** mode gives each task its own routable IP and security group. On the target cluster your CNI provides the same natively: every Pod gets its own individually-addressable IP, and a per-task security group maps to a **NetworkPolicy** to preserve network isolation between tasks. **Service discovery** by name, whether Cloud Map or DNS, is repointed at the build to a Kubernetes **Service** with cluster DNS, which is exactly ECS's name-based model; a ClusterIP Service plus DNS resolves the name the way Cloud Map did. The service's `loadBalancer` block (the ALB or NLB target group its tasks register into) becomes a Kubernetes **Service** (type LoadBalancer or ClusterIP) plus an **Ingress** for host and path routing, with the target-group health check becoming the Pod's readiness probe. For supported routing rules, weights and certificates, see the [Application Load Balancer](/service-adapters/aws/networking-traffic/application-load-balancer) and [Network Load Balancer](/service-adapters/aws/networking-traffic/network-load-balancer) articles. This page places the Pod fleet behind that load balancer. For ECS Service Connect : a Service provides name-based discovery, but Service Connect's injected mesh proxy and its built-in metrics are partial and need an added service mesh (Istio or Linkerd), which you configure separately. #### The cluster you operate The compiled Deployment and Service run on a cluster **you already operate** (kubeadm, k3s, or kops, or a managed cluster you bring), and it runs on any deployment target the appliance does, including fully disconnected environments. For a self-operated cluster, the customer maintains the **control plane and nodes**, including API server, etcd, upgrades and availability. For a customer-provided managed cluster, its provider retains those responsibilities, and an ECS **capacity provider** maps to your own node pools and cluster-autoscaler, with a `FARGATE_SPOT` preference mapping to your spot node pools. For a self-operated cluster, install and operate the required add-ons; for a customer-provided managed cluster, use its supported managed services. Required components include the ingress controller behind the Service-plus-Ingress mapping, the cluster autoscaler, the metrics or Prometheus stack, and the service mesh that hosts Service Connect's proxy. Confirm which components you operate and which are supplied by the cluster provider. Identity is native Kubernetes ServiceAccount and RBAC, covered next.
Use the existing cluster and confirm who operates its control plane, nodes and add-ons.
#### Pod identity: the task role An ECS task's **task role** is the same idea as EKS's IRSA: the identity the app's own code assumes. On the managed targets that federates to a cloud workload identity through the cluster's OIDC provider, while an existing cluster uses its configured identity integrations. Cluster API identity is native **Kubernetes ServiceAccount and RBAC**, which you own: the ServiceAccount is the workload's identity inside the cluster, and RBAC governs what it may do against the Kubernetes API. Separately, AWS API calls handled by Tensor9 use the selected credential adapter and task-role policy. Calls to real external cloud services need credentials authorized by that cloud, using the cluster's federation or secret configuration. The Tensor9 appliance still **reflects** the task role from the Pod's injected identity, so `aws sts get-caller-identity` and `iam:GetRole` answer as the task's own role. The **execution role** (the one ECS itself used to pull the image, fetch secrets, and write logs) is not needed, because the cluster owns image pull and log delivery.
Kubernetes permissions, AWS adapter sessions and real external-cloud credentials have separate scopes.
#### AWS request authorization For supported AWS API calls, Tensor9 evaluates the task role's IAM policy against the verified caller, action and resource; a denial overrides an allowance. See [AWS request authorization](/service-adapters/aws/compute-containers/ecs#aws-request-authorization) for policy preparation, wildcard support and verified policy delivery. Native external cloud permissions are granted separately, using credentials or federation authorized by that provider. Kubernetes RBAC separately governs the cluster API; AWS adapter policy evaluation remains local and can operate without a cloud IAM service. #### Secrets and logging The container's `environment` variables are set as-is, and its `secrets` references resolve from the cluster's own secret store, **Kubernetes Secrets** (often through the External Secrets Operator), the same store the SSM equivalence uses here. The `awslogs` log driver becomes **the target cluster's log stack**, with stdout and stderr delivered by the node's logging; a custom FireLens log router can run as a sidecar; configure its destination and credentials for the target logging service. #### Limitations Review the remaining service, deployment and networking differences below. △ Where it diverges * **ECS Service Connect's mesh is partial:** a Service provides name-based discovery, but the injected mesh proxy and its built-in metrics need an added service mesh (Istio / Linkerd) that you run. * **Weighted blue-green or canary releases require extra tooling:** a plain rolling update is native; a weighted traffic split uses Gateway API, Argo Rollouts, or Flagger. * **Capacity providers and Fargate Spot are the target cluster's own:** the cluster owns capacity via its node pools, so a capacity-provider strategy maps to your node pools and a Spot preference to your spot node pools. * **Configure each credential path.** Kubernetes RBAC governs cluster access. AWS adapters use the task role; real external services require credentials or federation authorized by their provider. * **The task-metadata endpoint is served read-only.** `169.254.170.2` (`ECS_CONTAINER_METADATA_URI_V4`), the ECS task-metadata API, is served read-only; other AWS calls use their corresponding adapters. #### Other considerations Plan persistent storage, cluster capacity, logging, and secret access before deployment. * **Migrate mounted volumes separately:** a task definition and service hold no data, and the image is already a container image pulled into your own registry at the build, so adoption is a redeploy; any volume a task mounts (EFS, EBS) moves under its own service card. * **Confirm cluster operating responsibilities.** For a self-operated cluster you maintain the control plane, nodes and add-ons. A customer-provided managed cluster retains its provider's control-plane and add-on services. * **Cost is your own infrastructure.** `desiredCount` becomes always-on replicas running on nodes you provision, sized by your node pools rather than metered per Fargate task. * **Telemetry and secrets are the cluster's own:** logs flow through the node's log stack and `secrets` resolve from Kubernetes Secrets (often via External Secrets), so there is no CloudWatch or Secrets Manager in the path; observability is whatever the cluster runs. #### Runtime tasks on your cluster Your cluster supplies scheduling, capacity and task execution. Kubernetes RBAC controls its API; selected credentials separately authorize AWS adapter calls. Check task readiness and container exits rather than treating request acceptance as successful execution. See [runtime task execution](/service-adapters/aws/compute-containers/ecs#runtime-task-execution) for supported task-definition and task-lifecycle calls. [Service Catalog](/service-adapters/catalog).