Amazon ECS: Launch Type, Role, Load Balancing আর Storage

এই লেসন শেষে তুমি পারবে

• Amazon ECS কী কাজ করে বুঝিয়ে বলতে, আর এর মূল অংশগুলোর নাম বলতে: cluster, task definition, task, service আর ECS agent।
• একটা service কীভাবে task definition থেকে চালু task পর্যন্ত যায়, তা ধাপে ধাপে দেখাতে, আর container crash করলে, instance মরে গেলে বা নতুন version deploy করলে সে কী করবে, আগেই বলে দিতে (rolling, blue/green, circuit breaker)।
• EC2 আর Fargate launch type-এর মধ্যে বেছে নিতে: কোনটা কে সামলায়, কোনটার bill কীভাবে হয় (Fargate-এ প্রতি সেকেন্ডে, কমপক্ষে ১ মিনিট, তুমি যতটা vCPU আর memory ঠিক করে দাও তার ওপর), আর পরীক্ষার কোন keyword কোনটার দিকে ইশারা করে; সাথে Fargate Spot, capacity provider, ECS Managed Instances আর ECS Anywhere কোথায় বসে, সেটাও।
• তিনটা IAM role আলাদা করে চিনতে (instance role, task execution role, task role), প্রতিটা container-কে least privilege দিতে, আর Secrets Manager বা Parameter Store থেকে secret ঢোকাতে।
• Network mode বাছতে (bridge, host, awsvpc), dynamic host port বা IP target দিয়ে service-কে ALB-র সাথে জুড়তে, আর ঠিক security group rule লিখতে।
• Task-কে ঠিক storage দিতে: ephemeral (Fargate-এ ২০ থেকে ২০০ GiB), ভাগ করা স্থায়ী data-র জন্য EFS, প্রতি task-এ একটা EBS volume, FSx for Windows File Server, bind mount, আর নতুন S3 Files; আর awslogs বা FireLens দিয়ে container-এর log পাঠাতে।

#ECS কী কাজ করে

Lesson 14.1 শেষ হয়েছিল একটা সমস্যা দিয়ে: একটা EC2 instance-এ Docker চালানো সহজ, কিন্তু অনেকগুলো instance-এ একশোটা container হলে কাউকে না কাউকে ঠিক করতে হয় কোন container কোথায় চলবে, যেগুলো crash করে সেগুলো আবার চালু করতে হয়, মরে যাওয়া server-এর container অন্য জায়গায় বসাতে হয়, আর downtime ছাড়া নতুন version চালু করতে হয়। Server-এ login করে করে এটা করা অসম্ভব। এই কাজটার নামই container orchestration।

Amazon Elastic Container Service (ECS) হলো AWS-এর নিজের orchestrator। কোন container কোথায় চলবে, কখন চালু হবে আর কখন থামবে, সেটা সে ঠিক করে, আর তুমি যতগুলো চেয়েছ ততগুলো সবসময় চালু রাখে। ECS নিজে বিনা পয়সায়: টাকা দিতে হয় শুধু নিচের compute-এর (EC2 instance বা Fargate) আর বাকি resource-এর (load balancer, volume, log)। এর open-source জুটি, মানে managed Kubernetes, হলো EKS (lesson 14.4)।

#মূল অংশগুলো

Notes বলে cluster মানে “তোমার সব container আর যে server-এ সেগুলো চলে, সব মিলিয়ে”। EC2 launch type-এর বেলায় কথাটা ঠিক, কিন্তু আসলে cluster একটা logical সীমানা: Fargate হলে তার ভেতরে তোমার কোনো server-ই থাকে না, আর একটা cluster-এ Fargate task আর EC2 instance মিশিয়েও রাখা যায়।

#Task definition

ঢাকার shop-এর checkout API-র একটা task definition, ছোট করে:

{
  "family": "checkout",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::111122223333:role/checkout-task-role",
  "containerDefinitions": [{
    "name": "checkout",
    "image": "111122223333.dkr.ecr.ap-southeast-1.amazonaws.com/checkout-example:1.4.2",
    "essential": true,
    "portMappings": [{ "containerPort": 8080 }],
    "secrets": [{ "name": "DB_PASSWORD",
                  "valueFrom": "arn:aws:secretsmanager:ap-southeast-1:111122223333:secret:checkout/db-AbCdEf" }],
    "logConfiguration": { "logDriver": "awslogs",
      "options": { "awslogs-group": "/ecs/checkout", "awslogs-region": "ap-southeast-1",
                   "awslogs-stream-prefix": "checkout" } }
  }]
}

