Systems Manager

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

• AWS Systems Manager কীসের জন্য, আর একটা server কখন managed node হয় তা বোঝাতে: SSM Agent, একটা অনুমতি (instance profile বা Default Host Management Configuration, on-premises-এ hybrid activation) আর 443-এ বাইরে যাওয়ার পথ (NAT বা interface VPC endpoint)।
• যে node Connection lost দেখায় বা তালিকাতেই আসে না, তার সমস্যা খুঁজে বের করতে।
• Session Manager-কে গোড়ার বাইরেও কাজে লাগাতে: session logging, KMS, idle timeout, database-এ port forwarding, এর ভেতর দিয়ে SSH, tag ধরে IAM; আর জানতে যে CloudTrail StartSession লেখে, command না।
• Run Command দিয়ে পুরো fleet-এ একটা script চালাতে, আর max concurrency ও max errors এমনভাবে বাছতে যাতে একটা খারাপ script সব ভেঙে না দেয়।
• Patch Manager দিয়ে Windows, Linux আর macOS patch করতে: baseline, auto-approval-এর দেরি, patch group আর patch policy, Scan বনাম Install, compliance।
• Maintenance Windows দিয়ে ঝামেলার কাজের সময় বেঁধে দিতে (schedule, time zone, duration, cutoff, task), আর EventBridge, Config, schedule বা মানুষের হাতে চালু হওয়া Automation runbook দিয়ে operation অটোমেট করতে।
• পরীক্ষার keyword দেখে বাকি tool-গুলোর নাম বলতে: Parameter Store, State Manager, Inventory, Fleet Manager, Distributor, OpsCenter, Explorer, Change Calendar, Quick Setup, আর ২০২৫–২৬-এ Change Manager ও Incident Manager-এর অবস্থা।

#পুরো fleet-এর জন্য একটাই console

ঢাকার একটা ব্যাংকের AWS-এ ৪০টা server চলে, আর শাখাগুলোতে আরও ৩০০টা। প্রতি মাসে কাউকে না কাউকে এগুলো patch করতে হয়, নতুন antivirus agent বসাতে হয়, কোন server-এ কী software আছে দেখতে হয়, আর মাঝেমধ্যে login করে কিছু ঠিক করতে হয়। SSH আর RDP দিয়ে হাতে হাতে এসব করা মানে খোলা port, ভাগাভাগি করা key, একটা bastion host, কে কী patch করল তার একটা spreadsheet, আর reboot গোলমাল হলে রাত ৩টায় ফোন।

AWS Systems Manager (সংক্ষেপে এখনো SSM, পুরোনো নাম Simple Systems Manager থেকে) হলো সেই service, যেটা এই কাজগুলো করে দেয় সেইসব server-এ যেগুলো তুমি হাত দিয়ে ছুঁতে চাও না: EC2 instance, on-premises server, আর অন্য cloud-এর virtual machine। এটা আসলে একটা যন্ত্রের বাক্স, আর পরীক্ষা যন্ত্রগুলোর নাম ধরেই প্রশ্ন করে:

Notes পরীক্ষার জন্য Systems Manager-এর পাঁচটা topic ধরেছে (Session Manager, Run Command, Patch Manager, Maintenance Windows, Automation); Parameter Store শেখানো হয়েছে লেসন ২১.৩-এ। এই লেসন শুরু করবে সেই ভিত দিয়ে যেটা সব tool-এর লাগে, তারপর একটা একটা করে tool ধরবে, শেষে ছোট tool-গুলোর একটা চক্কর।

#ভিত: managed node

#একটা node কখন “managed” হয়

ওপরের প্রতিটা tool কাজ করে শুধু managed node-এ: যে machine-এর সাথে Systems Manager কথা বলতে পারে। তিনটা জিনিস মিলে একটা managed node হয়:

1. SSM Agent তার ভেতরে চলে। Amazon Linux 2023 আর 2, Ubuntu, macOS আর AWS-এর প্রকাশ করা Windows Server AMI-তে এটা আগে থেকেই বসানো। অন্য image-এ তোমাকে বসাতে হয় (AMI বানানোর সময় বা user data দিয়ে)।
2. একটা অনুমতি, যাতে agent Systems Manager-কে call করতে পারে:
   • একটা instance profile (instance-এর IAM role), AWS managed policy AmazonSSMManagedInstanceCore-সহ, অথবা
   • Default Host Management Configuration: account আর Region ধরে একটা setting, যেটা instance profile ছাড়াই প্রতিটা EC2 instance-কে একটা default role (AWSSystemsManagerDefaultEC2InstanceManagementRole) দিয়ে দেয়। এর জন্য IMDSv2 আর SSM Agent 3.2.582.0 বা নতুন লাগে, আর যদি আগেই এমন instance profile লাগানো থাকে যেটা ssm:UpdateInstanceInformation allow করে, agent আগে সেটাই ব্যবহার করে।
