Skip to main content
On this page

​
Coverage by target cloud

​
How the targets compare

Each row compares a capability of ECS with its adaptation on each target. A dash means this row is not stated for that target.

​
Max adaptation

​
Infrastructure-only adaptation

​
On Google Cloud

​
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 GKE: a Deployment (or a DaemonSet for the DAEMON strategy) plus a Service, on a regional GKE Standard control plane that Google 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.
Before: on AWS your container image runs as an ECS service on Fargate behind an Application Load Balancer. After: on Google Cloud the same image runs as a native GKE Deployment (or a DaemonSet) plus a Service, provisioned at the build and reached by Google's own load balancer. Tensor9 is not in the service's traffic path.Before: on AWS your container image runs as an ECS service on Fargate behind an Application Load Balancer. After: on Google Cloud the same image runs as a native GKE Deployment (or a DaemonSet) plus a Service, provisioned at the build and reached by Google's own load balancer. Tensor9 is not in the service's traffic path.

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.
A task definition with one or more containers, an image, and a cpu-and-memory sizing becomes a Kubernetes Pod spec, and an ECS service with a desired count becomes a Deployment with that many replicas. Fargate cpu and memory become Pod requests and limits within node capacity and quota. The DAEMON strategy becomes a DaemonSet and ECS Exec becomes kubectl exec.A task definition with one or more containers, an image, and a cpu-and-memory sizing becomes a Kubernetes Pod spec, and an ECS service with a desired count becomes a Deployment with that many replicas. Fargate cpu and memory become Pod requests and limits within node capacity and quota. The DAEMON strategy becomes a DaemonSet and ECS Exec becomes kubectl exec.

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 and 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 GKE control plane, operated by Google. Regional GKE Standard is selected for this mapping; you configure node pools. Native Autopilot is an alternative where Google sizes nodes, not the selected mapping. Node auto-provisioning and managed integrations require configuration: the GKE Gateway controller for Gateway API, Managed Service for Prometheus, Config Connector, Backup for GKE, and the Compute Engine, Filestore, and Cloud Storage CSI drivers. Capacity providers map to node pools and Fargate Spot to a spot node pool.The GKE control plane, operated by Google. Regional GKE Standard is selected for this mapping; you configure node pools. Native Autopilot is an alternative where Google sizes nodes, not the selected mapping. Node auto-provisioning and managed integrations require configuration: the GKE Gateway controller for Gateway API, Managed Service for Prometheus, Config Connector, Backup for GKE, and the Compute Engine, Filestore, and Cloud Storage CSI drivers. Capacity providers map to node pools and Fargate Spot to a spot node pool.

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.
An ECS task role is the same idea as EKS IRSA: a Kubernetes ServiceAccount federated to a cloud identity through the cluster's OIDC provider, so the pod gets scoped cloud credentials with no static secret. On GKE the ServiceAccount is bound to a Google service account through the cluster's workload-identity pool, and the pod reads its credentials from the GKE metadata server, keyless.An ECS task role is the same idea as EKS IRSA: a Kubernetes ServiceAccount federated to a cloud identity through the cluster's OIDC provider, so the pod gets scoped cloud credentials with no static secret. On GKE the ServiceAccount is bound to a Google service account through the cluster's workload-identity pool, and the pod reads its credentials from the GKE metadata server, keyless.

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

​
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.
Before: on AWS your container image runs as an ECS service on Fargate behind an Application Load Balancer. After: on Azure the same image runs as a native AKS Deployment (or a DaemonSet) plus a Service, provisioned at the build and reached by Azure's own load balancer. Tensor9 is not in the service's traffic path.Before: on AWS your container image runs as an ECS service on Fargate behind an Application Load Balancer. After: on Azure the same image runs as a native AKS Deployment (or a DaemonSet) plus a Service, provisioned at the build and reached by Azure's own load balancer. Tensor9 is not in the service's traffic path.

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.
A task definition with one or more containers, an image, and a cpu-and-memory sizing becomes a Kubernetes Pod spec, and an ECS service with a desired count becomes a Deployment with that many replicas. Fargate cpu and memory become Pod requests and limits within node capacity and quota. The DAEMON strategy becomes a DaemonSet and ECS Exec becomes kubectl exec.A task definition with one or more containers, an image, and a cpu-and-memory sizing becomes a Kubernetes Pod spec, and an ECS service with a desired count becomes a Deployment with that many replicas. Fargate cpu and memory become Pod requests and limits within node capacity and quota. The DAEMON strategy becomes a DaemonSet and ECS Exec becomes kubectl exec.

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 and 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.
The AKS control plane, operated by Microsoft. Nodes come as system and user node pools of different VM sizes, with a cluster autoscaler, and Pods can burst onto virtual nodes backed by Azure Container Instances. The control plane ships managed addons and cluster extensions: the managed KEDA addon for event-driven autoscaling, the Application Routing managed ingress, the Azure Key Vault Secrets Store CSI addon, Container Insights, Dapr, GitOps with Flux, and Azure Policy. Capacity providers map to node pools and Fargate Spot to a Spot node pool.The AKS control plane, operated by Microsoft. Nodes come as system and user node pools of different VM sizes, with a cluster autoscaler, and Pods can burst onto virtual nodes backed by Azure Container Instances. The control plane ships managed addons and cluster extensions: the managed KEDA addon for event-driven autoscaling, the Application Routing managed ingress, the Azure Key Vault Secrets Store CSI addon, Container Insights, Dapr, GitOps with Flux, and Azure Policy. Capacity providers map to node pools and Fargate Spot to a Spot node pool.

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.
An ECS task role is the same idea as EKS IRSA: a Kubernetes ServiceAccount federated to a cloud identity through the cluster's OIDC provider, so the pod gets scoped cloud credentials with no static secret. On AKS the ServiceAccount is federated to a Microsoft Entra identity (a user-assigned managed identity or app registration) through the AKS OIDC issuer with a federated identity credential, and the pod exchanges its ServiceAccount token for an Entra token, keyless.An ECS task role is the same idea as EKS IRSA: a Kubernetes ServiceAccount federated to a cloud identity through the cluster's OIDC provider, so the pod gets scoped cloud credentials with no static secret. On AKS the ServiceAccount is federated to a Microsoft Entra identity (a user-assigned managed identity or app registration) through the AKS OIDC issuer with a federated identity credential, and the pod exchanges its ServiceAccount token for an Entra token, keyless.

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 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 for supported task-definition and task-lifecycle calls.