CPU লেখা হয় CPU unit-এ (১,০২৪ unit = ১ vCPU), memory MiB-তে। Fargate-এ task-এর CPU আর memory দেওয়া বাধ্যতামূলক, আর জোড়াটা বৈধ হতে হবে: সবচেয়ে ছোট ০.২৫ vCPU-র সাথে ০.৫ থেকে ২ GB, সবচেয়ে বড় ১৬ vCPU-র সাথে ১২০ GB পর্যন্ত। এই file-এর প্রতিটা অংশ লেসনে পরে আবার আসবে: দুটো role, secret, network mode, log driver।

#Task আর service

একটা task দুইভাবে চালু করা যায়:

• Standalone task (aws ecs run-task): একবার চলে, বিকল হলে কেউ বদলায় না। Batch job, migration আর এককালীন script-এর জন্য; schedule বা event দিয়ে চালু হওয়া task আছে lesson 14.3-এ।
• Service (aws ecs create-service): desired count চিরকাল চালু রাখে। যা অনেকক্ষণ চলবে তার জন্য: web API, worker। সাধারণ replica service ছাড়াও service হতে পারে daemon ধরনের (প্রতিটা EC2 instance-এ একটা করে task, log collector-এর মতো agent-এর জন্য)।

Service scheduler প্রতিটা task-এর জন্য এমন instance বাছে, যেখানে যথেষ্ট CPU, memory আর port খালি আছে। EC2-তে তুমি এই বাছাইটা ঘোরাতে পারো placement strategy দিয়ে (AZ বা instance জুড়ে spread, টাকা বাঁচাতে instance ভরে ভরে binpack, বা random) আর constraint দিয়ে (distinctInstance, বা কোনো expression-এর memberOf, যেমন একটা নির্দিষ্ট instance type)। Fargate নিজে থেকেই তোমার subnet-গুলোর AZ জুড়ে task ছড়িয়ে দেয়।

#ECS agent

EC2 launch type-এ cluster-এর অংশ হতে হলে প্রতিটা instance-এ ECS container agent চলতেই হবে। ECS-optimized AMI-গুলোতে (Amazon Linux 2023, Amazon Linux 2, Bottlerocket, Windows Server) Docker আর agent আগে থেকেই দেওয়া; কোন cluster-এ যোগ দেবে, সেটা user data agent-কে বলে দেয়:

#!/bin/bash
echo "ECS_CLUSTER=checkout-example" >> /etc/ecs/ecs.config

Agent instance role (নিচে আছে) দিয়ে instance-কে register করে, কতটা CPU, memory আর port খালি আছে জানায়, ECS-এর নির্দেশে container চালু ও বন্ধ করে, আর সেগুলোর অবস্থা জানায়। এটা open source, আর EC2-তে এটাকে হালনাগাদ রাখা তোমার দায়িত্ব (নতুন ECS-optimized AMI, অথবা aws ecs update-container-agent)। Agent-এর সংযোগ ছুটে গেলে instance cluster-এ থেকেই যায়, কিন্তু নতুন কোনো task পায় না।

#Deployment: rolling, blue/green আর circuit breaker

Service-কে নতুন একটা task definition revision-এ update করলে ECS deployment strategy মেনে task-গুলো বদলায়।

Rolling update (default)। দুটো সংখ্যা এটা নিয়ন্ত্রণ করে, দুটোই desired count-এর শতকরা হিসেবে: minimum healthy percent (default ১০০%) আর maximum percent (default ২০০%)। Desired ৪টা task আর default setting হলে deployment-এর সময় ECS ৮টা পর্যন্ত task চালাতে পারে, কিন্তু সুস্থ task কখনো ৪টার কম হবে না: সে নতুন task চালু করে, load balancer-এর health check পাস করা পর্যন্ত অপেক্ষা করে, তারপর পুরোনোগুলোকে ধীরে সরিয়ে থামায়। Cluster-এ বাড়তি কপির জায়গা না থাকলে maximum বা minimum কমাও (minimum ৫০% মানে একবারে অর্ধেক বদলানো, কম capacity নিয়ে)।

Blue/green। চলতি task-এর সেটের (blue) পাশে পুরো আরেকটা সেট (green) চালু হয়; green সুস্থ হলে traffic তার দিকে যায়, আর চট করে ফিরে আসার জন্য blue কিছুক্ষণ থেকে যায়। আগে এর জন্য AWS CodeDeploy লাগত। ২০২৫-এর জুলাই থেকে ECS-এর নিজেরই blue/green strategy আছে, traffic সরানোর আগে test চালানোর lifecycle hook আর blue সরানোর আগে একটা bake time সহ, ALB, NLB বা Service Connect-এর পেছনের service-এর জন্য; ২০২৫-এর অক্টোবরে এল canary আর linear ভাবে traffic সরানো। আগে লেখা পরীক্ষার প্রশ্ন ECS-এ blue/green-এর জন্য “CodeDeploy” আশা করে; আজকের দিনে দুটোই ঠিক।

