Forem: On-cloud7

Deployment Types in Amazon ECS (Elastic Container Service)

On-cloud7 — Wed, 31 Dec 2025 15:05:48 +0000

Introduction

Amazon Elastic Container Service (Amazon ECS) is a completely managed container orchestration solution that simplifies the deployment, management, and scaling of containerized applications on AWS. A key factor in operating applications on ECS is the method of deploying new versions of your application.

This blog will explore the deployment types in Amazon ECS, detail how each operates, identify when to utilize them, and discuss best practices. This blog is particularly beneficial for DevOps engineers, cloud engineers.

What Are ECS Deployment Types?

Deployment types in ECS specify the manner in which new versions of a task definition are introduced to your active services. ECS accommodates various deployment strategies based on your usage of:

1. ECS with EC2 launch type
2. ECS with AWS Fargate
3. ECS with an Application Load Balancer

The main ECS deployment types are:

1. Rolling Deployment (ECS Default)
2. Blue/Green Deployment (Using AWS CodeDeploy)
3. External Deployment (Custom / Third-party)

1. Rolling Deployment (ECS Default Deployment):
Overview:
Rolling deployment is the standard deployment method in Amazon ECS. In this approach, ECS systematically swaps out old tasks for new ones according to the revised task definition

How It Works:

ECS initiates new tasks utilizing the updated task definition.
Previous tasks are being phased out gradually.
The procedure is regulated by deployment configuration settings

2. Blue/Green Deployment (Using AWS CodeDeploy):
Overview:
Blue/Green deployment on ECS utilizes AWS CodeDeploy. This approach operates two distinct environments:

Blue – Present production edition

Green – Updated edition

Traffic is transitioned from Blue to Green in a regulated way

How It Works:
New assignments are initiated in the Green setting.
The load balancer directs traffic to Green.

Traffic management can be:

Simultaneously
Straight
Canary Completed old (blue) tasks are closed after success

Requirements:

Application Load Balancer (ALB)
ECS service with CodeDeploy deployment controller
Target groups (Blue & Green)

3. External Deployment (Custom Deployment):
Overview:
External deployment enables you to have complete control over the deployment process by utilizing third-party or custom tools rather than relying on ECS-managed deployments

How It Works:
ECS does NOT oversee task substitution.

Tasks and services are updated by an external system.

You manage scaling, traffic, and rollback

Common Tools Used:

Jenkins
GitHub Actions
Argo CD
Custom scripts using AWS SDK / CLI

Conclusion:

Amazon ECS offers various deployment choices to suit diverse application requirements. Rolling deployments are straightforward and economical, whereas Blue/Green deployments provide enterprise-level reliability and eliminate downtime. For complex situations, External deployments provide you with complete control.

Grasping these deployment types will assist you in creating strong, scalable, and dependable containerized applications on AWS ECS

Reference:

Amazon ECR - Architecture & Security

On-cloud7 — Sun, 21 Dec 2025 14:29:59 +0000

Introduction:

You can safely store, manage, and deploy container images (Docker or OCI) for your applications with Amazon Elastic Container Registry (ECR), a fully managed container image registry service provided by AWS. By closely integrating with AWS compute services like Amazon ECS, Amazon EKS, AWS Fargate, and more, ECR helps optimize container workflows, whether you're developing microservices, CI/CD pipelines, or scalable cloud-native applications.

What is Amazon Elastic Container Registry?

Amazon Elastic Container Registry (Amazon ECR) is an **AWS managed container image registry service that is secure, scalable, and reliable. **Amazon ECR supports private repositories with resource-based permissions using AWS IAM. This is so that specified users or Amazon EC2 instances can access your container repositories and images. You can use your preferred CLI to push, pull, and manage Docker images, Open Container Initiative (OCI) images, and OCI-compatible artifacts.

Features of Amazon ECR:

1. Image scanning helps in identifying software vulnerabilities in your container images. Each repository can be configured to scan on push. This ensures that each new image pushed to the repository is scanned. You can then retrieve the results of the image scan. For more information, see Scan images for software vulnerabilities in Amazon ECR.

2. Cross-Region and cross-account replication makes it easier for you to have your images where you need them. This is configured as a registry setting and is on a per-Region basis. For more information, see Private registry settings in Amazon ECR.

3. Pull through cache rules provide a way to cache repositories in an upstream registry in your private Amazon ECR registry. Using a pull through cache rule, Amazon ECR will periodically reach out to the upstream registry to ensure the cached image in your Amazon ECR private registry is up to date. For more information, see Sync an upstream registry with an Amazon ECR private registry.

4. Repository creation templates allow you to define the settings for repositories created by Amazon ECR on your behalf during pull through cache, create on push, or replication actions. You can specify tag immutability, encryption configuration, repository policies, lifecycle policies, and resource tags for automatically created repositories. For more information, see Templates to control repositories created during a pull through cache, create on push, or replication action.

Amazon ECR Architecture:

1. Core Components

A registry is a logical collection of one or more repositories.
Repositories: Holds container images that can be versioned and tagged.
Images & Tags: Your application and its dependencies are bundled together in a container image. Versioning them is aided by tags.
Storage: ECR keeps your photos in Amazon S3, where they are highly available and durable.

2. How ECR Works (High-Level Flow):