3. Systems Manager-এর endpoint পর্যন্ত HTTPS 443-এ বাইরে যাওয়ার পথ। Agent সবসময় connection বাইরের দিকে খোলে; ভেতরে কেউ কখনো ঢোকে না। Public subnet যায় internet gateway দিয়ে, private subnet যায় NAT gateway দিয়ে, অথবা ssm আর ssmmessages-এর interface VPC endpoint দিয়ে (লেসন ২২.২), পুরোনো agent-এর জন্য সাথে ec2messages।

Register হওয়ার পর agent প্রতি ৫ মিনিটে একটা heartbeat পাঠায়। Fleet Manager node-কে দেখায় Online; heartbeat থেমে গেলে হয় Connection lost; আর যে node কখনো register-ই হয়নি, সে তালিকাতেই নেই।

Endpoint-ওয়ালা private subnet-এ তিনটা খুঁটিনাটি ঠিক করে দেয় কাজ চলবে কিনা:

• Endpoint-এর নিজের security group-কে instance-গুলো থেকে (তাদের security group বা VPC CIDR) inbound TCP 443 allow করতে হবে। পুরো design-এ inbound rule এই একটাই, আর এর জায়গা endpoint-এ, instance-এ না।
• Endpoint-এ private DNS চালু থাকতে হবে (VPC-তে DNS hostnames আর DNS resolution-সহ), যাতে agent-এর চেনা service-এর নামগুলো endpoint-এ resolve হয়।
• অন্য feature-এর আলাদা endpoint লাগে: patch নামানো, agent update আর S3-এ log-এর জন্য S3 (gateway endpoint); CloudWatch Logs-এর জন্য logs; session KMS key দিয়ে encrypt করলে kms।

#On-premises server আর অন্য cloud: hybrid activation

শাখার server-এর কোনো instance profile নেই, metadata service-ও নেই। সে যোগ দেয় একটা hybrid activation দিয়ে:

1. একজন admin একটা activation বানান: একটা activation code আর activation ID, কয়টা server register হতে পারবে তার সীমা, মেয়াদের তারিখ, আর একটা IAM service role যেটা server-গুলো ব্যবহার করবে।
2. প্রতিটা server-এ admin SSM Agent বসিয়ে code আর ID দিয়ে register করেন।
3. Server দেখা দেয় mi- (managed instance) দিয়ে শুরু হওয়া ID নিয়ে, i- না। বাকি সব EC2-এর মতোই চলে: session, Run Command, patch, inventory। তবে 443-এ বাইরে যাওয়ার পথ এখনো লাগে: internet, VPN বা Direct Connect দিয়ে।

এবার নিজে চেষ্টা করো: node-টা যেমন পেয়েছ তেমন সাজাও, আর দেখো Systems Manager কোন status দেখাত, কেন।

#Document: রান্নার রেসিপি

প্রতিটা কাজের বর্ণনা থাকে একটা SSM document-এ, parameter আর step-সহ একটা JSON বা YAML file। এখানে যেগুলো দরকার:

AWS-এর নিজের শত শত document আছে (নাম শুরু হয় AWS- বা AWSSupport- দিয়ে)। তুমি নিজেরটাও লিখতে পারো, version রাখতে পারো, অন্য account-এর সাথে ভাগ করতে পারো। Document বলে কী করতে হবে; কোথায় আর কখন, সেটা ঠিক করে tool।

#Target: তালিকা না, tag

Tool-গুলো node বাছে instance ID দিয়ে (অল্প কয়েকটার জন্য ঠিক আছে, এক Run Command call-এ ৫০টা পর্যন্ত), tag দিয়ে (Env=prod, Patch Group=branches), একটা resource group দিয়ে, অথবা সব managed node। স্বাভাবিক উত্তর tag: Env=prod tag-ওয়ালা নতুন server পরের বার নিজে থেকেই ঢুকে যায়, কাউকে তালিকা বদলাতে হয় না।

#Session Manager, আরও গভীরে

লেসন ৪.২ Session Manager-কে চিনিয়েছিল SSH আর bastion host-এর আধুনিক বিকল্প হিসেবে। এক লাইনে: agent-এর outbound channel তোমার shell বয়ে নিয়ে যায়, তাই instance-এর লাগে না কোনো inbound rule, না public IP, না SSH key, না bastion, আর কে যুক্ত হবে ঠিক করে IAM। এর ওপরে একজন architect-এর আর যা জানা দরকার:

Session কীভাবে চলে। তুমি start-session ডাকো (CLI-তে, Session Manager plugin-সহ) অথবা console-এ Connect চাপো। IAM ওই instance-এ ssm:StartSession-এর অনুমতি যাচাই করে। Session Manager agent-কে একটা data channel খুলতে বলে, আর keystroke ও output TLS-এর ভেতর দিয়ে সেখানে চলাচল করে। Linux, Windows (PowerShell) আর macOS চলে; Windows-এ Fleet Manager দিয়ে browser-এই graphical RDP session-ও পাওয়া যায়।

Preference (প্রতি account আর Region-এ এক সেট):

• Session logging: command আর output CloudWatch Logs-এ stream করা, আর/অথবা session শেষে পুরো transcript একটা S3 bucket-এ রাখা। “সব terminal command log করো” এভাবেই হয়।
• TLS-এর ওপর আরেক স্তর, তোমার নিজের key দিয়ে session data-র KMS encryption।
• Idle timeout: default ২০ মিনিট, ১ থেকে ৬০ দেওয়া যায়। Maximum session duration দিয়ে ব্যস্ত session-কেও সীমায় বাঁধা যায়।
• Linux-এ Run As: default ssm-user-এর বদলে একটা নির্দিষ্ট OS user হিসেবে session শুরু; shell profile দিয়ে shell-এর পরিবেশ ঠিক করা।

Port forwarding। AWS-StartPortForwardingSession local একটা port-কে instance-এর একটা port-এ নিয়ে যায়। AWS-StartPortForwardingSessionToRemoteHost নিয়ে যায় এমন একটা remote host-এ যেখানে instance পৌঁছাতে পারে, যেমন একটা private RDS database: তোমার laptop-এর localhost:3306 instance-এর ভেতর দিয়ে database-এ পৌঁছায়, কোথাও inbound কিছু না খুলেই। Session Manager-এর ভেতর দিয়ে SSH আর scp (AWS-StartSSHSession, SSH-এর ProxyCommand হিসেবে) দিয়ে যে tool SSH ছাড়া চলবেই না, সেটাও port 22 ছাড়া চলে।

Tag ধরে access। Resource tag-এর ওপর IAM condition (ssm:resourceTag/Env) দিয়ে developer-দের session দেওয়া যায় শুধু Env=dev-এ। এপ্রিল ২০২৫ থেকে unified console-এর just-in-time node access production node-এর জন্য approval policy যোগ করে (আপনা-আপনি, approver-সহ হাতে, বা deny); একটা ফ্রি trial-এর পর এর দাম ধরা হয় প্রতি node, প্রতি ঘণ্টা হিসেবে।

#Run Command

Run Command একসেট managed node-এ একটা Command document চালায় এখনই, কোনোটায় login না করে: software বসানো, একটা service restart, একটা log তুলে আনা, configuration file বদলানো। Notes-এর ভাষায়: SSH ছাড়া একসাথে ১০০টা EC2 instance-এ script চালানো।

প্রতিটা command-এ তুমি যা বাছো:

• Document: তোমার command-সহ AWS-RunShellScript বা AWS-RunPowerShellScript, অথবা যেকোনো Command document।
• Target: tag, resource group, instance ID, বা সব node।
• Rate control:
  • Max concurrency: একসাথে কয়টা node-এ command চলবে, একটা সংখ্যা (10) বা শতাংশ (10%)। Default ৫০।
  • Max errors: কয়টা ব্যর্থতা সহ্য হবে। এই সংখ্যার চেয়ে একবার বেশি ব্যর্থ হলেই Systems Manager নতুন target-এ পাঠানো বন্ধ করে। যেগুলোতে আগেই চলছিল সেগুলো শেষ হতে দেয়, তাই শেষ হিসাব সীমার একটু ওপরে যেতে পারে। Default ০: প্রথম ব্যর্থতাতেই rollout থামে।
• Timeout: offline node-এর জন্য delivery কতক্ষণ অপেক্ষা করবে, আর script কতক্ষণ চলতে পারবে।
• Output: লম্বা output-এর শুধু শুরুটা console দেখায়; পুরোটা পাঠাও একটা S3 bucket-এ আর/অথবা CloudWatch Logs-এ।
• Notification: অবস্থা বদলালে (In progress, Success, Failed, Timed out…) SNS message, পুরো command-এর জন্য বা প্রতিটা node-এর জন্য।