Deployment circuit breaker। এটা না থাকলে যে version কখনো সুস্থ হয় না, তাকে নিয়ে ECS অনেকক্ষণ ধরে চেষ্টা চালিয়ে যেতে পারে। Circuit breaker (rollback সহ) চালু থাকলে ECS ব্যর্থ launch গোনে, deployment-কে failed ঘোষণা করে, আর নিজে থেকেই শেষ ভালো revision-এ ফিরে যায়। CloudWatch alarm দিয়েও একই rollback চালানো যায়।

#Launch type: EC2 নাকি Fargate

একটা task-এর কোথাও না কোথাও CPU আর memory লাগে। ECS দুটো জায়গা দেয়, এদের বলে launch type, আর notes কথা দিয়েছে এখান থেকে পরীক্ষায় প্রশ্ন আসবেই।

Notes বলে Fargate-এ “container যতটুকু resource ব্যবহার করে, ঠিক ততটুকুর” bill হয়। পুরোপুরি না: Fargate bill করে task তার definition-এ যতটা চেয়েছে তার ওপর। ২ vCPU ঠিক করা একটা task ৫% CPU-তে বসে থাকলেও bill হয় ২ vCPU-র। Fargate-এ টাকা বাঁচানোর উপায় তাই task definition-এর মাপ ঠিক করা।

Notes আরও বলে “reserved EC2 instance দিয়ে খরচ কমাতে চাই” মানে EC2 launch type। Reserved Instances-এর বেলায় কথাটা ঠিক: এগুলো শুধু EC2-তে খাটে। কিন্তু Compute Savings Plans (lesson 4.4) Fargate-ও ঢাকে (Lambda-ও), তাই “তিন বছরের commitment দিয়ে Fargate-এর খরচ কমাও”-এরও উত্তর আছে।

#কোনটায় খরচ কম?

প্রতি vCPU-ঘণ্টায় Fargate-এর list price পুরোপুরি ব্যবহার হওয়া একটা EC2 instance-এর চেয়ে একটু বেশি। কিন্তু EC2 instance প্রায় কখনোই পুরোপুরি ব্যবহার হয় না: task-গুলো নিখুঁতভাবে আঁটে না (CPU-র আগে memory ফুরায়, বা উল্টোটা), task কমে গেলেও instance চালু থাকে, আর deployment-এর জন্য বাড়তি জায়গা রাখতে হয়। Shop-এর checkout service দিয়ে নিজেই চেষ্টা করে দেখো:

Default setting-এ (০.৫ vCPU আর ১ GB-র ১০টা task, সারাদিন, m6i.large) ৩০ দিনে Fargate-এর খরচ প্রায় ১৭৮ USD আর তিনটা instance-এর প্রায় ২০৭ USD, কারণ প্রতি instance-এ চারটা task আঁটে আর তৃতীয় instance-টা অর্ধেক খালি পড়ে থাকে। ২০টা task হলে instance-গুলো ভরে যায়, তখন EC2 জেতে (৩৪৬ বনাম ৩৫৫ USD)। এর সাথে instance patch আর scale করতে তোমার যে ঘণ্টাগুলো যায়, সেগুলো যোগ করো, তাহলেই চেনা পরামর্শটা আসে: শুরু করো Fargate দিয়ে; স্থির, বড়, ভালোভাবে ঠাসা workload-কে Savings Plans বা Reserved Instances সহ EC2-তে নাও, যখন হিসাব সেটা বলে।

মনে রাখার মতো একটা হিসাব: N. Virginia-তে ১ vCPU আর ২ GB-র একটা task পুরো মাস চলল (৩০ দিন = ৭২০ ঘণ্টা): (১ × ০.০৪০৪৮ + ২ × ০.০০৪৪৪৫) × ৭২০ = ০.০৪৯৩৭ × ৭২০ ≈ ৩৫.৫৫ USD। এমন দশটা task দিনে ৮ ঘণ্টা চললে: ০.০৪৯৩৭ × ১০ × ২৪০ ≈ ১১৮.৪৯ USD।

#Fargate Spot আর capacity provider