Authentication: AWS IAM & STS requests a login token from your client (such as Docker CLI).
Push: Images are pushed to an ECR repository using the token.
Store: Amazon S3 is where ECR stores these photos.
Pull: During deployments, images are pulled from ECR by ECS, EKS, or other environments.

3. Integration with AWS Ecosystem:

Amazon ECS
Amazon EKS
AWS Fargate
AWS Lambda

Security in Amazon ECR:

1.Access Control:

_ECR uses AWS Identity and Access Management (IAM) to control access:
Grant permissions at repository level (push/pull actions)
Use resource-based policies for cross-account access
Use temporary security credentials via AWS STS _

2.Encryption:

You can transfer your container images to and from Amazon ECR via HTTPS. Your images are also automatically encrypted at rest using Amazon S3 server-side encryption. Amazon ECR also lets you choose your own key managed by AWS Key Management Service (AWS KMS) to encrypt images at rest.

3.Vulnerability Scanning:

You can enable Amazon ECR to automatically scan your container images for a broad range of operating system vulnerabilities. You can also scan images using an API command, and Amazon ECR will notify you over API and in the console when a scan completes. For enhanced image scanning, you can turn on Amazon Inspector.

4.Network Security:

ECR supports VPC interface endpoints using AWS PrivateLink, so your services can pull images privately without going through the internet.

5.Image Integrity:

*Amazon ECR now supports managed container image signing to enhance your security posture and eliminate the process of setting up signing. Container image signing allows you to verify that images are from trusted sources. With managed signing, ECR simplifies setting up container image signing to just a few clicks in the ECR Console or a single API call. To enable managed signing, you create a signing rule with a signing profile, which is a unique AWS resource that allows you to specify parameters such as signature validity and which IAM principals can sign. *

USE CASES:

Microservices & Cloud apps
CICD pipelines
Hybrid Workloads

Conclusion:

We conclude this blog as Amazon ECR is Elastic Container Registry which is used to store images securely on AWS trusted infrastructure. It also has features like IAM Access Controls,encryption,image scanning and so on with other aws services.

References:

1.https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html?
2.https://aws.amazon.com/ecr/features
3.https://aws.amazon.com/ecr/faqs/
4.https://docs.aws.amazon.com/AmazonECR/latest/userguide/security.html?
5.https://www.certbolt.com/certification/comprehensive-guide-to-containers-on-aws-modernizing-application-deployment/
6.https://docs.aws.amazon.com/config/latest/developerguide/security-best-practices-for-ECR.html?

END-TO-END Deployment Of Django App on AWS EKS Cluster

On-cloud7 — Sat, 06 Dec 2025 18:21:44 +0000

Today, we are deploying a Django app on an EKS Cluster and will Learn How to create an EKS cluster and deploy the app on it.

Step 1: Create a EC2 instance to run all the dependencies on the instance.

Step 2: Configure the AWS CLI, check the AWS version.

Step3: Install EKSCTL and Kubectl in the master machine(ie: EC2 instance).

*Step 4: Create an IAM user, give access to the user (administrator access) and create an access key to configure the AWS *

Step 5: Create a Cluster.

Step 6: Create an OIDC Provider.

_Now the Cluster is created in the EKS Services in AWS _

Step 7: Update Kubectl Context: so that local and remote are connected.

Step 8: Create a Folder and clone the app in the folder.

mkdir K8-practice
git clone app url

Step 9: Create a YAML file for the namespace in Kubernetes folder.

kubectl apply -f namespace.yml
kubectl get namespaces

Step 10: Create a yaml file for Pod in kubernetes folder.

kubectl apply -f pod.yml
kubectl get pods -n nginx

Step 11: Create a yaml for Deployment in kubernetes folder.

kubectl apply -f deployment.yml
kubectl get deployments -n nginx

Step 12: Create a Service yaml in kubernetes folder.

kubectl apply -f service.yml
kubectl get svc 
kubectl port-forward service/my-service 8000:8000 --address=0.0.0.0

Reference:

Conclusion:
Overall, deploying Django on Amazon EKS helped me understand the complete workflow—from Dockerizing the application, pushing images to ECR, configuring Kubernetes manifests, and finally exposing the service through a load balancer. This approach not only improves performance and availability but also lays the foundation for implementing CI/CD and future scaling.

[Boost]

On-cloud7 — Sun, 30 Nov 2025 18:08:08 +0000

How to Create An Amazon EKS - Step by Step for Beginners

On-cloud7 ・ Nov 30 '25

#aws #eks #containers #cloud

How to Create An Amazon EKS - Step by Step for Beginners

On-cloud7 — Sun, 30 Nov 2025 18:07:38 +0000

What is Amazon EKS?

Amazon EKS: Simplified Kubernetes Management

Amazon Elastic Kubernetes Service (EKS) provides a fully managed Kubernetes service that eliminates the complexity of operating Kubernetes clusters. With EKS, you can:

Deploy applications faster with less operational overhead

Scale seamlessly to meet changing workload demands

Improve security through AWS integration and automated updates

Choose between standard EKS or fully automated EKS Auto Mode

>> Here are the Steps to Create a EKS Cluster from Scratch:

Pre-requisites:

_Step 1:Create a Ec2 Instance So that we can Configure AWS CLI, Eksctl,kubectl on it _
**
**_Step 2: Connect the EC2 with the help of SSH _