Run Command একটা EventBridge target-ও (লেসন ১৯.৫), তাই একটা event (নতুন instance চালু হলো, একটা schedule) একে চালু করতে পারে। প্রতিটা SendCommand call CloudTrail লিখে রাখে, আর কে কোন node-এ কোন document চালাতে পারবে তা ঠিক করে IAM। EC2-তে এর কোনো খরচ নেই; hybrid node-এ ৩০ সেপ্টেম্বর ২০২৬ থেকে প্রতিটা invocation-এর চার্জ আছে।

Rate control হলো একটা নিরাপত্তার ছিটকিনি। নিজে চালিয়ে দেখো: বড় fleet-এ খারাপ script থাকলেও ঠিকঠাক max concurrency আর max errors ক্ষতিটা হাতে গোনা কয়েকটা server-এ আটকে রাখে।

#Patch Manager

Patch Manager managed node-এ operating system আর কিছু application-এর patching অটোমেট করে: Windows Server, Amazon Linux, Ubuntu, Red Hat Enterprise Linux, Debian, macOS আর আরও কিছু, EC2-তে আর on-premises-এ। এটা তিনটা কাজ করে: কোন patch অনুমোদিত তা ঠিক করা, scan বা install করা, আর compliance জানানো।

#Patch baseline: কী অনুমোদিত

Patch baseline হলো নিয়মের খাতা। প্রতিটা operating system-এর জন্য AWS-এর একটা তৈরি default baseline আছে (যেমন Windows-এ critical আর security update release-এর ৭ দিন পরে অনুমোদিত)। তুমি নিজেরটাও বানাতে পারো:

• Approval rule: product, classification (Security, Critical, Bugfix…) আর severity, সাথে একটা auto-approval-এর দেরি (ApproveAfterDays, release-এর ০ থেকে ৩৬০ দিন পরে), বা নির্দিষ্ট cutoff-এর জন্য একটা approve-until তারিখ। দেরি রাখলে তোমার কাছে পৌঁছানোর আগে বাকি দুনিয়া এক সপ্তাহ সময় পায় খারাপ patch ধরতে।
• Approved আর rejected patch-এর তালিকা: নির্দিষ্ট একটা patch জোর করে ঢোকাও (জরুরি fix), বা একটা বাইরে রাখো (যেটা তোমার software ভেঙে দেয় বলে জানা)।
• Missing patch-এর compliance severity, আর Linux-এ non-security update চলবে কিনা ও কোন repository ব্যবহার হবে।

Baseline ঠিক করে কী চলবে; patch-গুলো নিজে আসে চেনা উৎস থেকেই (Windows Update বা তোমার নিজের update server, Linux distribution-এর repository)।

#কোন node কোন baseline পাবে

দুটো উপায়, পুরোনো আর নতুন:

• Patch group: node-কে Patch Group (বা PatchGroup) = branches tag দাও, আর সেই patch group-কে একটা baseline-এর সাথে register করো। কোনো patch group-এ না থাকা node পায় তার OS-এর default baseline।
• Patch policy (Quick Setup-এ, ২০২২ থেকে): একটা policy-ই একটা Organization-এর অনেক account আর Region-এর জন্য baseline, scan আর install-এর schedule আর target একসাথে ঠিক করে দেয়। নতুন setup-এর জন্য AWS এটাই সুপারিশ করে।

#Scan, Install আর compliance

Patching চালায় Command document AWS-RunPatchBaseline, Run Command দিয়ে, সাধারণত একটা Maintenance Window-এর ভেতরে:

• Operation=Scan: যা install আছে তার সাথে baseline মিলিয়ে কী বাকি তা জানায়। কিছুই বদলায় না, কিছু reboot-ও হয় না। প্রতিদিন চালাও।
• Operation=Install: অনুমোদিত বাকি patch বসায়, তারপর দরকার হলে reboot (RebootIfNeeded, বা পরে নিজে reboot করতে চাইলে NoReboot)। Window-এর ভেতরে চালাও।

প্রতিবার চলার পর node জানায় Compliant নাকি Non-compliant, সাথে বাকি patch-এর তালিকা। Compliance দেখা যায় Patch Manager-এর dashboard-এ, Systems Manager-এর Compliance-এ, আর এটা AWS Config আর Security Hub-এও যেতে পারে।

#Maintenance Windows

একটা maintenance window ঠিক করে ঝামেলার কাজ কখন হতে পারবে। Notes-এর পরীক্ষার ভাষায়: “ঝামেলার update যেন শুধু ছুটির দিনে বা ভিড় কম এমন সময়ে হয়”। একটা window-এ থাকে:

• একটা schedule: cron বা rate expression, সাথে একটা time zone (Asia/Dhaka; না দিলে schedule UTC ধরা হয়) আর ইচ্ছে হলে দিনের হিসাবে একটা offset (“Patch Tuesday-র দুদিন পরে”-র জন্য)।
• একটা duration: ১ থেকে ২৪ ঘণ্টা।
• একটা cutoff: শেষের ০ থেকে ২৩ ঘণ্টা আগে, যার পরে নতুন কোনো task শুরু হয় না। চলমান task চলতে থাকে।
• Register করা target: tag, resource group বা ID দিয়ে node।
• Register করা task, প্রতিটার একটা priority (ছোট সংখ্যা আগে চলে) আর নিজস্ব max concurrency ও max errors। চার ধরনের task: Run Command, Automation, Lambda আর Step Functions।

Window-এ register করা task চলে শুধু window খোলা থাকলে। মঙ্গলবার দুপুরে যোগ করা ঝামেলার task শুক্রবার রাতের জন্য অপেক্ষা করে। এখনই কিছু করতেই হলে command সরাসরি চালাও, window-এর বাইরে, ইচ্ছে করে।

#Automation

Automation চালায় runbook: কয়েক ধাপের Automation document, যেগুলো AWS resource আর instance-এর ওপর কাজ করে। Run Command যেখানে node-এ একটা script চালায়, সেখানে একটা runbook একটা instance থামাতে পারে, অপেক্ষা করতে পারে, তার volume-এর snapshot নিতে পারে, একটা API ডাকতে পারে, script চালাতে পারে, একজন মানুষের অনুমোদন চাইতে পারে, ফলাফল দেখে পথ বদলাতে পারে আর image বানাতে পারে, সবকিছু log, retry আর rate control-সহ।

চেনা step action: aws:executeAwsApi (যেকোনো AWS API ডাকো), aws:runCommand (instance-এ Command document চালাও), aws:executeScript (Python বা PowerShell), aws:invokeLambdaFunction, aws:approve (approver উত্তর না দেওয়া পর্যন্ত থামো, SNS দিয়ে খবর যায়), aws:branch, aws:waitForAwsResourceProperty, aws:createImage।

AWS-এর নিজের runbook notes আর slide-এর চেনা কাজগুলো সেরে দেয়:

• Instance restart: AWS-RestartEC2Instance।
• AMI বানানো: AWS-CreateImage; পুরো golden-AMI pipeline (launch, patch, test, image, terminate): AWS-UpdateLinuxAmi আর AWS-UpdateWindowsAmi।
• EBS volume-এর snapshot, আর troubleshooting-এর অনেক AWSSupport- runbook (হারানো key reset, পৌঁছানো যাচ্ছে না এমন instance ঠিক করা)।

Runbook কে চালু করে (slide p839):

• হাতে, console, CLI বা SDK থেকে (start-automation-execution)।
• একটা EventBridge rule, কোনো event-এ বা schedule-এ (EventBridge Scheduler)।
• একটা Maintenance Window-এর task।
• Non-compliant resource-এর জন্য AWS Config remediation (লেসন ১৯.৭), হাতে বা retry-সহ আপনা-আপনি।
• একটা CloudWatch alarm, alarm-এর অবস্থা বদলের ওপর EventBridge rule দিয়ে (লেসন ১৯.৩), বা OpsCenter-এর একটা OpsItem থেকে।

Runbook কাজ করে একটা automation role নিয়ে (AutomationAssumeRole parameter), তাই যে চালায় তার সেই role-এর জন্য iam:PassRole লাগে, আর role-এর লাগে ঠিক ততটুকু অনুমতি যতটুকু step-গুলো ডাকে। Rate control দিয়ে একটা runbook অনেক target-এ (tag ধরে) max concurrency আর max errors মেনে চলতে পারে, আর একটা কেন্দ্রীয় account থেকে Organization-এর অনেক account আর Region-এ চলতে পারে। দাম প্রতি step-এ (প্রতি step ০.০০২ USD, সাথে aws:executeScript-এর চলার সময়)।

#বাক্সের বাকি যন্ত্র

পরীক্ষা এগুলোর যেকোনোটার নাম একটা option-এ দিতে পারে। প্রতিটা এক লাইনে:

#কোন Systems Manager tool?

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