​
On OCI

​
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.
Before: on AWS your container image runs as an ECS service on Fargate behind an Application Load Balancer. After: on Oracle Cloud the same image runs as a native OKE Deployment (or a DaemonSet) plus a Service, provisioned at the build and reached by OCI's own load balancer. Tensor9 is not in the service's traffic path.Before: on AWS your container image runs as an ECS service on Fargate behind an Application Load Balancer. After: on Oracle Cloud the same image runs as a native OKE Deployment (or a DaemonSet) plus a Service, provisioned at the build and reached by OCI's own load balancer. Tensor9 is not in the service's traffic path.

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.
A task definition with one or more containers, an image, and a cpu-and-memory sizing becomes a Kubernetes Pod spec, and an ECS service with a desired count becomes a Deployment with that many replicas. Fargate cpu and memory become Pod requests and limits within node capacity and quota. The DAEMON strategy becomes a DaemonSet and ECS Exec becomes kubectl exec.A task definition with one or more containers, an image, and a cpu-and-memory sizing becomes a Kubernetes Pod spec, and an ECS service with a desired count becomes a Deployment with that many replicas. Fargate cpu and memory become Pod requests and limits within node capacity and quota. The DAEMON strategy becomes a DaemonSet and ECS Exec becomes kubectl exec.

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 and 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.
The OKE control plane, operated by Oracle as an enhanced cluster. Nodes come as managed node pools, serverless virtual node pools, or self-managed nodes, with a cluster autoscaler. Oracle manages cluster addons through the OKE addons API: the cluster autoscaler, the OCI Native Ingress Controller, and the VCN-native pod-networking CNI. Capacity providers map to node pools and Fargate Spot to a preemptible node pool.The OKE control plane, operated by Oracle as an enhanced cluster. Nodes come as managed node pools, serverless virtual node pools, or self-managed nodes, with a cluster autoscaler. Oracle manages cluster addons through the OKE addons API: the cluster autoscaler, the OCI Native Ingress Controller, and the VCN-native pod-networking CNI. Capacity providers map to node pools and Fargate Spot to a preemptible node pool.

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: 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.
For native OCI access, IAM policies match the workload principal by cluster, namespace and service account. AWS adapter calls separately use the configured task role.For native OCI access, IAM policies match the workload principal by cluster, namespace and service account. AWS adapter calls separately use the configured task role.

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 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 for supported task-definition and task-lifecycle calls.

​
On Private Kubernetes

​
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.
Before: on AWS your container image runs as an ECS service on Fargate behind an Application Load Balancer. After: on a Kubernetes cluster you already operate the same image runs as a native Deployment (or a DaemonSet) plus a Service, provisioned at the build and reached by the cluster's own load balancer. Tensor9 is not in the service's traffic path.Before: on AWS your container image runs as an ECS service on Fargate behind an Application Load Balancer. After: on a Kubernetes cluster you already operate the same image runs as a native Deployment (or a DaemonSet) plus a Service, provisioned at the build and reached by the cluster's own load balancer. Tensor9 is not in the service's traffic path.

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.
A task definition with one or more containers, an image, and a cpu-and-memory sizing becomes a Kubernetes Pod spec, and an ECS service with a desired count becomes a Deployment with that many replicas. Fargate cpu and memory become Pod requests and limits within node capacity and quota. The DAEMON strategy becomes a DaemonSet and ECS Exec becomes kubectl exec.A task definition with one or more containers, an image, and a cpu-and-memory sizing becomes a Kubernetes Pod spec, and an ECS service with a desired count becomes a Deployment with that many replicas. Fargate cpu and memory become Pod requests and limits within node capacity and quota. The DAEMON strategy becomes a DaemonSet and ECS Exec becomes kubectl exec.

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 and 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 an existing self-operated or managed cluster. Confirm who operates its control plane, nodes, ingress, autoscaling, metrics, Gateway API and secrets integrations. Disconnected operation requires these dependencies to be available locally.Use an existing self-operated or managed cluster. Confirm who operates its control plane, nodes, ingress, autoscaling, metrics, Gateway API and secrets integrations. Disconnected operation requires these dependencies to be available locally.

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 ServiceAccounts and RBAC govern cluster access. AWS adapter calls use task-role sessions. Real external cloud access uses separately configured credentials or federation.Kubernetes ServiceAccounts and RBAC govern cluster access. AWS adapter calls use task-role sessions. Real external cloud access uses separately configured credentials or federation.

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 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 for supported task-definition and task-lifecycle calls. Service Catalog.