_Step 3: Create a IAM User give permissions to the user and create a Access key _

Step 4 : Configue the AWS CLI in the EC2 Instance

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
sudo apt install unzip
unzip awscliv2.zip
sudo ./aws/install
aws configure

_Step 5: Install the Kubectl in the EC2 Instance _

curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.19.6/2021-01-05/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin
kubectl version --short --client

Step 6: Install the Eksctl in the EC2 Instance

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version

Steps to create EKS cluster:

Step 7: Create EKS Cluster

eksctl create cluster --name=my-cluster \
                      --region=us-west-2 \
                      --version=1.30 \
                      --without-nodegroup

Step 8:Associate IAM OIDC Provider :It means connecting an external identity provider (OIDC)—like GitHub, Kubernetes (EKS), or any OIDC-supported service—to AWS IAM so that those users or services can securely request temporary AWS permissions without using long-term AWS keys.

eksctl utils associate-iam-oidc-provider \
    --region us-west-2 \
    --cluster my-cluster \
    --approve

Step 9:Create Nodegroup in the EC2 instance

eksctl create nodegroup --cluster=my-cluster \
                       --region=us-west-2 \
                       --name=my-cluster \
                       --node-type=t2.medium \
                       --nodes=2 \
                       --nodes-min=2 \
                       --nodes-max=2 \
                       --node-volume-size=29 \
                       --ssh-access \
                       --ssh-public-key=eks-nodegroup-key

Note: Make sure the ssh-public-key "eks-nodegroup-key is available in your aws account"

step 10: Update Kubectl Context

aws eks update-kubeconfig --region us-west-2 --name my-cluster

Step 11:Delete EKS Cluster

eksctl delete cluster --name=my-cluster --region=us-west-2

Reference:

1.https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html
2.https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-eks-cluster.html
3.https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html
4.https://github.com/On-cloud7/kubestarter/blob/main/eks_cluster_setup.md

[Boost]

On-cloud7 — Tue, 18 Nov 2025 16:41:27 +0000

Inside Amazon EKS: Understanding Its Core Architecture

On-cloud7 ・ Nov 18 '25

#aws #eks #cloudcomputing #docker

Inside Amazon EKS: Understanding Its Core Architecture

On-cloud7 — Tue, 18 Nov 2025 16:36:14 +0000

Amazon Elastic Kubernetes Service (EKS) has become a popular option for running containerized applications at scale. Before deploying workloads or setting up CI/CD pipelines, it’s crucial to understand how EKS is structured internally.

This blog will guide you through the core architecture of Amazon EKS, discussing the control plane, worker nodes, networking, IAM roles, and the CNI plugin that facilitates pod communication.

EKS Architecture Diagram

                 ┌───────────────────────────────────────────┐

                 │           AWS Managed Control Plane        │

                 │───────────────────────────────────────────│

                 │   • API Server                             │

                 │   • etcd (Multi-AZ HA)                     │

                 │   • Scheduler                              │

                 │   • Controller Manager                     │

                 └───────────────────────────────────────────┘

                                  ▲

                                  │ Secure ENI Connection

                                  │

 ┌───────────────────────────────────────────────────────────────────────────┐

 │                                   Your VPC                                │

 │───────────────────────────────────────────────────────────────────────────│

 │                           Private Subnets (Nodes)                         │

 │                                                                           │

 │        ┌───────────────────┐                       ┌───────────────────┐  │

 │        │   Worker Node     │                       │   Worker Node     │  │

 │        │  (EC2 / Fargate)  │                       │  (EC2 / Fargate)  │  │

 │        └──────────┬────────┘                       └──────────┬────────┘  │

 │                   │ CNI (VPC IPs)                             │           │

 │                   ▼                                            ▼           │

 │        ┌───────────────────┐                       ┌───────────────────┐  │

 │        │     Pod (App)     │                       │     Pod (App)     │  │

 │        │   Pod IP from     │                       │   Pod IP from     │  │

 │        │       VPC         │                       │       VPC         │  │

 │        └───────────────────┘                       └───────────────────┘  │

 │                                                                           │

 │───────────────────────────── Public Subnets ─────────────────────────────│

 │        ┌───────────────────┐                ┌──────────────────────────┐ │

 │        │     ALB / NLB     │  ───────────→  │     Internet / Clients   │ │

 │        └───────────────────┘                └──────────────────────────┘ │

 └───────────────────────────────────────────────────────────────────────────┘

📌 What is Amazon EKS?

Amazon EKS is a fully managed Kubernetes service that simplifies the setup and management of Kubernetes control-plane components. AWS takes care of cluster reliability, scalability, and updates, allowing you to concentrate on running applications instead of maintaining control-plane infrastructure.

But even though EKS is “managed,” understanding its architecture is crucial for designing secure, scalable workloads.

EKS Architecture Overview

At a high level, EKS consists of two major layers:
1.Control Plane — fully managed by AWS
2.Worker Nodes — run inside your AWS account and can be EC2 instances or Fargate
These components operate inside your VPC, communicate via the AWS VPC CNI, and are secured through IAM roles and Kubernetes RBAC.

Let’s break each component down in detail.

1. EKS Control Plane

The EKS control plane is the brain of your Kubernetes cluster. AWS manages it completely, which includes:

Kubernetes API Server
Handles:

kubectl requests
scheduling instructions
cluster state changes This is the only entry point for cluster operations

etcd (Highly Available Data Store)
Stores:

cluster state
pod configs
secrets
service metadata EKS provides a multi-AZ, automatically replicated etcd, ensuring high availability.

Scheduler
Responsible for placing pods on available nodes based on:

node capacity
taints & tolerations
affinity rules

Controller Manager
Manages:

deployments
replicas
node lifecycle
service endpoints

Managed & Isolated by AWS
You cannot SSH or modify the control plane.
AWS handles:

version upgrades
patching
availability
scalability This separation improves security and eliminates operational burden.

2. Worker Nodes

Worker nodes actually run your applications. You manage them (unless using Fargate).

EKS supports three types of nodes:
a. Self-Managed EC2 Nodes
You deploy an EC2 Auto Scaling Group manually.
Pros:

full flexibility
custom AMIs Cons:
more maintenance

b. Managed Node Groups (Preferred)

AWS automates:

provisioning
patching
draining during updates You choose the instance type, and AWS does the heavy lifting.

c. AWS Fargate
Serverless compute for pods.

event-driven workloads
lightweight services
cost optimization for low-traffic workloads

3. VPC — Networking Backbone of EKS

Your EKS cluster is created inside a Virtual Private Cloud (VPC).

Private subnets → worker nodes
Public subnets → load balancers
Route tables → traffic flow
NAT Gateway → private pods access the internet
EKS ENIs → elastic network interfaces The control plane lives in AWS-managed VPCs, but connects securely to your VPC using elastic network interfaces (ENIs).

4. AWS VPC CNI Plugin (Container Networking Interface)

EKS uses the Amazon VPC CNI plugin, which assigns VPC-native IP addresses directly to pods.

Benefits:

Pods behave like first-class VPC resources
Simplifies network policies
Eliminates overlay networks
Supports security groups for pods

How It Works:

CNI attaches ENIs to the worker node
Each ENI has multiple secondary IPs
These IPs are assigned to pods

5. IAM Roles in EKS

a. EKS Cluster Role
Allows EKS to create or manage:

EC2 resources
ENIs
security groups

b. Node Instance Role (Worker Node IAM Role)
Each EC2 node uses this role to:

pull containers from ECR
join the EKS cluster
interact with CloudWatch logs

c. IRSA (IAM Roles for Service Accounts)
This is one of the most powerful EKS features.

IRSA maps Kubernetes service accounts → IAM roles, allowing fine-grained access control.
Examples:

A pod can access S3
A pod can push to CloudWatch
A pod can read Secrets Manager

Putting It All Together
Here’s how the flow works in a real EKS environment:

User runs kubectl apply
API Server (control plane) validates the request
Scheduler places a pod on a worker node
CNI assigns a VPC IP to the pod
IAM + RBAC verify permissions
Load balancers route traffic to the pod
Metrics/logs flow to CloudWatch/Grafana

Conclusion

Amazon EKS provides a highly scalable, secure, and production-ready Kubernetes environment by combining:

AWS-managed control plane
Flexible worker node options
Tight IAM security
Native VPC networking
Auto-scaling capabilities

Understanding EKS architecture lays the foundation for mastering deployments, networking, scaling, and security in Kubernetes on AWS.

📚 References

Amazon EKS User Guide – Amazon EKS Architecture
Amazon EKS Best Practices Guide – Cluster Architecture
Amazon VPC CNI Plugin for Kubernetes – Networking Deep Dive
AWS Shared Responsibility Model for Containers
Kubernetes Documentation – Key Components (API Server, Scheduler, etc.)
AWS Containers Blog – EKS Control Plane and Node Management

[Boost]

On-cloud7 — Fri, 07 Nov 2025 15:34:35 +0000

Understanding Amazon EKS: How Kubernetes Runs on AWS

On-cloud7 ・ Nov 7 '25

#aws #eks #cloud #container

Understanding Amazon EKS: How Kubernetes Runs on AWS

On-cloud7 — Fri, 07 Nov 2025 15:34:05 +0000

Containers and Kubernetes have become central to today's cloud-native world. Due to their complexity, many teams rely on managed services rather than building from scratch. On AWS, Amazon EKS provides a managed Kubernetes environment that reduces operational overhead while preserving full Kubernetes compatibility.
In this blog we will examine how EKS manages the control plane, how the worker nodes (data plane) function, and how the integrations with AWS services connect everything. We aim to help you understand what happens under the hood, giving you a solid foundation for EKS in your DevOps or cloud-ops work.

What is Amazon EKS?
Amazon Elastic Kubernetes Service (EKS) provides a fully managed Kubernetes service that eliminates the complexity of operating Kubernetes clusters. With EKS, you can:

Deploy applications faster with less operational overhead
Scale seamlessly to meet changing workload demands
Improve security through AWS integration and automated updates
Choose between standard EKS or fully automated EKS Auto Mode

Amazon Elastic Kubernetes Service (Amazon EKS) is the premiere platform for running Kubernetes clusters, both in the Amazon Web Services (AWS) cloud and in your own data centers (EKS Anywhere and Amazon EKS Hybrid Nodes).