Fargate Spot AWS-এর বাড়তি capacity-তে Fargate task চালায়, ৭০% পর্যন্ত কম দামে। AWS দুই মিনিটের নোটিশ দিয়ে capacity ফেরত নিতে পারে (task পায় SIGTERM, তারপর থামিয়ে দেওয়া হয়)। যে কাজ মাঝপথে থামলেও চলে, তার জন্য মানানসই: queue worker, batch job, test environment। এটা শুধু Linux task চালায়।

তাহলে আজকাল FARGATE, FARGATE_SPOT আর নিজের instance-এর মধ্যে বাছাই হয় কীভাবে? Capacity provider দিয়ে। Launch type-এর নাম না বলে service একটা capacity provider strategy নেয়, যেমন “FARGATE-এ সবসময় ২টা task (base), আর বাকিগুলো FARGATE আর FARGATE_SPOT-এর মধ্যে ১:৩ ভাগে”। EC2-তে managed scaling-ওয়ালা একটা Auto Scaling group capacity provider task জায়গার অপেক্ষায় থাকলে instance যোগ করে। একটা service হয় launch type নেয়, নয়তো capacity provider strategy, দুটো একসাথে না। Scaling-এর দিকটা (base আর weight, managed scaling, Spot-এর interruption) আছে lesson 14.3-এ।

#ECS-এর IAM role: দুটো না, তিনটা

Notes বলে ECS-এ দুটো role থাকে, EC2 instance role আর task role। আসলে আছে তিনটা, আর তৃতীয়টা, মানে task execution role, সেটাই Fargate-কে চালু করায়।

Execution role আর task role দুটোই service principal ecs-tasks.amazonaws.com-কে বিশ্বাস করে। Application task role-এর অস্থায়ী credential পায় task-এর ভেতরের একটা credentials endpoint থেকে (169.254.170.2, যেটা খুঁজে পাওয়া যায় AWS_CONTAINER_CREDENTIALS_RELATIVE_URI variable দিয়ে); AWS SDK নিজে থেকেই এগুলো তুলে নেয়। Execution role-এর credential তোমার code কখনো দেখতে পায় না।

Slide ECR থেকে image টানা, CloudWatch log আর secret, সবই রেখেছে instance profile-এর ঘরে। EC2 launch type-এ সেটা এখনো চলে, কারণ agent দরকার হলে instance role-এ ফিরে যেতে পারে। কিন্তু তখন instance-এর সব task একই permission ভাগ করে, আর Fargate-এ তো instance profile বলে কিছুই নেই। এগুলো রাখো execution role-এ।

Notes-এর exam trick-টা হুবহু ঠিক থাকে: “container-এর ভেতরের application-কে একটা S3 bucket access করতে হবে” → ECS task role। এর জন্য EC2 instance role-এ কখনো S3-এর permission দিও না: তাহলে instance-এর প্রতিটা container সেটা পেয়ে যাবে। যে container-এর task role নেই, তার SDK task-এর credential খুঁজে না পেয়ে instance metadata service-এ চলে যায় আর instance role তুলে নেয়। এই কারণেই EC2-তে container-গুলোর instance metadata-য় যাওয়ার পথও আটকাও (awsvpc task-এর জন্য ECS_AWSVPC_BLOCK_IMDS=true; bridge mode-এ একটা iptables rule, বা hop limit ১ রেখে IMDSv2)।

Console-এ আরও দুটো role চোখে পড়বে: service-linked role AWSServiceRoleForECS, যেটা ECS নিজেই বানায় ENI সামলাতে আর load balancer-এ target register করতে, আর ECS infrastructure role, যেটা তুমি বানাও যখন ECS-কে তোমার হয়ে কোনো resource সামলাতে হয়, যেমন task-এর EBS volume বা ECS Managed Instances। তোমার code এর কোনোটাই ব্যবহার করে না।

#Task definition-এ secret

Password কখনো image-এর ভেতরে বা task definition-এর সাদা environment variable-এ রেখো না (task definition যে পড়তে পারে, সে-ই দেখে ফেলবে)। বরং reference দাও:

• secrets-এ valueFrom = একটা Secrets Manager secret-এর ARN (চাইলে তার JSON-এর একটা key) অথবা একটা SSM Parameter Store parameter (secret-এর জন্য SecureString)।
• Task execution role-এর লাগবে ঠিক ওই ARN-গুলোর ওপর secretsmanager:GetSecretValue বা ssm:GetParameters (আর customer managed KMS key দিয়ে encrypt করা থাকলে kms:Decrypt)।
• Task চালু হওয়ার সময় ECS মানটা নিয়ে আসে আর environment variable হিসেবে বসিয়ে দেয় (registry-র credential হলে সেটা দিয়ে private registry-তে login করে)। Secret rotate হলে নতুন মান container-এ পৌঁছায় কেবল task আবার চালু হলে, যেমন নতুন একটা deployment জোর করে চালালে।