• Instance তালিকায় নেই। তিনটার একটা: agent নেই, অনুমতি নেই (instance profile নেই, Default Host Management Configuration বন্ধ, বা চালু কিন্তু IMDSv1), বা বাইরে যাওয়ার পথ নেই (NAT নেই, endpoint নেই)। এই ক্রমেই যাচাই করো; unified console-এর diagnosis তোমার হয়ে এটা করে দেয়।
• Endpoint আছে কিন্তু কিছুই যুক্ত হয় না। Endpoint-এর security group-এ instance থেকে inbound 443 নেই, বা endpoint-এ private DNS বন্ধ।
• Connection lost। Agent বন্ধ, disk ভরা, ঘড়ি ভুল (signature মেলে না), বা instance profile সরানো হয়েছে (হারানোটা দেখা দিতে এক ঘণ্টা পর্যন্ত লাগতে পারে)।
• Session Manager চলে, কিন্তু log আসে না। Session logging চালু নেই, instance-এর role bucket বা log group-এ লিখতে পারে না, private subnet-এ logs বা S3 endpoint নেই, বা session-টা ছিল port-forwarding বা SSH session, যেটা session logging লেখে না।
• “CloudTrail-এ তো দেখা উচিত সে কী টাইপ করেছে।” সেখানে আছে শুধু StartSession। Session logging চালু করো।
• একটা command ৩০টা server-এ পৌঁছে সবগুলো ভেঙে দিল। Max concurrency ছিল ৫০ (default) বা ১০০%। ছোট শতাংশ আর কম max errors দাও।
• প্রথম ব্যর্থতাতেই command থেমে গেল। Max errors-এর default ০। জেনে-বুঝে ঠিক করো।
• Patch compliance সবুজ, কিন্তু একটা server patch হয়নি। Server-টা managed node না, তাই সে কখনো report-ই করেনি। Managed node-এর সংখ্যা EC2-এর তালিকার সাথে মেলাও, আর ec2-instance-managed-by-systems-manager Config rule ব্যবহার করো।
• গতকাল বের হওয়া patch install হলো না। Baseline-এর auto-approval-এর দেরি এখনো পেরোয়নি। জরুরি হলে approved তালিকায় যোগ করো।
• Window রাত ২টার বদলে সকাল ৮টায় চলল। Schedule-এ time zone ছিল না, তাই UTC ধরা হয়েছে। --schedule-timezone Asia/Dhaka দাও।
• একটা task কখনো শুরুই হলো না। সেটা cutoff-এর পরে register হয়েছিল, বা আগের task-গুলো cutoff পেরিয়ে চলেছে।
• Automation runbook AccessDenied দিয়ে ব্যর্থ। কোনো step-এর দরকারি অনুমতি automation role-এ নেই, বা যে চালাচ্ছে তার role-টার জন্য iam:PassRole নেই।
• Hybrid server register হয় না। Activation-এর মেয়াদ শেষ বা registration-এর সীমা ফুরিয়েছে, বা অফিসের firewall outbound 443 আটকে দেয়।

#System design-এ Systems Manager

• কোথাও কোনো inbound management port নেই। মানুষের জন্য Session Manager, machine-এর জন্য Run Command আর Automation; security group-এ 22 বা 3389-এর rule নেই; private subnet interface endpoint দিয়ে Systems Manager-এ পৌঁছায়। Bastion host উধাও।
• শুরু থেকেই managed। প্রতিটা account আর Region-এ Default Host Management Configuration (বা Quick Setup-এর host management configuration) চালু রাখো, যাতে কারো role মনে রাখার দরকারই না পড়ে, নতুন instance আপনা-আপনি managed হয়। একটা Config rule দিয়ে যাচাই করো।
• স্তরে স্তরে patch। দেখার জন্য প্রতিদিন Scan, install হবে window-তে, auto-approval-এর দেরি রাখো, আগে staging patch group-এ পরীক্ষা করো, install-এর আগে AMI বা snapshot নাও।
• যেখানে পারো, immutable। Load balancer-এর পেছনের fleet-এ server-এর ভেতরে patch না করে Automation (বা Image Builder) দিয়ে golden AMI patch করো, আর instance বদলে দাও।
• আটকাও, ধরো, সারাও। SCP আর IAM আটকায়; Config আর Inspector ধরে; Automation runbook সারায়; EventBridge এদের জোড়া দেয় (লেসন ১৯.৭)।
• অনেক account। পুরো Organization জুড়ে Quick Setup আর patch policy, account আর Region জুড়ে Automation, এক নজরে দেখার জন্য Explorer আর unified console।
• Configuration code-এর বাইরে। Setting আর AMI ID-র জন্য Parameter Store, rotate হওয়া secret-এর জন্য Secrets Manager (লেসন ২১.৩)।
• On-premises-এও একই যন্ত্র। Hybrid activation শাখা আর data center-এর server-কে একই session, patching আর inventory-র আওতায় আনে, যেটা migration-এর আগেও কাজে লাগে (লেসন ২৩.৪)।

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