Amazon EKS simplifies building, securing, and maintaining Kubernetes clusters. It can be more cost effective at providing enough resources to meet peak demand than maintaining your own data centers. Two of the main approaches to using Amazon EKS are as follows:

EKS standard: AWS manages the Kubernetes control plane when you create a cluster with EKS. Components that manage nodes, schedule workloads, integrate with the AWS cloud, and store and scale control plane information to keep your clusters up and running, are handled for you automatically.

EKS Auto Mode: Using the EKS Auto Mode feature, EKS extends its control to manage Nodes (Kubernetes data plane) as well. It simplifies Kubernetes management by automatically provisioning infrastructure, selecting optimal compute instances, dynamically scaling resources, continuously optimizing costs, patching operating systems, and integrating with AWS security services.

The following diagram illustrates how Amazon EKS integrates your Kubernetes clusters with the AWS cloud, depending on which method of cluster creation you choose:

Features of Amazon EKS:
Amazon EKS provides the following high-level features:

Management interfaces:
EKS offers multiple interfaces to provision, manage, and maintain clusters, including AWS Management Console, Amazon EKS API/SDKs, CDK, AWS CLI, eksctl CLI, AWS CloudFormation, and Terraform. For more information, see Get started with Amazon EKS and Amazon EKS cluster lifecycle and configuration.

Access control tools:
EKS relies on both Kubernetes and AWS Identity and Access Management (AWS IAM) features to manage access from users and workloads. For more information, see Grant IAM users and roles access to Kubernetes APIs and Grant Kubernetes workloads access to AWS using Kubernetes Service Accounts.

Compute resources:
For compute resources, EKS allows the full range of Amazon EC2 instance types and AWS innovations such as Nitro and Graviton with Amazon EKS for you to optimize the compute for your workloads. For more information, see Manage compute resources by using nodes.

Storage:
EKS Auto Mode automatically creates storage classes using EBS volumes. Using Container Storage Interface (CSI) drivers, you can also use Amazon S3, Amazon EFS, Amazon FSX, and Amazon File Cache for your application storage needs. For more information, see Use application data storage for your cluster.

Security:
The shared responsibility model is employed as it relates to Security in Amazon EKS. For more information, see Security best practices, Infrastructure security, and Kubernetes security.

Monitoring tools:
Use the observability dashboard to monitor Amazon EKS clusters. Monitoring tools include Prometheus, CloudWatch, Cloudtrail, and ADOT Operator. For more information on dashboards, metrics servers, and other tools, see EKS cluster costs and Kubernetes Metrics Server.

Kubernetes compatibility and support:
Amazon EKS is certified Kubernetes-conformant, so you can deploy Kubernetes-compatible applications without refactoring and use Kubernetes community tooling and plugins. EKS offers both standard support and extended support for Kubernetes. For more information, see Understand the Kubernetes version lifecycle on EKS.

Related Services to use with Amazon EKS

You can use other AWS services with the clusters that you deploy using Amazon EKS:

Amazon EC2:
Obtain on-demand, scalable compute capacity with Amazon EC2.

Amazon EBS:
Attach scalable, high-performance block storage resources with Amazon EBS.

Amazon ECR:
Store container images securely with Amazon ECR.

Amazon CloudWatch:
Monitor AWS resources and applications in real time with Amazon CloudWatch.

Amazon Prometheus:
Track metrics for containerized applications with Amazon Managed Service for Prometheus.

Elastic Load Balancing:
Distribute incoming traffic across multiple targets with Elastic Load Balancing.

Amazon GuardDuty:
Detect threats to EKS clusters with Amazon GuardDuty.

AWS Resilience Hub:
Assess EKS cluster resiliency with AWS Resilience Hub.

Amazon EKS architecture:
Control plane:
Amazon EKS ensures every cluster has its own unique Kubernetes control plane. This design keeps each cluster’s infrastructure separate, with no overlaps between clusters or AWS accounts. The setup includes:

Distributed components
The control plane positions at least two API server instances and three etcd instances across three AWS Availability Zones within an AWS Region.

Optimal performance
Amazon EKS actively monitors and adjusts control plane instances to maintain peak performance.

Resilience
If a control plane instance falters, Amazon EKS quickly replaces it, using different Availability Zone if needed.

Consistent uptime
By running clusters across multiple Availability Zones, a reliable API server endpoint availability Service Level Agreement (SLA) is achieved.

Amazon EKS uses Amazon Virtual Private Cloud (Amazon VPC) to limit traffic between control plane components within a single cluster. Cluster components can’t view or receive communication from other clusters or AWS accounts, except when authorized by Kubernetes role-based access control (RBAC) policies.

Compute:

In addition to the control plane, an Amazon EKS cluster has a set of worker machines called nodes. Selecting the appropriate Amazon EKS cluster node type is crucial for meeting your specific requirements and optimizing resource utilization. Amazon EKS offers the following primary node types:

EKS Auto Mode:
EKS Auto Mode extends AWS management beyond the control plane to include the data plane, automating cluster infrastructure management. It integrates core Kubernetes capabilities as built-in components, including compute autoscaling, networking, load balancing, DNS, storage, and GPU support. EKS Auto Mode dynamically manages nodes based on workload demands, using immutable AMIs with enhanced security features. It automates updates and upgrades while respecting Pod Disruption Budgets, and includes managed components that would otherwise require add-on management. This option is ideal for users who want to leverage AWS expertise for day-to-day operations, minimize operational overhead, and focus on application development rather than infrastructure management.