Secrets Manager আর Parameter Store বিস্তারিত আছে lesson 21.3-এ।

#Networking আর load balancing

#Network mode

Container-গুলো network-এ কীভাবে আসবে, সেটা ঠিক করে task definition-এর networkMode।

#Dynamic host port mapping আর ALB

Notes-এর পরিচিত ঘটনা: bridge mode-এ একটা EC2 instance-এ একই container-এর কয়েকটা কপি। Task definition যদি host port বেঁধে দিত (ধরো 80), তাহলে দ্বিতীয় কপি ওই instance-এ চালুই হতে পারত না: port দখলে, আর scheduler port-কেও CPU আর memory-র মতো একটা resource ধরে, তাই task pending-এ অপেক্ষা করে। hostPort ফাঁকা (বা 0) রাখলে Docker প্রতিটা কপিকে ephemeral range থেকে একটা খালি port দেয়। ECS প্রতিটা task-কে ALB target group-এ register করে instance ID + port হিসেবে, আর ALB সবগুলোর মধ্যে traffic ভাগ করে দেয়, একই instance-এ কয়েকটা থাকলেও। এটাই dynamic host port mapping, আর এই কারণেই ALB হলো ECS-এর চিরচেনা সঙ্গী।

Notes দুটো খুঁটিনাটি বাদ দিয়েছে:

• কোন port? Range-টা আসে kernel থেকে (/proc/sys/net/ipv4/ip_local_port_range), Amazon Linux-এ যেটা 32768–60999; এটা না পেলে Docker নেয় 49153–65535। Notes-এর উদাহরণ “32768” হলো এর প্রথম port।
• Security group। Instance-গুলোর security group-কে ওই port-গুলো ALB-র security group থেকে আসতে দিতে হবে। চেনা rule-টা হলো TCP 32768–65535, source হিসেবে ALB-র security group। এটা ভুলে গেলে health check ফেল করে: container ঠিকঠাক থাকলেও প্রতিটা target unhealthy।

Classic Load Balancer dynamic host port সমর্থন করে না (প্রতিটা instance-এ একটা নির্দিষ্ট port লাগে) আর Fargate task-কে target করতে পারে না; slide বলে এটা supported কিন্তু পরামর্শযোগ্য না, আর আজকের দিনে এটা legacy।

#awsvpc: প্রতি task-এ একটা ENI

Notes বলে Fargate task নিজের private IP পায়, তাই ALB traffic পাঠায় “port না, সরাসরি IP ধরে”। প্রথম অংশ ঠিক; দ্বিতীয়টা একটু ঢিলেঢালা। awsvpc-তে প্রতিটা task-এর নিজের ENI আর IP, তাই ভাগ করার মতো কোনো host port নেই: container নিজেই 8080-এ শোনে, আর ALB target করে IP address আর port (10.0.1.23:8080)। Target group-এর হতে হবে target type ip, instance না (lesson 6.3)। লাভটা হলো:

• প্রতিটা task VPC-র পুরো সদস্য: নিজের security group (প্রতি task-এ “ALB-র security group থেকে 8080”), VPC Flow Logs-এ নিজের আলাদা লাইন।
• Port-এর সংঘর্ষ নেই, instance-এ ephemeral range খোলার ঝামেলাও নেই।

awsvpc EC2 launch type-এও চলে, তবে একটা প্যাঁচ আছে: প্রতিটা task একটা ENI খরচ করে, আর একটা instance-এ ENI থাকে হাতে গোনা। একটা m6i.large-এ ৩টা ENI লাগানো যায়, তার একটা instance-এর নিজের, তাই CPU যতই খালি থাকুক, awsvpc task আঁটে ২টা। Account setting awsvpcTrunking চালু করলে নতুন instance-গুলো একটা trunk ENI পায়, যার ওপর অনেকগুলো branch ENI চলে: তখন একই m6i.large ১০টা পর্যন্ত task নেয়।

#কোন load balancer?

• Application Load Balancer: HTTP/HTTPS-এর জন্য স্বাভাবিক পছন্দ। Path আর host দেখে routing করে বলে কয়েকটা service একটা ALB ভাগ করে নিতে পারে (/checkout → checkout service, /search → search service)। একটা service কয়েকটা target group-এ register হতে পারে।
• Network Load Balancer: TCP, UDP বা TLS, বিপুল throughput আর কম latency, স্থির IP address, আর AWS PrivateLink দিয়ে অন্য VPC বা account-কে service খুলে দেওয়া।
• Gateway Load Balancer: virtual appliance-এর বহরের জন্য (firewall, inspection), app-এর সামনে কালেভদ্রে।
• Classic Load Balancer: legacy; dynamic port নেই, Fargate নেই।