এই command-গুলো AWS CLI v2-এর, ID-গুলো বানানো। EC2-তে Session Manager আর Run Command-এর কোনো খরচ নেই; Automation-এর step, hybrid-এর session আর invocation, NAT gateway আর endpoint-এ খরচ আছে।

# কোন node managed, আর সেগুলো online কিনা
aws ssm describe-instance-information \
  --query 'InstanceInformationList[].[InstanceId,PingStatus,PlatformName,AgentVersion]' --output text
# i-0a1b2c3d4e5f67890    Online           Amazon Linux    3.3.1802.0
# i-0b2c3d4e5f6789012    ConnectionLost   Ubuntu          3.2.2303.0
# mi-0c3d4e5f678901234   Online           Microsoft Windows Server 2022 Datacenter   3.3.1611.0

# এই account আর Region-এ Default Host Management Configuration চালু করো
aws ssm update-service-setting \
  --setting-id arn:aws:ssm:ap-south-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role \
  --setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole

# কোনো inbound port ছাড়াই shell (Session Manager plugin লাগবে)
aws ssm start-session --target i-0a1b2c3d4e5f67890
# Starting session with SessionId: admin-0a1b2c3d4e5f6a7b8
# sh-5.2$

# Instance-এর ভেতর দিয়ে laptop-এর 3306 port একটা private RDS database-এ forward করো
aws ssm start-session --target i-0a1b2c3d4e5f67890 \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["accounts-db.abc123xyz.ap-south-1.rds.amazonaws.com"],"portNumber":["3306"],"localPortNumber":["3306"]}'
# Port 3306 opened for sessionId admin-1b2c3d4e5f6a7b8c9.
# Waiting for connections...

# প্রতিটা prod server-এ script, একবারে ১০%, ৫টা ব্যর্থতার পর থামো, পুরো output S3-এ
aws ssm send-command --document-name AWS-RunShellScript \
  --targets Key=tag:Env,Values=prod \
  --parameters 'commands=["sudo dnf install -y amazon-cloudwatch-agent"]' \
  --max-concurrency 10% --max-errors 5 \
  --output-s3-bucket-name erp-command-output-example \
  --query 'Command.[CommandId,Status,TargetCount]' --output text
# 7b9c2e1a-3f4d-4c5b-9a8e-EXAMPLE11111    Pending    0

aws ssm list-command-invocations --command-id 7b9c2e1a-3f4d-4c5b-9a8e-EXAMPLE11111 \
  --query 'CommandInvocations[].[InstanceId,Status]' --output text
# i-0a1b2c3d4e5f67890    Success
# i-0d4e5f6789012345a    Failed

# Patch baseline: Windows-এর security আর critical update, release-এর ৭ দিন পরে অনুমোদন
aws ssm create-patch-baseline --name branches-windows --operating-system WINDOWS \
  --approval-rules 'PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=CLASSIFICATION,Values=[SecurityUpdates,CriticalUpdates]}]},ApproveAfterDays=7}]'
# { "BaselineId": "pb-0123456789abcdef0" }
aws ssm register-patch-baseline-for-patch-group --baseline-id pb-0123456789abcdef0 --patch-group branches

# Scan-এর পর প্রতিটা node-এর patch-এর অবস্থা
aws ssm describe-instance-patch-states --instance-ids mi-0c3d4e5f678901234 \
  --query 'InstancePatchStates[].[InstanceId,Operation,InstalledCount,MissingCount,FailedCount]' --output text
# mi-0c3d4e5f678901234    Scan    214    7    0

# Maintenance window: প্রতি শুক্রবার ঢাকার সময় রাত ২টা, ৩ ঘণ্টা, cutoff ১ ঘণ্টা
aws ssm create-maintenance-window --name branch-patching \
  --schedule "cron(0 2 ? * FRI *)" --schedule-timezone Asia/Dhaka \
  --duration 3 --cutoff 1 --no-allow-unassociated-targets
# { "WindowId": "mw-0a1b2c3d4e5f67890" }
aws ssm register-target-with-maintenance-window --window-id mw-0a1b2c3d4e5f67890 \
  --resource-type INSTANCE --targets 'Key=tag:Patch Group,Values=branches'
# { "WindowTargetId": "e32eecb2-646c-4f4b-8ed1-EXAMPLE22222" }
aws ssm register-task-with-maintenance-window --window-id mw-0a1b2c3d4e5f67890 \
  --task-type RUN_COMMAND --task-arn AWS-RunPatchBaseline --priority 2 \
  --targets Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-EXAMPLE22222 \
  --max-concurrency 10% --max-errors 5 \
  --task-invocation-parameters '{"RunCommand":{"Parameters":{"Operation":["Install"],"RebootOption":["RebootIfNeeded"]}}}'