AWS Fargate:
Fargate is a serverless compute engine for containers that eliminates the need to manage the underlying instances. With Fargate, you specify your application’s resource needs, and AWS automatically provisions, scales, and maintains the infrastructure. This option is ideal for users who prioritize ease-of-use and want to concentrate on application development and deployment rather than managing infrastructure.

Karpenter:
Karpenter is a flexible, high-performance Kubernetes cluster autoscaler that helps improve application availability and cluster efficiency. Karpenter launches right-sized compute resources in response to changing application load. This option can provision just-in-time compute resources that meet the requirements of your workload.

Managed node groups:
Managed node groups are a blend of automation and customization for managing a collection of Amazon EC2 instances within an Amazon EKS cluster. AWS takes care of tasks like patching, updating, and scaling nodes, easing operational aspects. In parallel, custom kubelet arguments are supported, opening up possibilities for advanced CPU and memory management policies. Moreover, they enhance security via AWS Identity and Access Management (IAM) roles for service accounts, while curbing the need for separate permissions per cluster.

Self-managed nodes:
Self-managed nodes offer full control over your Amazon EC2 instances within an Amazon EKS cluster. You are in charge of managing, scaling, and maintaining the nodes, giving you total control over the underlying infrastructure. This option is suitable for users who need granular control and customization of their nodes and are ready to invest time in managing and maintaining their infrastructure.

Amazon EKS Hybrid Nodes:
With Amazon EKS Hybrid Nodes, you can use your on-premises and edge infrastructure as nodes in Amazon EKS clusters. Amazon EKS Hybrid Nodes unifies Kubernetes management across environments and offloads Kubernetes control plane management to AWS for your on-premises and edge applications.

Conclusion:

Amazon EKS brings together the best of Kubernetes and AWS — offering the flexibility of open-source container orchestration with the reliability, scalability, and security of a managed cloud platform. By abstracting the complexity of managing the control plane, networking, and scaling, EKS enables DevOps teams to focus more on delivering applications rather than maintaining infrastructure.

Whether you use EKS Auto Mode for full automation, Fargate for serverless container execution, or managed node groups for customizable compute control, EKS adapts to diverse operational models and workloads. Its deep integration with AWS services such as IAM, CloudWatch, ECR, and GuardDuty ensures a consistent and secure environment across every layer of deployment.

In essence, EKS is not just “Kubernetes on AWS” — it’s a bridge between containerized innovation and cloud-native efficiency. Understanding how EKS manages the control plane, worker nodes, and ecosystem integrations equips DevOps engineers to design robust, scalable, and production-ready container platforms.

References:

Amazon EKS Architecture – AWS Documentation(https://docs.aws.amazon.com/eks/latest/userguide/eks-architecture.html?utm_source=chatgpt.com)
https://aws.amazon.com/documentation-overview/eks/?utm_source=chatgpt.com
https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html

From Docker to AWS: Step-by-Step Guide — Push to ECR and Deploy on ECS

On-cloud7 — Wed, 15 Oct 2025 16:33:41 +0000

🚀 Goal

Build a Docker image locally, push it to Amazon ECR, and deploy it to Amazon ECS (Fargate or EC2) behind an Application Load Balancer, with autoscaling and health checks.

Prerequisites

AWS account with permission to use ECR, ECS, IAM, ALB, and (optional) CloudWatch/Autoscaling.
AWS CLI installed and configured (aws configure) or access to AWS Console.
Docker installed locally.
Basic app packaged with a Dockerfile.

1. AWS CLI & IAM setup
What to do: Ensure your local environment has AWS credentials and an IAM user/role with permissions for ECR and ECS.

aws configure → enter AWS Access Key ID, Secret Access Key, region, and output format.

(Optional) Create an IAM policy/role for CI system later (CodePipeline/GitHub Actions).

Tip: For production, use fine-grained roles (ECR read/write, ECS create/update, ALB modify). Avoid using root credentials.

Step 1: Create an ECR Repository

If you haven’t already created it:

Option 1 – Using CLI:

aws ecr create-repository --repository-name priyanka-repo --region us-east-1

Option 2 – Using Console:

Go to AWS Management Console → ECR → Create repository

Name it priyanka-repo

Copy the repository URI, something like:

157168991173.dkr.ecr.us-east-1.amazonaws.com/priyanka-repo

_ Step 2: Authenticate Docker to ECR_

Run this command to log in to your ECR registry:

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 157168991173.dkr.ecr.us-east-1.amazonaws.com

This lets Docker push/pull images from your private ECR.

_ Step 3: Build the Docker Image_

If you have a Dockerfile in your project directory, build the image:

docker build -t priyanka-repo .

_ Step 4: Tag the Docker Image_

Tag it with your ECR repository URI:

docker tag priyanka-repo:latest 157168991173.dkr.ecr.us-east-1.amazonaws.com/priyanka-repo:latest

Step 5: Push the Image to ECR

Finally, push your image:

docker push 157168991173.dkr.ecr.us-east-1.amazonaws.com/priyanka-repo:latest

✅ After Success:
You’ll see your image appear in the AWS Console → ECR → Repositories → priyanka-repo → Images.

6.Create an ECS cluster

Decide between Fargate (serverless) or EC2 (you manage instances).

Console: AWS → ECS → Clusters → Create cluster → choose Networking only (Fargate) or EC2 Linux + Networking.

What this provides: a logical grouping for tasks/services.

7. Create a Task Definition

A task definition declares how containers run (image, CPU, memory, ports, env vars, log config).

Console: Task Definitions → Create new Task Definition → Fargate (or EC2).

Main fields:

Task Role / Execution Role – IAM role for AWS API access / pulling from ECR.

Container Definition:

Image: ECR URI (.../my-app:latest)

Port mappings: container port (e.g., 80 or 5000)

Environment variables (if required)

Health check command (optional)

Log configuration (CloudWatch Logs)

Quick example JSON snippet (conceptual):

{
  "family": "my-app-task",
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "my-app",
      "image": "<aws_account_id>.dkr.ecr.<region>.amazonaws.com/my-app:latest",
      "portMappings": [{"containerPort": 80, "protocol": "tcp"}],
      "essential": true,
      "memory": 512,
      "cpu": 256
    }
  ],
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512"
}