Cluster-এর ভেতরে service-রা ECS Service Connect (বা Cloud Map service discovery) দিয়ে নাম ধরে একে অপরকে call করতে পারে, ভেতরের কোনো load balancer ছাড়াই।

#Storage: data volume

Container-এর লেখার স্তরটা container-এর সাথেই মুছে যায়, আর ECS-এ task সারাক্ষণ বদলায়: প্রতিটা deployment, প্রতিটা crash, প্রতিটা scale-in, Fargate-এর প্রতিটা retirement-এ। Task পেরিয়েও যা টিকে থাকতে হবে, তার জন্য task-এর বাইরে একটা volume লাগে।

যে খুঁটিনাটিগুলো কাজে লাগে:

• EFS (lesson 5.4) একটা regional NFS file system, প্রতিটা AZ-এ তার mount target। যেকোনো AZ-এর task, EC2-তে হোক বা Fargate-এ, একই file system mount করে (efsVolumeConfiguration), চাইলে একটা access point দিয়ে, IAM authorization আর পথে encryption সহ। Fargate + EFS = serverless ভাগাভাগির storage। “Container-এর জন্য স্থায়ী, multi-AZ, ভাগ করা storage”-এর পরীক্ষার উত্তর এটাই।
• Task-এর EBS volume। Notes বলে Fargate-এ EBS চলে না। কথাটা সত্যি ছিল ২০২৪-এর জানুয়ারি পর্যন্ত: এখন ECS প্রতি task-এ একটা নতুন EBS volume বানিয়ে লাগিয়ে দিতে পারে, Fargate-এ আর EC2-তে দুই জায়গাতেই। Task definition volume-টাকে configuredAtLaunch চিহ্ন দেয়; service বা run-task call বলে দেয় size, type (gp3, io2…), IOPS, আর চাইলে কোন snapshot থেকে শুরু। আগে থেকে থাকা কোনো volume লাগানো যায় না, volume থাকে task-এর AZ-এ (lesson 5.1), আর service task-এর volume task থামলে delete হয়ে যায়। এর জন্য ECS infrastructure role লাগে। প্রতি task-এর জন্য বড়, দ্রুত একটা কাজের disk হিসেবে ভালো (transcoding, ETL, cache); ভাগ করার জন্য না।
• Fargate-এর ephemeral storage (platform 1.4.0+) default-এ ২০ GiB, বাড়িয়ে ২০০ GiB করা যায়; image নিজেই এর একটা অংশ খায়, আর ২০ GiB-র ওপরের অংশের দাম দিতে হয়। এটা encrypted থাকে (AES-256, AWS-এর নিজের key বা তোমার KMS key)।
• FSx for Windows File Server (lesson 12.2): ভাগ করা SMB storage, Active Directory-র সাথে জোড়া, EC2-র Windows container-এর জন্য।
• S3 Files হলো slide-এর শেষ পাতা। এটা সত্যিকারের আর নতুন: ২০২৬-এর এপ্রিল থেকে Amazon S3 Files একটা general purpose bucket-কে NFS file system হিসেবে খুলে দেয় (EFS-এর প্রযুক্তির ওপর বানানো), আর ECS task সেটা mount করতে পারে (s3filesVolumeConfiguration), Fargate আর ECS Managed Instances-এ শুরু থেকেই, আর ২০২৬-এর সেপ্টেম্বর থেকে EC2 launch type-এও। Mount দিয়ে লেখা file bucket-এ sync হয়, আর অন্য system একই data-য় S3 API ব্যবহার করে যেতে পারে। Task role বাধ্যতামূলক, আর পথে encryption সবসময় চালু। Data যখন আগে থেকেই S3-এ আর code চায় file path, তখন এটা নাও। পরীক্ষা এখনো এটা আশা করে না: “Fargate-এর shared persistent storage” এখনো EFS।

#Logging: awslogs আর FireLens

Container-এর উচিত log লেখা stdout আর stderr-এ, container-এর ভেতরের file-এ না (সেগুলো task-এর সাথেই উধাও হয়, আর কেউ সেগুলো বাইরে পাঠায় না)।

