India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Amazon EKS, ECS & Fargate Container Platform Services in India
Amazon EKS is AWS's managed Kubernetes service and Amazon ECS is its AWS-native container orchestrator; both can run containers on EC2 nodes or on serverless AWS Fargate. NTSPL builds production container platforms for Indian SaaS, fintech and gaming companies, choosing between EKS and ECS, configuring Karpenter or Fargate capacity, ECR image pipelines and service networking so teams deploy several times a day safely.
AWS services in scope
The Problem Amazon EKS and Amazon ECS Solve
Container platforms fail in predictable ways. Clusters stuck three Kubernetes versions behind because nobody owns upgrades, now paying EKS extended support rates. Node groups of one instance type that cannot scale when that type runs short. Pods requesting 2 vCPUs and using 200 millicores, so a 40-node cluster is 15% utilized. Secrets in environment variables, images pulled from public registries without scanning, and a service mesh adopted for one feature that now blocks every upgrade. The problem is not running containers; it is operating the platform underneath them.
NTSPL first decides whether the team needs Kubernetes at all. If the services are a few dozen stateless APIs and workers, ECS on Fargate removes nodes, control-plane versions and add-on upgrades entirely. Where Kubernetes is justified by ecosystem, portability or scale, we build EKS with Karpenter or EKS Auto Mode, EKS Pod Identity, managed add-ons and a written upgrade cadence. Both paths use ECR with Amazon Inspector scanning, GitOps or pipeline-driven deploys and right-sized requests from measured usage.
When to Run Containers on Amazon EKS, ECS or Fargate (and When Not To)
Signals that point to containers & kubernetes on AWS
- Your EKS clusters are on a Kubernetes version past standard support and you are paying extended support charges.
- Cluster-wide CPU utilization averages under 25% while pods still sit Pending during scale-outs.
- Deployments take more than 30 minutes or need manual steps on servers.
- You run AWS App Mesh and need a supported replacement now that it has been discontinued.
- Auditors ask for per-service isolation and image vulnerability evidence for PCI DSS or RBI reviews.
- Traffic or job volume swings 5x or more within the hour, such as tournament starts or shipment cut-off times.
When a different approach is better
- A single monolith with steady load and no plan to split it may run more simply on EC2 Auto Scaling or AWS Elastic Beanstalk than on a Kubernetes cluster.
- Event handlers that run for seconds on irregular triggers are cheaper and simpler as AWS Lambda functions than as always-on container services.
- Teams without at least one engineer able to own Kubernetes upgrades and add-ons should choose ECS on Fargate rather than EKS.
AWS Container Building Blocks: EKS Clusters, ECS Services, Fargate, ECR, Karpenter and Service Connect
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Amazon EKS | Runs a managed, upstream-conformant Kubernetes control plane across multiple Availability Zones, with managed node groups, EKS Auto Mode, managed add-ons and access entries for cluster authentication. | You need the Kubernetes API, Helm charts, operators or CNCF tooling, or must run the same platform across AWS and other environments. |
| Amazon ECS | Schedules containers as tasks and services using AWS-native task definitions, with deep integration into ALB, IAM task roles, CloudWatch and AWS deployment tooling, and no control-plane charge. | The team wants containers without operating Kubernetes, and services are standard web APIs, workers and scheduled jobs. |
| AWS Fargate | Provides serverless compute for ECS tasks and EKS pods, sized per task by vCPU and memory, with each task isolated in its own micro-VM and no nodes to patch. | Patching and scaling nodes is unwanted overhead, workloads are bursty or isolation per task is a compliance requirement. |
| Amazon ECR | Stores private container images and OCI artefacts with immutable tags, lifecycle policies, cross-Region replication and enhanced scanning through Amazon Inspector. | Always, for production images; pulling from public registries at deploy time adds rate-limit and supply-chain risk. |
| Karpenter | Provisions right-sized EC2 nodes for pending pods within seconds, chooses across many instance types including Spot and Graviton, and consolidates under-used nodes. | EKS clusters run varied workloads where fixed node groups cause either pending pods or idle nodes. |
| Amazon ECS Service Connect | Gives ECS services service discovery, client-side load balancing, retries and traffic metrics through a managed proxy, without running a separate mesh control plane. | ECS microservices need service-to-service discovery and telemetry, including teams migrating from AWS App Mesh, which AWS has discontinued. |
EKS and ECS on Fargate container platform with Karpenter, ECR pipeline and GitOps delivery
EKS and ECS on Fargate container platform with Karpenter, ECR pipeline and GitOps delivery
External requests reach an Application Load Balancer managed by the AWS Load Balancer Controller or ECS service integration, which routes to pods on Karpenter-provisioned nodes or to Fargate tasks across three Availability Zones. Images flow from CI into ECR, where Inspector scans them before Argo CD or the deployment pipeline promotes them, and pods reach AWS services using EKS Pod Identity or ECS task roles.
Select any component
EKS and ECS on Fargate container platform with Karpenter, ECR pipeline and GitOps delivery: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Container Platform Decisions: EKS vs ECS, Node Provisioning, Upgrades and Service Networking
EKS or ECS
We choose ECS when the organization runs mostly stateless services, wants AWS-native operations and has no Kubernetes skills to retain. We choose EKS when the team depends on Helm charts, operators such as Strimzi or cert-manager, needs multi-cloud or on-premises portability with EKS Anywhere or Hybrid Nodes, or runs more than about 100 services with platform-team ownership. Mixed estates are fine: ECS on Fargate for PCI-scoped services and EKS for the rest.
Node provisioning: Karpenter, Auto Mode or Fargate
Karpenter gives the best bin-packing and Spot diversity for varied workloads, but the team operates it. EKS Auto Mode hands node provisioning, core add-ons and node patching to AWS for an added management fee on Auto Mode instances, suiting smaller platform teams. Fargate removes nodes entirely but does not support DaemonSets, privileged pods or GPUs. We often run system add-ons on a small managed node group and applications on Karpenter NodePools.
Kubernetes version and upgrade cadence
Each EKS version gets 14 months of standard support and then 12 months of extended support at a higher control-plane hourly rate. We plan one minor upgrade every quarter or two, check deprecated APIs with tooling before each, upgrade managed add-ons, then roll nodes. For high-risk jumps we build a new cluster and shift traffic blue-green, which is only possible if state lives outside the cluster.
Requests, limits and autoscaling
Most clusters we audit over-request CPU by 3-5x. We set requests from p95 usage observed over two weeks, set memory limits equal to requests to avoid noisy-neighbour eviction, and often omit CPU limits to avoid throttling. Horizontal Pod Autoscaler or KEDA scales pods on CPU, queue depth or custom metrics, and Karpenter then supplies nodes. On ECS, service auto scaling uses target tracking on CPU or ALB request count.
Service-to-service networking
AWS App Mesh has been discontinued, so ECS estates move to ECS Service Connect, which provides discovery, retries and metrics with less configuration. On EKS we use plain Kubernetes Services with the VPC CNI for most needs, VPC Lattice when services span accounts or mix ECS, EKS and Lambda, and Istio or Linkerd only when mutual TLS and fine traffic policies are genuine requirements with an owner.
How NTSPL Stands Up and Migrates Workloads onto an EKS or ECS Platform
Workload containerization review
Inventory services, check Dockerfiles for multi-stage builds, non-root users and arm64 support, and record CPU and memory profiles from current hosts.
Cluster or ECS environment build
Provision EKS or ECS through infrastructure code with private endpoints, VPC CNI prefix delegation, managed add-ons, Karpenter or Fargate profiles and logging.
Image supply chain
Set up ECR repositories, Inspector enhanced scanning, image signing and a pipeline gate that blocks critical vulnerabilities.
GitOps and deployment strategy
Install Argo CD or configure ECS deployments with circuit breaker and rolling or blue-green strategies, then onboard a first low-risk service.
Service migration waves and right-sizing
Move services in waves behind weighted DNS or ALB rules and adjust requests after two weeks of observed usage.
Upgrade and chaos rehearsal
Run a Kubernetes minor-version upgrade and node or task termination drills with AWS Fault Injection Service before declaring the platform production-ready.
What you receive
Securing EKS and ECS: Pod Identity, Image Scanning, Network Policies and Runtime Monitoring
Container security on AWS spans the image, the identity a pod uses, what it can reach on the network and what it does at runtime. NTSPL replaces node-wide instance roles with EKS Pod Identity or ECS task roles, scans images in ECR and blocks critical CVEs, enforces Pod Security Standards and network policies, and enables GuardDuty runtime monitoring so a compromised container is detected even when the image looked clean.
- EKS Pod Identity or ECS task roles granting each service only its own AWS permissions
- Amazon Inspector enhanced scanning on ECR push and continuously, with deploy-time gates
- Kubernetes network policies through the VPC CNI and security groups for pods for database access
- Envelope encryption of Kubernetes secrets with KMS, or retrieval from Secrets Manager via the CSI driver
- Amazon GuardDuty EKS protection and runtime monitoring for EKS, ECS and Fargate
Container Pricing Levers: Control Plane Fees, Fargate Sizing, Spot Nodes and Request Right-Sizing
EKS charges an hourly fee per cluster, higher on extended support, plus the EC2 or Fargate compute pods run on; EKS Auto Mode adds a management fee on instances it manages. ECS has no orchestration fee. Fargate bills per second on requested vCPU and memory, so over-sized task definitions cost directly. On EC2, cost depends on bin-packing efficiency, which Karpenter consolidation and accurate requests control.
- Karpenter consolidation with Spot and Graviton NodePools for stateless workloads
- Fargate Spot for interruption-tolerant ECS tasks and Compute Savings Plans for steady Fargate use
- Right-sizing pod requests and Fargate task sizes from observed p95 usage
- Staying within EKS standard support to avoid extended support control-plane rates
- Consolidating small clusters into fewer multi-tenant clusters with namespace isolation
Amazon EKS vs Amazon ECS: which container service should we use?
Choose on four criteria. Ecosystem: if you depend on Helm charts, Kubernetes operators or CNCF tools, or need the same platform across clouds and data centres, EKS is the answer. Operational load: ECS has no control-plane versions to upgrade, fewer add-ons and no orchestration fee, so a small team runs it with far less effort. Integration: ECS integrates natively with AWS services and IAM with less configuration; EKS needs controllers for the same results. Scale and flexibility: EKS gives finer scheduling control, custom resources and Karpenter-based node optimization for large, varied estates. In practice, ECS on Fargate fits teams with a few dozen services and no Kubernetes skills, while EKS fits platform teams supporting many squads.
Key facts about containers & kubernetes on AWS
Containers & Kubernetes on AWS in Practice
3 containers & kubernetes scenarios from Logistics technology (SaaS shipment tracking), Fintech (payment aggregator and gateway), Online gaming (casual and esports mobile games, non-real-money): the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Logistics SaaS scales shipment tracking to 9 crore events a day on EKS with Karpenter
Payments fintech moves card-processing services to ECS Fargate and narrows PCI DSS scope
Mobile gaming studio handles 6x tournament match-making spikes on EKS with Spot nodes
Retail chain connects 420 stores' POS to AWS through SD-WAN and Transit Gateway Connect
Containers & Kubernetes on AWS: Frequently Asked Questions
How much does Amazon EKS cost?
EKS charges a fixed hourly fee per cluster for the control plane during standard support, and a higher hourly fee once a cluster's Kubernetes version enters extended support. You also pay for the EC2 instances or Fargate resources your pods use, plus EKS Auto Mode's management fee if you enable it. ECS has no cluster fee; you pay only for compute.
What should we replace AWS App Mesh with?
AWS has discontinued App Mesh. For ECS services, the recommended path is Amazon ECS Service Connect, which provides service discovery, load balancing, retries and metrics. For EKS or mixed ECS, EKS and Lambda estates, Amazon VPC Lattice is the AWS-managed option, and Istio or Linkerd remain choices when you need full mesh features and can operate them.
How do we move from Docker on VMs or an on-premises Kubernetes cluster to EKS?
We containerize or reuse existing images, push them to ECR, convert manifests or Compose files to Helm charts or ECS task definitions, and externalize state to managed databases. Services move in waves behind weighted routing so each can be rolled back. From self-managed Kubernetes, most manifests port directly, with changes to storage classes, ingress and IAM integration.
Can we run PCI DSS or RBI-regulated workloads on ECS or EKS in India?
Yes. Amazon ECS, EKS and Fargate are in scope of AWS's PCI DSS attestation, and running them in Asia Pacific (Mumbai) keeps payment data in India as RBI's payment data storage directive requires. You still own controls inside the workload, such as segmentation, image scanning, logging and key management, which NTSPL builds into the platform.
Do we need Karpenter if we use EKS Auto Mode?
No. EKS Auto Mode includes Karpenter-based node provisioning managed by AWS, along with core add-ons and node patching. Self-managed Karpenter gives more control over NodePool settings and avoids the Auto Mode management fee, so teams with platform engineers often keep it while smaller teams prefer Auto Mode.
How often must we upgrade EKS clusters?
Each Kubernetes minor version on EKS gets 14 months of standard support, followed by 12 months of extended support at extra cost, after which clusters are upgraded automatically. With upstream releasing roughly three versions a year, plan an upgrade every four to six months. NTSPL runs these as rehearsed changes with deprecated-API checks and add-on upgrades.