8. Create ECS Service
A Service ensures a desired number of task instances are running and manages deployment/rolling updates.

Console: Clusters → Select cluster → Create → Create Service
Key options:

Launch type: Fargate (recommended) or EC2.

Service name (e.g., my-app-service).

Number of tasks (desired count): initial minimum (e.g., 2).

Deployment options: Rolling update (default).

Assign public IP? If tasks need internet access and you’re using public subnets.

Important: Choose the same subnets/security groups as your ALB target group (for network reachability).

9. Create Application Load Balancer (ALB) & Target Group

ALB will route incoming traffic to ECS tasks.

Steps:

Create Target Group (Console → EC2 → Target Groups)

Type: ip (for Fargate) or instance (for EC2).

Protocol: HTTP, Port: 80 (or your app port).

Health check path: / or /health (whatever your app exposes).

_Create ALB _(Console → EC2 → Load Balancers)

Scheme: internet-facing (for public app) or internal.

Select public subnets across AZs for high availability.

Security group allowing inbound HTTP/HTTPS.

Register Targets

When you configure ECS Service, you can choose the ALB & target group so ECS automatically registers tasks as targets.

Health check: configure a path and thresholds (healthy threshold, unhealthy threshold, timeout, interval). For example: path /health with status 200.

10. Hook ALB to ECS Service

During service creation:

Choose Load balancing: Application Load Balancer.

Attach previously created ALB and target group.

ECS will create an ENI for each task (Fargate) and register it to the target group.

Result: Requests to ALB are forwarded to running containers.

10. Configure Autoscaling (optional but recommended)

Autoscaling adjusts the number of tasks automatically.

Steps:

In your ECS Service → Auto Scaling → Create scale policy.

Define Minimum and Maximum tasks (e.g., min 2, max 10).

Set scaling triggers, e.g.:

Target tracking policy: keep CPU utilization at 50%

Or using CloudWatch metrics (Request count per target)

Tip: Start with conservative min=2, max=10 and tune over time

11. Verify Deployment

Go to ALB → Listeners → copy the DNS name and open in a browser.

Check Task status in ECS cluster (should be RUNNING).

Check Target Group health — targets should show healthy.

Troubleshooting:

If targets are unhealthy, check container health endpoint and security groups.

Ensure container port mapping matches target group settings.

Check CloudWatch logs for container startup errors.

12. Rolling updates and new image versions

Workflow to update:

Build a new image version and tag it (e.g., :v2).

Push to ECR.

Update Task Definition to point to the new image (new revision).

Update ECS Service to use the new task definition → ECS performs a rolling deployment.

Automation tip: Use CI/CD (GitHub Actions / Jenkins / CodePipeline) to:

Build image → push to ECR.

Trigger ECS service update for zero-downtime deployments.

✅ Summary (mapping to your original notes)

aws configure ✔️

Create ECR repo ✔️

Build and push Docker image ✔️

Create cluster (ECS) & task definition ✔️

Create service with task & Fargate/EC2 ✔️

Add ALB → configure target group + health checks ✔️

Add autoscaling (min 2, max 10) ✔️

Service created → check ALB DNS for app ✔️

Deep Dive into ECS Task Definitions: The Blueprint of Your Containers

On-cloud7 — Thu, 25 Sep 2025 13:35:31 +0000

A task definition is a blueprint for your application. It is a text file in JSON format that describes the parameters and one or more containers that form your application.

>> The following are some of the parameters that you can specify in a task definition:

The launch type to use, which determines the infrastructure that your tasks are hosted on

The Docker image to use with each container in your task

How much CPU and memory to use with each task or each container within a task

The memory and CPU requirements

The operating system of the container that the task runs on

The Docker networking mode to use for the containers in your task

The logging configuration to use for your tasks

Whether the task continues to run if the container finishes or fails

The command that the container runs when it's started

Any data volumes that are used with the containers in the task

The IAM role that your tasks use

What is a Task Definition?
A task definition is a JSON file (or equivalent when using AWS Console, SDK, or CDK) that describes one or more containers needed to run your application.

You can think of it as:

A recipe that ECS uses to launch tasks.

It defines the container configuration (image, resources, ports, etc.).

It can include multiple containers if your app needs them (e.g., web + sidecar).