• awslogs log driver: প্রতিটা container-এর stdout/stderr একটা CloudWatch Logs log group-এ পাঠায়, প্রতি container-এ একটা log stream (prefix/container/task-id)। Fargate-এ এটা task execution role ব্যবহার করে। এটাই স্বাভাবিক পছন্দ, আর “container-এর log CloudWatch-এ দেখো”-র পরীক্ষার উত্তর (CloudWatch Logs: lesson 19.2)।
• FireLens: task-এর ভেতরে একটা Fluent Bit (বা Fluentd) sidecar container, awsfirelens log driver দিয়ে সাজানো, যে log যেখানে খুশি পাঠায়: Data Firehose (আর তার মাধ্যমে S3), OpenSearch, filter করে CloudWatch, বা বাইরের tool। Log কয়েক জায়গায় পাঠাতে বা বদলে নিতে এটা নাও।
• SSH ছাড়া চলতি container-এর ভেতরে উঁকি দিতে ECS Exec নাও (aws ecs execute-command, Session Manager-এর মাধ্যমে)। প্রতি task আর service-এর metric আসে Container Insights থেকে, যেটা scaling-এর সাথে আছে lesson 14.3-এ।

#কোথায় গোলমাল হয়

#System design-এ ECS

• Web API আর microservice: প্রতিটা microservice-এর জন্য একটা ECS service, প্রত্যেকটার নিজের task definition, task role আর scaling, path-ভিত্তিক routing-ওয়ালা একটা ভাগাভাগির ALB-র পেছনে। Fargate পুরো instance-এর বহরটাই operations-এর তালিকা থেকে সরিয়ে দেয়।
• Worker: load balancer ছাড়া service, যারা SQS থেকে কাজ টানে (lesson 13.1), interruption চললে Fargate Spot-এ; queue দেখে scaling আছে lesson 14.3-এ।
• Batch আর schedule-এর কাজ: EventBridge দিয়ে চালু হওয়া standalone task (lesson 14.3), প্রতি সেকেন্ডে bill।
• Team-দের মধ্যে আলাদা রাখা: আলাদা task role, প্রতি task-এ security group (awsvpc), শক্ত সীমানার জন্য আলাদা cluster বা account; Fargate প্রতিটা task-কে নিজের micro-VM-ও দেয়।
• খরচ: হঠাৎ বাড়া-কমা বা ছোট workload আর দ্রুত চালুর জন্য Fargate; বড়, স্থির, ভালোভাবে ঠাসা বহর বা GPU লাগলে EC2 (Savings Plans বা Reserved Instances সহ, আর capacity provider দিয়ে Spot)।
• Lift and shift: Elastic Beanstalk-এর Docker platform (lesson 9.4) কম নিয়ন্ত্রণ নিয়ে container চালায়; সেটা ছোট হয়ে গেলে পরের ধাপ সরাসরি ECS।

#নিজে করে দেখো

একটা cluster, execution role, একটা task definition আর আগে থেকে থাকা একটা ALB target group-এর পেছনে একটা Fargate service বানাও, তারপর একটা deployment দেখো। Output ছোট করা; ID-গুলো উদাহরণ।

REGION=ap-southeast-1
# 1. একটা খালি cluster (Fargate-এর কোনো instance লাগে না)
aws ecs create-cluster --cluster-name checkout-example --region $REGION
# { "cluster": { "clusterName": "checkout-example", "status": "ACTIVE", ... } }

# 2. Task execution role: ecs-tasks.amazonaws.com-কে বিশ্বাস করে, AWS managed policy
aws iam create-role --role-name ecsTaskExecutionRole \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow",
  "Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name ecsTaskExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

# 3. আগে দেখানো task definition register করো (checkout-taskdef.json নামে রাখা)
aws ecs register-task-definition --cli-input-json file://checkout-taskdef.json
# "taskDefinitionArn": "arn:aws:ecs:ap-southeast-1:111122223333:task-definition/checkout:1"

# 4. একটা service: ২টা task, private subnet, ip type-এর ALB target group, circuit breaker চালু
aws ecs create-service --cluster checkout-example --service-name checkout \
  --task-definition checkout:1 --desired-count 2 --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-0a1b2c3d4e5f60001,subnet-0a1b2c3d4e5f60002],securityGroups=[sg-0123456789abcdef0],assignPublicIp=DISABLED}" \
  --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:ap-southeast-1:111122223333:targetgroup/checkout-tg/0123456789abcdef,containerName=checkout,containerPort=8080" \
  --health-check-grace-period-seconds 60 \
  --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true},minimumHealthyPercent=100,maximumPercent=200"

# 5. Desired বনাম running, আর deployment-এর অবস্থা
aws ecs describe-services --cluster checkout-example --services checkout \
  --query 'services[0].{desired:desiredCount,running:runningCount,rollout:deployments[].rolloutState}'
# { "desired": 2, "running": 2, "rollout": ["COMPLETED"] }