# Automation: একটা instance থেকে AMI বানাও (role pass করা হয়, তাই iam:PassRole লাগবে)
aws ssm start-automation-execution --document-name AWS-CreateImage \
  --parameters InstanceId=i-0a1b2c3d4e5f67890,AutomationAssumeRole=arn:aws:iam::111122223333:role/ssm-automation-example
# { "AutomationExecutionId": "4105a4fc-f944-4ddc-a9fe-EXAMPLE33333" }
aws ssm get-automation-execution --automation-execution-id 4105a4fc-f944-4ddc-a9fe-EXAMPLE33333 \
  --query 'AutomationExecution.[AutomationExecutionStatus,Outputs]'
# [ "Success", { "createImage.ImageId": [ "ami-0123456789abcdef0" ] } ]

# ৩০০টা শাখার server-এর জন্য hybrid activation, ৭ দিনের মেয়াদ
aws ssm create-activation --default-instance-name branch-server \
  --iam-role SSMServiceRole-example --registration-limit 300 \
  --expiration-date 2026-11-08T00:00:00Z
# { "ActivationId": "e488f2f6-e686-4afb-8a04-EXAMPLE44444", "ActivationCode": "EXAMPLE-ACTIVATION-CODE" }
# Server-এ: amazon-ssm-agent -register -code "<code>" -id "<id>" -region ap-south-1

#সারসংক্ষেপ

মূল কথা

• Systems Manager EC2, on-premises আর অন্য cloud-এর server সামলায় managed node হিসেবে: SSM Agent + অনুমতি (AmazonSSMManagedInstanceCore-ওয়ালা instance profile, বা IMDSv2-সহ Default Host Management Configuration) + বাইরের দিকে 443 (NAT, বা ssm, ssmmessages interface endpoint, পুরোনো agent-এ ec2messages-ও; endpoint SG 443 allow করে, private DNS চালু)। Status: Online, Connection lost, বা তালিকায় নেই।
• Hybrid activation on-premises server-কে mi- node হিসেবে register করে। ৩০ জুন ২০২৬ থেকে advanced-instances tier নেই; ৩০ সেপ্টেম্বর ২০২৬ থেকে hybrid node-এ Session Manager আর Run Command যতটুকু ব্যবহার ততটুকু দাম। EC2-তে ফ্রি।
• Session Manager: inbound port নেই, bastion নেই, SSH key নেই, tag ধরে IAM; S3 / CloudWatch Logs-এ session logging command লেখে; CloudTrail লেখে শুধু StartSession; RDS-এর মতো remote host-এ port forwarding; এর ভেতর দিয়ে SSH।
• Run Command: এখনই অনেক node-এ একটা Command document, tag দিয়ে target; max concurrency (default ৫০) আর max errors (default ০, তারপর নতুন target নেই); output S3 / CloudWatch Logs-এ; SNS notification; EventBridge চালু করতে পারে।
• Patch Manager: baseline (approval rule, ৩৬০ দিন পর্যন্ত auto-approval-এর দেরি, approved/rejected তালিকা), patch group বা patch policy; Scan (শুধু report) বা Install (আর reboot) দিয়ে AWS-RunPatchBaseline; compliance report। Inspector CVE খোঁজে; Patch Manager fix বসায়।
• Maintenance Windows: schedule (cron/rate, time zone, offset), duration ১–২৪ ঘণ্টা, cutoff ০–২৩ ঘণ্টা, target, priority অনুযায়ী task (Run Command, Automation, Lambda, Step Functions)। Task window-এর জন্য অপেক্ষা করে। পরীক্ষা: “শুধু সপ্তাহান্তে / ভিড় কম সময়ে”।
• Automation: কয়েক ধাপের runbook (AWS-RestartEC2Instance, AWS-CreateImage, AWS-UpdateLinuxAmi), approval, rate control, অনেক account আর অনেক Region; চালু হয় হাতে, EventBridge দিয়ে (event, schedule, alarm-এর অবস্থা বদল), Maintenance Window দিয়ে বা Config remediation দিয়ে; চলে automation role নিয়ে (যে চালায় তার iam:PassRole লাগে)।
• বাকিরা: State Manager (desired state), Inventory, Fleet Manager, Distributor, OpsCenter, Explorer, Change Calendar, Quick Setup, Parameter Store। Change Manager আর Incident Manager ৭ নভেম্বর ২০২৫ থেকে নতুন গ্রাহকের জন্য বন্ধ। Unified console নভেম্বর ২০২৪ থেকে।

নিজেকে যাচাই করো: Systems Manager৩২টি প্রশ্ন