Key Parameters in ECS Task Definitions:
Let’s break down the important fields you’ll encounter:

1. Container Definitions:

The heart of a task definition is the containerDefinitions section. Each container definition includes settings for a single container.

Key parameters include:

image → The Docker image to run (e.g., nginx:latest or 123456789.dkr.ecr.us-east-1.amazonaws.com/my-app:1.0).

name → Logical name for the container inside ECS.

essential → Boolean that tells ECS if this container must run for the task to be healthy.

2. CPU and Memory:

You can define CPU and memory at both task level and container level.

Task-level (cpu, memory): Defines the total resources for the entire task.

Container-level (cpu, memoryReservation, memory): Defines how much of those resources each container gets.

"cpu"
:

256
,

"memory"
:

512

3. Environment Variables
Used to configure applications without hardcoding values.

"environment": [
  { "name": "ENV", "value": "production" },
  { "name": "DEBUG", "value": "false" }
]

4. Port Mappings

Defines how container ports are exposed.

"portMappings": [
  { "containerPort": 80, "hostPort": 80, "protocol": "tcp" }
]

containerPort: Inside container.

hostPort: Exposed on host (for Fargate, usually matches containerPort).

5. Volumes and Mount Points

If your app needs persistent storage or shared data between containers.

Volumes are defined at the task level.

Mount points connect those volumes to a container.

"mountPoints": [
  {
    "sourceVolume": "app-storage",
    "containerPath": "/data"
  }
]

6. Logging

ECS integrates seamlessly with Amazon CloudWatch Logs.

"logConfiguration": {
  "logDriver": "awslogs",
  "options": {
    "awslogs-group": "/ecs/my-app",
    "awslogs-region": "us-east-1",
    "awslogs-stream-prefix": "ecs"
  }
}

7. Command and EntryPoint

Overrides the default behavior of the Docker image.

entryPoint → Overrides the ENTRYPOINT in Dockerfile.

command → Overrides the CMD in Dockerfile.

"command": ["node", "server.js"]

8. Networking Mode

Specifies how containers in a task communicate.

bridge → Default for EC2 (Docker bridge network).

awsvpc → Each task gets its own ENI (used in Fargate).

host → Containers share host networking.

9. IAM Roles

You can assign task roles to containers for AWS permissions.

"taskRoleArn": "arn:aws:iam::123456789:role/ecsTaskExecutionRole"

Putting It All Together: Example Task Definition

Here’s a simplified JSON snippet:

{
  "family": "my-app",
  "cpu": "256",
  "memory": "512",
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "nginx:latest",
      "cpu": 256,
      "memory": 512,
      "essential": true,
      "portMappings": [
        { "containerPort": 80, "hostPort": 80 }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

Best Practices for Task Definitions

✅ Use task roles for AWS service access (never hardcode credentials).

✅ Keep container images small for faster startup.

✅ Define resource limits to avoid noisy-neighbor issues.

✅ Centralize logs with CloudWatch.

✅ Use secrets managers for sensitive data.

How To SSH Into An ECS Fargate Container

On-cloud7 — Mon, 04 Aug 2025 17:27:29 +0000

1) To install the Session Manager plugin using the EXE installer
Download the installer using the following URL.
https://s3.amazonaws.com/session-mana...

   command :  session-manager-plugin --version

2) Install or update the AWS CLI
Download and run the AWS CLI MSI installer for Windows (64-bit):
https://awscli.amazonaws.com/AWSCLIV2...

 command : aws --version

3) Add SSM permissions to the ecsTaskExecutionRole role
You should add the following policy to your existing ecsTaskExecutionRole IAM role. This grants permission for the ECS task to connect with the SSM Session Manager service.

{
   "Version": "2012-10-17",
   "Statement": [
       {
       "Effect": "Allow",
       "Action": [
            "ssmmessages:CreateControlChannel",
            "ssmmessages:CreateDataChannel",
            "ssmmessages:OpenControlChannel",
            "ssmmessages:OpenDataChannel"
       ],
      "Resource": "*"
      }
   ]
}

**4) Add ECS ExecuteCommand permission to your IAM USER

Make sure your IAM USER contains a policy that allows the action ecs:ExecuteCommand. Otherwise, you’re not able to run the aws ecs execute-command in the AWS CLI to access the running container.**

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "User access to ECS ExecuteCommand",
            "Effect": "Allow",
            "Action": "ecs:ExecuteCommand",
            "Resource": "*"
        }
    ]
}

**5) Enable ECS Exec for your ECS task and services

To enable ECS Exec on an existing ECS service run:**

aws ecs update-service  --cluster cluster-name   --task-definition  task-definition-name    --service  service-name    --enable-execute-command --desired-count 1

To verify if a task has ExecuteCommand enabled you can run the aws ecs describe-tasks command to check its configuration.


aws ecs describe-tasks --cluster cluster-name  -–tasks taskid

Example : aws ecs describe-tasks --cluster example-cluster  -–tasks 5210107e30a9470b9b093d1fb72e8d6a

If everything went well, you’ll receive the following output with enableExecuteCommand set to true.

6) Run the aws ecs execute command with the task id and container name to log in.

aws ecs execute-command --cluster cluster-name  --task task-id  --container                    container-name  --interactive     --command "/bin/bash"