# 6. প্রতিটা task-এর private IP (awsvpc), আর কোনো task কেন থামল
aws ecs list-tasks --cluster checkout-example --service-name checkout
aws ecs describe-tasks --cluster checkout-example --tasks 3f1c9e0a1b2c4d5e8f9a0b1c2d3e4f50 \
  --query 'tasks[0].{status:lastStatus,ip:attachments[0].details[?name==`privateIPv4Address`].value|[0],stopped:stoppedReason}'
# { "status": "RUNNING", "ip": "10.0.1.23", "stopped": null }

# 7. Revision 2 চালু করো (আগে register করে নাও), তারপর log দেখো
aws ecs update-service --cluster checkout-example --service checkout --task-definition checkout:2
aws logs tail /ecs/checkout --follow

# 8. চলতি container-এর ভেতরে একটা shell (service-এ enableExecuteCommand লাগবে)
aws ecs execute-command --cluster checkout-example --task 3f1c9e0a1b2c4d5e8f9a0b1c2d3e4f50 \
  --container checkout --interactive --command "/bin/sh"

# 9. গুছিয়ে ফেলো
aws ecs update-service --cluster checkout-example --service checkout --desired-count 0
aws ecs delete-service --cluster checkout-example --service checkout
aws ecs delete-cluster --cluster checkout-example

হাতে একটা task থামাও (aws ecs stop-task), তারপর আবার ধাপ ৫ চালাও: running নেমে যায় ১-এ, আর এক মিনিটের মধ্যে আবার ২। Service ঠিক তার কাজটাই করছে।

#সারসংক্ষেপ

মূল কথাগুলো

• ECS হলো AWS-এর নিজের container orchestrator, নিজে বিনা পয়সায়। Cluster = task আর capacity-র logical দল; task definition = version-ওয়ালা রেসিপি (image, CPU, memory, port, role, secret, log, volume); task = একটা চালু কপি; service = desired count চালু রাখে, বিকলগুলো বদলায়, load balancer-এ register করে, deploy করে। EC2-তে প্রতিটা instance-এ চলে ECS agent।
• Deployment: rolling (default-এ minimum healthy ১০০%, maximum ২০০%), blue/green (CodeDeploy, আর ২০২৫-এর জুলাই থেকে ECS-এর নিজের ভেতরেই), আর নিজে থেকে rollback-এর জন্য deployment circuit breaker।
• EC2 launch type: instance তোমার, patch আর scaling তোমার, টাকা instance-এর; root access, GPU, Reserved Instances। Fargate: serverless, টাকা প্রতি সেকেন্ডে (কমপক্ষে ১ মিনিট), ঠিক করে দেওয়া vCPU আর memory-র ওপর, শুধু awsvpc। Compute Savings Plans Fargate-ও ঢাকে। Fargate Spot: ৭০% পর্যন্ত ছাড়, দুই মিনিটের নোটিশ। এখনকার বাছাই: capacity provider। পাশের কথা: ECS Managed Instances, ECS Anywhere।
• তিনটা IAM role: instance role (agent cluster-এ যোগ দেয়, শুধু EC2), task execution role (ECR থেকে টানা, log পাঠানো, secret আনা; Fargate-এ বাধ্যতামূলক), task role (app-এর নিজের permission, প্রতি task definition-এ একটা)। App-এর S3 লাগবে → task role, instance role কখনো না।
• Secret: Secrets Manager বা Parameter Store-এর ARN দিয়ে secrets, execution role নিয়ে আসে, task চালুর সময় ঢোকানো হয়।
• Networking: এক instance-এ অনেক কপির জন্য bridge + dynamic host port + ALB (ALB-র security group থেকে 32768–65535 খোলো); awsvpc = প্রতি task-এ একটা ENI আর IP, নিজের security group, target type ip, Fargate-এ বাধ্যতামূলক (EC2-তে ENI trunking); TCP/UDP আর PrivateLink-এর জন্য NLB; CLB legacy।
• Storage: ephemeral (Fargate-এ default ২০ GiB, ২০০ GiB পর্যন্ত) task-এর সাথে মরে; EFS = ভাগাভাগি, স্থায়ী, multi-AZ, EC2 আর Fargate (পরীক্ষার উত্তর); প্রতি task-এ EBS (২০২৪ থেকে) = ব্যক্তিগত, AZ-এ বাঁধা; EC2-তে FSx for Windows; Fargate, Managed Instances আর EC2-তে S3 Files (২০২৬)।
• Log: CloudWatch Logs-এ awslogs; যেখানে খুশি পাঠাতে FireLens।

নিজেকে যাচাই করো: Amazon ECS৩১টি প্রশ্ন