Well-Architected Framework আর Trusted Advisor

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

• AWS Well-Architected Framework কী, বুঝিয়ে বলতে (design principle, pillar, প্রশ্ন আর best practice নিয়ে একটা নির্দেশনার ভান্ডার, deploy করার মতো কোনো service না), আর পরীক্ষার প্রতিটা উত্তর যে মাপকাঠিতে বিচার হয়, সেটা হিসেবে একে ব্যবহার করতে।
• ছয়টা general design principle কাজে লাগাতে, “game day দিয়ে উন্নতি” সহ, আর বলতে পারতে প্রতিটা একটা design-এ কী বদলায়।
• ছয়টা pillar-এর নাম, তাদের লক্ষ্য, মূল design principle, এই course-এর কোন service কোন pillar বাস্তবায়ন করে, আর কোন keyword কোন pillar-এর দিকে ইশারা করে, বলতে; কখন pillar-গুলো একে অন্যকে সাহায্য করে আর কখন প্রশ্ন একটা trade-off করতে বাধ্য করে, চিনতে।
• AWS Well-Architected Tool-এ একটা review চালাতে: workload, lens, high আর medium risk issue, improvement plan, milestone, profile, review template, sharing আর integration।
• AWS Trusted Advisor বর্ণনা করতে: ছয়টা check category, সাধারণ check, status-এর রং, ২০২৫–২৬-এর support plan বদলের পরে কোন plan কী খুলে দেয়, API, EventBridge আর organizational view।
• Well-Architected Tool, Trusted Advisor, AWS Config, Compute Optimizer, AWS Health Dashboard আর তাদের প্রতিবেশীদের আলাদা করে চিনতে, আর reference architecture ও Disaster Recovery whitepaper কোথায় বসে, জানতে।

#Framework কেন: একটা architecture-এর বিচার

এই course-এর প্রতিটা অধ্যায় শেষ হয়েছে কিছু বাছাই দিয়ে: এক AZ না তিন AZ, On-Demand না Spot, SQS না Kinesis, pilot light না warm standby। একটা design যে ভালো, সেটা বুঝবে কীভাবে? AWS এর উত্তর দেয় Well-Architected Framework দিয়ে: কিছু document, যেখানে AWS লিখে রেখেছে হাজার হাজার customer-এর architecture review করে সে কী কী শিখেছে।

Framework হলো নির্দেশনা, কোনো service না। কিছু deploy হয় না, কোনো bill আসে না। এর ভেতরে আছে:

• Cloud-এ বানানোর জন্য general design principle (পরের অংশে)।
• ছয়টা pillar, প্রত্যেকটার নিজের design principle, কিছু প্রশ্ন (“তুমি data-র backup কীভাবে নাও?”) আর best practice, যেগুলো একটা ভালো উত্তরে থাকা উচিত।
• Lens: নির্দিষ্ট ধরনের workload-এর জন্য বাড়তি প্রশ্ন (serverless, SaaS, financial services আর আরও কিছু)।

এটা প্রকাশিত হয় AWS Well-Architected Framework whitepaper হিসেবে, সাথে প্রতিটা pillar-এর জন্য একটা করে whitepaper, সবই docs.aws.amazon.com/wellarchitected-এ। বিনা খরচের AWS Well-Architected Tool (এই লেসনেই পরে আসছে) প্রশ্নগুলোকে একটা প্রশ্নমালা বানিয়ে দেয়, যেটা তুমি নিজের workload-এর জন্য পূরণ করো।

#General design principle

Pillar-এর আগে framework ছয়টা নীতি দেয়, যেগুলো প্রতিটা design-এ খাটে। নিজের data centre-এর মালিক থাকা বন্ধ করলে ঠিক এই জিনিসগুলোই বদলে যায় (লেসন ১.১)।

Slide-এ দুটো নীতির পুরোনো শব্দ আছে (“automate to make architectural experimentation easier”, “allow for evolutionary architectures”); মানে একই।

#Game day দিয়ে উন্নতি

Game day হলো পরিকল্পিত মহড়া: তুমি একটা অনুমান লেখো (“১০ গুণ traffic-এও checkout ১ সেকেন্ডের নিচে থাকবে”, “একটা AZ নষ্ট হলে user কিছু টের পাবে না”), ইচ্ছা করে ঘটনাটা ঘটাও, তাকিয়ে দেখো, আর যা ভাঙে তা ঠিক করো। Load generator traffic বানায়; AWS Fault Injection Service নিয়ন্ত্রিতভাবে failure ঢোকায় (instance বন্ধ করা, database failover করানো, একটা AZ-এ গোলমাল বাধানো), সাথে থাকে stop condition, সত্যিকারের ক্ষতি শুরু হলে যা পরীক্ষা থামিয়ে দেয় (DR-এর drill আর chaos testing আছে লেসন ২৩.১-এ)।

#ছয়টা pillar

Framework একটা design-কে ছয়টা pillar দিয়ে বিচার করে। এদের নাম, এক লাইনের লক্ষ্য, আর কোন শব্দ কোনটার দিকে ইশারা করে, শিখে নাও।

Sustainability সবচেয়ে নতুন: যোগ হয়েছে ২০২১-এর শেষে (Well-Architected Tool-এ এসেছে ২০২২-এর মার্চে), তাই পুরোনো লেখায় পাঁচটা pillar দেখবে। লেসন ১.১ আর ৯.১-এ এদের প্রথম ঝলক দেখেছ; এখানে একটা একটা করে গভীরে।

#Operational excellence

লক্ষ্য: workload ভালোভাবে চালানো, সে কী করছে দেখতে পাওয়া, আর চালানোর ধরন ক্রমাগত ভালো করা।

Design principle (AWS আটটা বলে; পরীক্ষায় বেশি আসা পাঁচটা):

• যেখানে পারো, নিরাপদে automate করো: পুরো workload আর তার operation code হিসেবে লেখো, event দিয়ে চালু হয়, সাথে rate limit আর approval-এর মতো guardrail।
• ঘন ঘন, ছোট, ফেরানো যায় এমন change করো: ছোট deploy মানে ক্ষতির পরিধি ছোট, আর দ্রুত rollback।
• কাজে লাগে এমন observability রাখো: business-এর ফলাফলের সাথে বাঁধা metric, log আর trace, যাতে customer টের পাওয়ার আগেই ব্যবস্থা নিতে পারো।
• Failure আগে থেকে ভাবো আর প্রতিটা operational ঘটনা থেকে শেখো: failure-এর মহড়া দাও, incident-এর পরে review করো, শিক্ষা সবার সাথে ভাগ করো।
• Managed service ব্যবহার করো: আলাদা কিছু যোগ করে না এমন operational খাটুনি কমে।

এই course-এর service: CloudFormation আর IaC (লেসন ২৫.১), Systems Manager-এর runbook, Patch Manager আর Session Manager (লেসন ২৫.৩), CloudWatch metric, log, alarm আর dashboard (লেসন ১৯.১ থেকে ১৯.৪), X-Ray, EventBridge দিয়ে automation (১৯.৫), Elastic Beanstalk (৯.৪)।

পরীক্ষার keyword: “least operational overhead”, “automate deployments”, “infrastructure as code”, “roll back quickly”, “runbook”, “monitor and respond to events”, “reduce manual effort”।

উদাহরণ: একটা ride-sharing startup প্রতি শুক্রবার রাতে SSH দিয়ে হাতে deploy করত; তারা CloudFormation আর এক click-এ rollback করা যায় এমন automated pipeline-এ চলে যায়। Release ছোট আর একঘেয়ে হয়ে যায়, আর ঠিক সেটাই উদ্দেশ্য।

#Security

লক্ষ্য: value দেওয়া চালিয়ে যেতে যেতেই তথ্য, system আর সম্পদ সুরক্ষিত রাখা।

Design principle:

• শক্ত একটা identity-র ভিত বানাও: least privilege, দায়িত্ব ভাগ করা, এক জায়গায় identity, দীর্ঘমেয়াদি স্থির credential নয়।
• Traceability রাখো: প্রতিটা কাজ আর বদল log, monitor আর alert করো।
• প্রতিটা স্তরে security দাও: network-এর কিনারা থেকে code পর্যন্ত গভীর প্রতিরক্ষা।
• Data in transit আর at rest সুরক্ষিত রাখো: data-কে শ্রেণিতে ভাগ করো আর encryption, tokenisation, access control ব্যবহার করো।
• মানুষকে data থেকে দূরে রাখো, security best practice automate করো, আর security event-এর জন্য তৈরি থাকো (incident response plan আর মহড়া)।

এই course-এর service: IAM, role আর MFA (অধ্যায় ২), Organizations আর SCP (২০.১), KMS (২১.২), ACM (২১.৪), Secrets Manager (২১.৩), AWS WAF আর Shield (২১.৬), GuardDuty, Inspector, Macie আর Security Hub (২১.৭), CloudTrail (১৯.৬), security group আর NACL (৩.৫)।

পরীক্ষার keyword: “protect data at rest and in transit”, “least privilege”, “temporary credentials”, “audit who did what”, “encrypt with keys we control”, “detect threats”, “block common web exploits”।

উদাহরণ: একটা microfinance app জাতীয় পরিচয়পত্রের scan রাখে; সেগুলো SSE-KMS আর একটা customer managed key দিয়ে encrypt করা, ফলে key-এর প্রতিটা ব্যবহার CloudTrail-এ ওঠে, আর security team-এর অনুমোদিত role ছাড়া কোনো engineer bucket পড়তে পারে না।

#Reliability

লক্ষ্য: workload যে কাজ করার কথা, ঠিকভাবে আর ধারাবাহিকভাবে করে, আর failure থেকে দ্রুত ফিরে আসে।

Design principle (পাঁচটাই):

• Failure থেকে নিজে নিজে ফিরে এসো: মূল সূচকগুলো দেখো, আর নিজে থেকে recovery শুরু করাও।
• Recovery procedure test করো: failure ঘটিয়ে দেখাও যে restore আর failover সত্যিই কাজ করে।
• মোট availability বাড়াতে horizontally scale করো: একটা বড় resource-এর বদলে অনেক ছোট, যাতে একটার failure ছোট থাকে।
• Capacity আন্দাজ করা বন্ধ করো: চাহিদা দেখো আর নিজে থেকে resource যোগ-বাদ দাও (ভরে যাওয়া outage-এর পুরোনো কারণ; quota তবুও থাকে)।
• Change automation দিয়ে সামলাও: infrastructure-এর বদল এমন automation দিয়ে যায়, যা track আর review হয়।

এই course-এর service: Multi-AZ RDS আর Aurora (৭.১, ৭.৩), কয়েকটা AZ জুড়ে Auto Scaling group (৬.৫), load balancer-এর health check (৬.২), Route 53 health check আর failover (৮.৩, ৮.৪), SQS দিয়ে decoupling (১৩.১), backup আর DR (২৩.১, ২৩.২), Service Quotas।

পরীক্ষার keyword: “recover from failure”, “highly available”, “fault tolerant”, “survive the loss of an AZ / a Region”, “RTO and RPO”, “no single point of failure”, “self-healing”।

উদাহরণ: যে hospital প্রতি রাতে backup নেয় কিন্তু একবারও restore করেনি, তার আসলে backup নেই; আছে একটা আশা। প্রতি মাসে restore করে RTO-র সাথে সময় মেলানোই “recovery procedure test করো” নীতি।

#Performance efficiency

লক্ষ্য: দক্ষতার সাথে computing resource ব্যবহার করে চাহিদা মেটানো, আর চাহিদা ও প্রযুক্তি বদলালেও সেই দক্ষতা ধরে রাখা।

Design principle (পাঁচটাই):

• উন্নত প্রযুক্তি সবার নাগালে আনো: কঠিন জিনিস (NoSQL, machine learning, media transcoding) নিজে না বানিয়ে service হিসেবে নাও।
• কয়েক মিনিটে global হও: কম latency-র জন্য কয়েকটা Region-এ আর edge-এ deploy করো।
• Serverless architecture ব্যবহার করো: অনেক কাজে চালানোর মতো কোনো server-ই থাকে না।
• বেশি বেশি পরীক্ষা করো: অন্য instance type, storage বা configuration দ্রুত চালিয়ে দেখো।
• Mechanical sympathy মাথায় রাখো: access pattern-এর সাথে মেলে এমন প্রযুক্তি বাছো (সম্পর্কের জন্য graph database, গরম read-এর জন্য cache)।

এই course-এর service: CloudFront (১১.১) আর Global Accelerator (১১.৪), ElastiCache আর DAX (৭.৫, ১৫.৫), read replica (৭.১), purpose-built database (১৬.১, ১৬.২), Lambda আর serverless design (১৫.৮), instance family আর placement group (৪.১, ৪.৫), EBS volume type (৫.২)।

পরীক্ষার keyword: “lowest latency”, “global users”, “millisecond / microsecond response”, “read-heavy”, “high throughput”, “the right instance type”, “improve performance”।

উদাহরণ: Mumbai-তে host করা একটা বাংলাদেশি e-learning site-এ Malaysia আর মধ্যপ্রাচ্যের ছাত্রছাত্রী যোগ হয়েছে; পুরো platform সরানোর বদলে CloudFront তাদের কাছের edge location থেকে video পাঠায়।

#Cost optimization

লক্ষ্য: সবচেয়ে কম দামে business value দেয় এমন system চালানো।

Design principle (পাঁচটাই):

• Cloud financial management চালু করো: security-র মতো খরচেরও একজন মালিক, একটা প্রক্রিয়া আর tool থাকুক।
• Consumption model নাও: যা ব্যবহার করো তার দাম দাও; কাজের দিনে ৮ ঘণ্টা ব্যবহার হওয়া development environment বাকি সময় বন্ধ রাখলে প্রায় ৭৫% বাঁচে।
• সামগ্রিক দক্ষতা মাপো: business output-এর প্রতি একক খরচ (প্রতি order, প্রতি ছাত্র)।
• আলাদা কিছু যোগ করে না এমন ভারী কাজে টাকা ঢালা বন্ধ করো: নিজে server বসানো আর database patch করার বদলে managed service।
• খরচ বিশ্লেষণ করো আর কার খরচ ঠিক করো: tag আর report দেখায় কোন team বা product কত খরচ করছে।

এই course-এর service: purchasing option, Savings Plans আর Spot (৪.৪), S3 storage class আর lifecycle (১০.৫), Compute Optimizer দিয়ে right-sizing (৪.১), Cost Explorer, Budgets আর Cost Anomaly Detection (১.৪, ২৫.৪), Instance Scheduler (২৫.৫), networking-এর খরচ (২২.৮)।

পরীক্ষার keyword: “most cost-effective”, “lowest cost”, “reduce cost”, “idle”, “underutilised”, “pay only when used”, “infrequently accessed”, “interruptible workload”।

উদাহরণ: ঢাকার একটা software firm ৩০টা development instance ২৪ ঘণ্টা চালু রাখে, অথচ developer-রা কাজ করে সকাল ৯টা থেকে সন্ধ্যা ৬টা, রবি থেকে বৃহস্পতি। কাজের সময়ের বাইরে বন্ধ রাখলে bill-এর ওই অংশ প্রায় চার ভাগের তিন ভাগ কমে যায়।

#Sustainability

লক্ষ্য: প্রতিটা workload-এর যতটা energy আর resource লাগে তা কমানো, আর তাতে পরিবেশের ওপর প্রভাবও কমানো।

Design principle (AWS ছয়টা বলে):

• নিজের প্রভাব বোঝো আর sustainability-র লক্ষ্য ঠিক করো: মাপো, যেমন billing console-এর customer carbon footprint tool দিয়ে, আর প্রতি transaction বা প্রতি user ধরে লক্ষ্য বসাও।
• Utilisation সর্বোচ্চ করো: ৩০%-এ চলা দুটো host ৬০%-এ চলা একটার চেয়ে বেশি energy খায়; right-size করো আর অলস resource সরাও।
• নতুন, বেশি দক্ষ hardware আর software আগে থেকে ভাবো আর গ্রহণ করো: যেমন Graviton (Arm) processor।
• Managed service ব্যবহার করো: AWS-এর মাপে ভাগাভাগি করা infrastructure (Fargate, Lambda, S3 lifecycle, Auto Scaling)।
• Cloud workload-এর পরের ধাপের প্রভাব কমাও: হালকা app, যাতে user-কে নতুন phone কিনতে না হয়।

এই course-এর service: right-sizing আর Graviton instance (৪.১), Auto Scaling (৬.৫), serverless আর Fargate (১৫.১, ১৪.২), S3 lifecycle আর Intelligent-Tiering (১০.৫), Region বাছাই (কোন Region পুরোপুরি নবায়নযোগ্য বিদ্যুতের কাছাকাছি চলে, AWS তা প্রকাশ করে; তবে latency আর data-র নিয়ম আগে)।

পরীক্ষার keyword: “reduce carbon footprint”, “environmental impact”, “energy efficiency”, “minimise the resources provisioned”।

#দুটো pillar-এ দায়িত্বের ভাগ

দুটো pillar স্পষ্টভাবে AWS-এর সাথে কাজ ভাগ করে নেয়, লেসন ১.১-এর shared responsibility model মেনে:

• Security: AWS সুরক্ষা দেয় cloud-এর (facility, hardware, virtualisation স্তর); তুমি সুরক্ষা দাও cloud-এর ভেতরে যা রাখো তার (IAM, data, encryption setting, security group, তোমার instance-এর patch)।
• Sustainability: cloud-এর sustainability AWS-এর দায়িত্ব (দক্ষ ভাগাভাগি করা infrastructure, নবায়নযোগ্য বিদ্যুৎ, পানির সঠিক ব্যবহার); cloud-এর ভেতরের sustainability তোমার (right-sizing, utilisation, অদরকারি জিনিস মুছে ফেলা, দক্ষ service বাছা)।

#Synergy, তবে প্রশ্নই অগ্রাধিকার বলে দেয়

Slide বলছে pillar-গুলো “ভারসাম্য রাখার বা trade-off-এর জিনিস না, এরা একে অন্যকে সাহায্য করে”। প্রায়ই কথাটা সত্যি: right-sizing-এর সাথে Graviton একসাথে খরচ, performance আর sustainability ভালো করে; infrastructure as code একসাথে operation, security আর reliability-কে সাহায্য করে।

কিন্তু সৎ থাকো: বাস্তব design সত্যিই trade করে। Multi-site active/active DR সবচেয়ে ভালো reliability দেয়, আর bill প্রায় দ্বিগুণ করে। সবকিছু encrypt আর inspect করলে latency একটু বাড়ে। Framework নিজেই বলে, business-এর অগ্রাধিকার দেখে ভেবেচিন্তে বাছো।

পরীক্ষায় এটাই পুরো course-এর সবচেয়ে জরুরি অভ্যাস: প্রশ্নে অগ্রাধিকারের শব্দটা খুঁজে বের করো আর সেটা মানো। ৩০ মিনিট RTO সহ “most cost-effective” মানে pilot light, multi-site না। “Highest availability regardless of cost” মানে multi-site। “Least operational overhead” এমন সস্তা উপায়কে হারিয়ে দেয়, যেটা তোমাকে নিজে চালাতে হয়।

#AWS Well-Architected Tool

#এক workload-এর জন্য বিনা খরচের প্রশ্নমালা

AWS Well-Architected Tool হলো AWS console-এর একটা বিনা খরচের service, যেটা framework-এর প্রশ্নগুলোকে একটা workload-এর জন্য প্রশ্নমালা বানিয়ে দেয়। তুমি উত্তর দাও; সে উত্তরগুলো best practice-এর সাথে মিলিয়ে বলে দেয় ঝুঁকি কোথায়। সে নিজে কিছু deploy, scan বা বদল করে না।

#একটা review কীভাবে চলে

1. Workload define করো: নাম, বর্ণনা, environment (production বা pre-production), AWS Region (বা AWS-এর বাইরের জায়গা, যেমন on-premises data centre), একজন review owner, আর চাইলে account, architecture diagram-এর link আর industry।
2. Lens লাগাও: Well-Architected Framework lens সবসময় লাগানো থাকে; Lens Catalog থেকে বা তোমার custom lens থেকে আরও যোগ করো।
3. Pillar ধরে ধরে প্রশ্নের উত্তর দাও: প্রতিটা প্রশ্নে যে best practice সত্যিই মানো সেগুলোতে টিক দাও, যে প্রশ্ন বা বাছাই খাটে না সেটা চিহ্নিত করো, আর note লেখো। কাজটা workshop হিসেবে করো, যারা workload বানায় আর চালায় তাদের নিয়ে।
4. ঝুঁকি পড়ো: tool প্রতিটা প্রশ্নকে দাগ দেয় high risk issue (HRI: এমন সিদ্ধান্ত, যা AWS-এর অভিজ্ঞতায় business-এর বড় ক্ষতি করতে পারে) বা medium risk issue (MRI: ক্ষতি তুলনায় কম) হিসেবে, অথবা ঝুঁকি নেই।
5. Improvement plan কাজে লাগাও: ঝুঁকিওয়ালা প্রশ্নগুলো, তোমার pillar অগ্রাধিকার অনুযায়ী সাজানো, HRI আগে, প্রতিটার সাথে best practice, নির্দেশনা আর video-র link।
6. Milestone save করো: ওই মুহূর্তের review-এর একটা জমাট কপি (“Before Eid review”)। ঠিক করার পরে উত্তর হালনাগাদ করে আরেকটা save করো; dashboard দুটো তুলনা করে।
7. Report আর share: PDF report বানাও, dashboard দেখো (আর অনেক workload জুড়ে একটা consolidated report), আর workload বা custom lens অন্য IAM user, account বা পুরো organization-এর সাথে share করো।

#Slide-এর পরে যোগ হওয়া feature

• Trusted Advisor integration (২০২২, ২০২৩-এ আরও ভালো): প্রশ্নের পাশেই সংশ্লিষ্ট Trusted Advisor check-এর ফল দেখা যায়, ফলে উত্তরের পাশে চালু account-এর প্রমাণ থাকে। Resource খুঁজে পাওয়া যায় AWS Service Catalog-এ register করা application বা tag দিয়ে; কোন check দেখবে, সেটা তবুও তোমার support plan-এর ওপর নির্ভর করে।
• Profile (জুন ২০২৩): তুমি business-এর প্রেক্ষাপট আর অগ্রাধিকার লিখে রাখো, আর tool সেগুলোর জন্য সবচেয়ে জরুরি প্রশ্ন আগে আনে।
• Review template (অক্টোবর ২০২৩): একই রকম অনেক workload-এর জন্য আগে থেকে ভরা উত্তর আর note, যেমন ভাগাভাগি করা landing zone-এর উত্তর, যেটা নইলে প্রতিটা team-কে আবার লিখতে হতো।
• Jira connector (এপ্রিল ২০২৪): improvement item Jira project-এ issue হয়ে যায়, আর তাদের অবস্থা আবার ফিরে আসে।
• API আর CLI (aws wellarchitected …): script থেকে workload বানানো, ঝুঁকির সংখ্যা আর improvement item পড়া, milestone বানানো।

#AWS Trusted Advisor

#Account-এর নিজে নিজে চলা check-up

AWS Trusted Advisor হলো তোমার পুরো account-এর নিজে নিজে চলা check-up। কিছুই install করতে হয় না: সে একটা service-linked role দিয়ে তোমার resource-এর configuration আর ব্যবহার পড়ে, AWS-এর নিজের best-practice check-এর তালিকা চালায়, তারপর কী করতে হবে সুপারিশ করে। Well-Architected Tool যেখানে তোমাকে প্রশ্ন করে, Trusted Advisor সেখানে নিজেই খুঁজে দেখে।

#ছয়টা category

Notes-এ পাঁচটা category আছে। আসলে আছে ছয়টা: slide-এ ষষ্ঠটা আগেই দেখানো।

1. Cost optimization: অব্যবহৃত বা কম ব্যবহৃত resource আর টাকা বাঁচানোর সুযোগ।
2. Performance: গতি আর সাড়া দেওয়ার ক্ষমতা।
3. Security: যেসব setting account-কে উন্মুক্ত রাখে।
4. Fault tolerance: redundancy আর resiliency-র ফাঁক।
5. Service limits: কোনো quota-র কাছাকাছি বা তার বেশি ব্যবহার।
6. Operational excellence: বড় মাপে environment দক্ষভাবে চালানো (যেমন logging বন্ধ থাকা)।

#উদাহরণ check

অনেক check এখন অন্য service থেকে আসে: কিছু চলে AWS Config rule বা Security Hub CSPM control দিয়ে, আর opt in করলে cost check-এ Compute Optimizer-এর right-sizing ফল দেখা যায়।

#Status-এর রং, refresh আর notification

• লাল: action recommended। হলুদ: investigation recommended। সবুজ: কোনো সমস্যা পাওয়া যায়নি। ধূসর গোনে সেসব check, যেখানে তুমি কিছু item বাদ দিতে বলেছ।
• সব check আছে এমন plan-এ Trusted Advisor প্রতি সপ্তাহে নিজে থেকে check refresh করে; চাইলে যেকোনো check তখনই refresh করতে পারো। Basic Support-এ security check হাতে refresh করতে হয়।
• একটা সাপ্তাহিক email তোমার বাছাই করা মানুষদের কাছে ফলাফলের সারাংশ পাঠায়।
• Check-এর অবস্থা বদলালে খবর যায় Amazon EventBridge-এ, যেখানে একটা rule SNS-কে জানাতে বা Lambda চালাতে পারে (লেসন ১৯.৫)।
• Programmatic access: Trusted Advisor API (aws trustedadvisor …, ২০২৩) বা AWS Support API-র পুরোনো Trusted Advisor operation (aws support describe-trusted-advisor-checks, us-east-1 endpoint)। দুটোর জন্যই সব check আছে এমন পয়সার plan লাগে।
• Organizational view: একটা AWS Organization-এর management account সব member account জুড়ে একটা report বানাতে পারে।
• Trusted Advisor Priority: Enterprise Support আর Unified Operations customer-দের জন্য AWS account team অগ্রাধিকার দিয়ে সাজানো সুপারিশ যোগ করে (Trusted Advisor, Security Hub, Well-Architected আর নিজেদের বিশ্লেষণ থেকে), আর পুরো organization জুড়ে সমাধান পর্যন্ত সেগুলো track করে।

#তোমার support plan কী খুলে দেয়

#Well-Architected Tool বনাম Trusted Advisor বনাম প্রতিবেশীরা

Notes এই গোলমালকে পরীক্ষার জন্য “খুব গুরুত্বপূর্ণ” বলেছে। মূল পার্থক্য এক লাইনে: Well-Architected Tool-এ তুমি একটা workload নিয়ে প্রশ্নের উত্তর দাও; Trusted Advisor নিজে নিজে account scan করে।

আর বাকি দেখতে-একই-রকমগুলো:

#AWS Health Dashboard

AWS Health Dashboard দেখায় AWS নিজের এমন ঘটনা, যা তোমার ওপর প্রভাব ফেলতে পারে। এর দুটো view:

• Service health: প্রতিটা Region-এ প্রতিটা AWS service-এর সবার জন্য খোলা অবস্থা (sign in লাগে না)। এই মুহূর্তে ap-southeast-1-এ EC2-এর কোনো সমস্যা আছে কি?
• Your account health: তোমার resource-এর ঘটনা: তোমার EC2 instance-এর নিচের hardware-এর পরিকল্পিত maintenance বা অবসর, একটা RDS engine version-এর support শেষ হওয়া, যে AZ-এ তোমার instance চলে সেখানে সমস্যা, certificate বা key-এর ঘটনা। এই view-এর নাম একসময় ছিল Personal Health Dashboard; ২০২২ থেকে দুটো view-ই AWS Health Dashboard-এর ভেতরে, আর পুরোনো প্রশ্নে এখনো পুরোনো নাম আসতে পারে।

প্রতিটা account বিনা খরচে dashboard পায়, আর প্রতিটা account Amazon EventBridge-এ AWS Health event পায়, ফলে maintenance ঠিক হলেই একটা rule ticket খুলতে বা automation চালাতে পারে (লেসন ১৯.৫)। AWS Health API (তোমার নিজের tool-এর জন্য) লাগে Business Support+, Enterprise Support বা Unified Operations (বা পুরোনো Business আর Enterprise plan)। AWS Organizations থাকলে একটা organizational view প্রতিটা member account-এর Health event এক জায়গায় আনে।

#Reference architecture: সাদা পাতা থেকে শুরু কোরো না

আসল project-এ (একটা e-commerce site, একটা gaming backend, একটা data lake) design নতুন করে আবিষ্কার করার দরকার কমই পড়ে। AWS প্রমাণিত design প্রকাশ করে:

• AWS Architecture Center (aws.amazon.com/architecture): reference architecture diagram, pattern, whitepaper আর guide, প্রযুক্তি আর industry ধরে সাজানো। Slide-এর দুটো পরিবারই সেখানে: classic (EC2, ELB, RDS, ElastiCache) আর serverless (S3, Lambda, DynamoDB, CloudFront, API Gateway), অধ্যায় ৯ আর ১৫-এ তুমি ঠিক এগুলোই বানিয়েছ।
• AWS Solutions Library (aws.amazon.com/solutions): যাচাই করা solution, যা তুমি deploy করতে পারো, অনেকগুলো AWS-এর বানানো, সাথে একটা CloudFormation template আর implementation guide। Instance Scheduler on AWS (লেসন ২৫.৫) এদেরই একটা।
• AWS Prescriptive Guidance (পাশের কথা): migration আর আধুনিকীকরণের জন্য ধাপে ধাপে কৌশল, guide আর pattern।

#এক table-এ Disaster Recovery whitepaper

Slide-এর section overview শেষ হয় Disaster Recovery of Workloads on AWS whitepaper দিয়ে, Reliability pillar-এর সঙ্গী। তুমি এটা গভীরে পড়েছ লেসন ২৩.১-এ (RPO, RTO, চারটা কৌশল) আর লেসন ২৩.২-এ (Elastic Disaster Recovery, AWS Backup)। ঝালিয়ে নাও:

• RTO (recovery time objective): বিপর্যয়ের পরে system কতক্ষণ বন্ধ থাকতে পারে, যেমন ২ ঘণ্টা।
• RPO (recovery point objective): সময় দিয়ে মাপা কতটা data হারানো চলবে, যেমন শেষ ১ ঘণ্টার write।

কৌশল যত সস্তা, recovery তত লম্বা। ২৩.১-এর পদ্ধতি: RTO আর RPO বের করো, যেটা বেশি কড়া সেটা ধরো, তারপর দুটোই পূরণ করে এমন সবচেয়ে সস্তা কৌশল বাছো।

#কোন pillar? কোন tool?

এই লেসনের দুটো অভ্যাসই ঝালাও: requirement-কে ঠিক pillar-এ বসানো, আর প্রশ্নকে ঠিক tool-এর কাছে পাঠানো।

#কী ভুল হয়

#System design-এ Well-Architected

• একটা ছন্দ, অনুষ্ঠান না। একটা workload review করো launch-এর আগে, বড় চাপের সময়ের আগে (ঈদ, ১১.১১, ভর্তির মৌসুম), বড় বদলের পরে আর বড় incident-এর পরে। প্রতিবার একটা milestone save করো।
• আটকাও, ধরো, review করো। SCP, IAM আর service setting আটকায় (লেসন ২০.১); Config আর Security Hub অবিরাম ধরে; Trusted Advisor সাপ্তাহিক best-practice ছবি দেয়; Well-Architected review দেখে design আর প্রক্রিয়া, যা কোনো scanner দেখে না।
• বড় মাপে ভাগাভাগি করা উত্তর। অনেক account-এর organization-এ review template রাখে landing zone-এর সাধারণ উত্তর, একটা custom lens রাখে company-র standard, আর share করা workload দিয়ে একটা কেন্দ্রীয় architecture team প্রতিটা team-এর ঝুঁকি দেখতে পায়।
• Requirement দেখে সিদ্ধান্ত। এই course-এর প্রতিটা architecture-এর উত্তর ছিল pillar-এর একটা trade-off। Service বাছার আগে অগ্রাধিকারটা বলো (availability-র লক্ষ্য, budget, latency, carbon-এর লক্ষ্য); পরীক্ষার প্রতিটা প্রশ্নও এভাবেই পড়তে হয় (লেসন ২৬.২)।
• মহড়া দাও। Game day আর DR drill diagram-কে প্রমাণে বদলে দেয়।

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

Well-Architected Tool-এ একটা workload বানাও, তার ঝুঁকি পড়ো, একটা milestone save করো, আর Trusted Advisor ও AWS Health-কে query করো। Output ছোট করা; ID আর সংখ্যা উদাহরণ। Well-Architected Tool বিনা খরচের; Trusted Advisor, Support আর Health API call-এর জন্য Business Support+ বা ওপরে লাগে (Basic-এ এগুলো subscription error ফেরত দেয়)।

1. ১. একটা workload define করো

   aws wellarchitected create-workload \
     --workload-name wallet-payments \
     --description "Payments API before the Eid peak" \
     --environment PRODUCTION \
     --aws-regions ap-southeast-1 ap-south-1 \
     --review-owner architect@example.com \
     --lenses wellarchitected serverless
   

   { "WorkloadId": "0123456789abcdef0123456789abcdef",
     "WorkloadArn": "arn:aws:wellarchitected:ap-southeast-1:111122223333:workload/0123456789abcdef0123456789abcdef" }
   

   --description, --environment, --lenses আর --aws-regions বা --non-aws-regions-এর একটা লাগবেই; API একজন review owner-ও চায়। এবার console-এ workload খুলে team নিয়ে প্রশ্নের উত্তর দাও।

2. ২. ঝুঁকির সংখ্যা আর improvement plan পড়ো

   aws wellarchitected get-lens-review --workload-id 0123456789abcdef0123456789abcdef \
     --lens-alias wellarchitected --query 'LensReview.RiskCounts'
   
   aws wellarchitected list-lens-review-improvements \
     --workload-id 0123456789abcdef0123456789abcdef --lens-alias wellarchitected \
     --pillar-id reliability \
     --query 'ImprovementSummaries[].{q:QuestionTitle,risk:Risk}'
   

   { "HIGH": 9, "MEDIUM": 14, "NONE": 31, "NOT_APPLICABLE": 2, "UNANSWERED": 1 }
   [ { "q": "How do you back up data?", "risk": "HIGH" },
     { "q": "How do you test reliability?", "risk": "HIGH" },
     { "q": "How do you design your workload to withstand component failures?", "risk": "MEDIUM" } ]
   

3. ৩. Milestone save করো, ঠিক করো, তুলনা করো

   aws wellarchitected create-milestone --workload-id 0123456789abcdef0123456789abcdef \
     --milestone-name "Before Eid review"
   
   # after the fixes and updated answers
   aws wellarchitected create-milestone --workload-id 0123456789abcdef0123456789abcdef \
     --milestone-name "Eid ready"
   aws wellarchitected list-milestones --workload-id 0123456789abcdef0123456789abcdef \
     --query 'MilestoneSummaries[].{n:MilestoneName,risk:WorkloadSummary.RiskCounts.HIGH}'
   

   [ { "n": "Eid ready", "risk": 3 }, { "n": "Before Eid review", "risk": 9 } ]
   

4. ৪. Trusted Advisor-এর সুপারিশ তালিকা (Business Support+ বা ওপরে)

   aws trustedadvisor list-recommendations --status error --region us-east-1 \
     --query 'recommendationSummaries[].{name:name,pillars:pillars,status:status}'
   
   # the older Support API, us-east-1 only
   aws support describe-trusted-advisor-checks --language en --region us-east-1 \
     --query 'checks[?category==`cost_optimizing`].name' | head
   

   [ { "name": "Amazon S3 Bucket Permissions", "pillars": ["security"], "status": "error" } ]
   [ "Low Utilization Amazon EC2 Instances", "Unassociated Elastic IP Addresses",
     "Idle Load Balancers", "Underutilized Amazon EBS Volumes", ... ]
   

   Basic Support-এ এই call-গুলো subscription error দিয়ে fail করে: plan-এর পার্থক্যটা হাতেকলমে এটাই।

5. ৫. Check লাল হলে খবর পাও

   aws events put-rule --region us-east-1 --name ta-red-security --event-pattern '{
     "source": ["aws.trustedadvisor"],
     "detail-type": ["Trusted Advisor Check Item Refresh Notification"],
     "detail": { "status": ["ERROR"] } }'
   
   aws events put-targets --region us-east-1 --rule ta-red-security \
     --targets Id=sec,Arn=arn:aws:sns:us-east-1:111122223333:security-alerts
   

   Trusted Advisor এই event-গুলো পাঠায় us-east-1-এ।

6. ৬. AWS Health event দেখো

   aws health describe-events --region us-east-1 \
     --filter eventStatusCodes=open,upcoming \
     --query 'events[].{svc:service,type:eventTypeCode,region:region,start:startTime}'
   

   [ { "svc": "EC2", "type": "AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED",
       "region": "ap-southeast-1", "start": "2026-11-12T03:00:00+06:00" } ]
   

   Dashboard আর EventBridge event প্রতিটা account-এর জন্য বিনা খরচে; API-র জন্য Business Support+ বা ওপরে লাগে।

7. ৭. পরিষ্কার করো

   aws events remove-targets --region us-east-1 --rule ta-red-security --ids sec
   aws events delete-rule --region us-east-1 --name ta-red-security
   aws wellarchitected delete-workload --workload-id 0123456789abcdef0123456789abcdef
   

#সারসংক্ষেপ

মূল কথা

• Well-Architected Framework হলো AWS-এর লেখা best practice (design principle, ছয়টা pillar, প্রশ্ন, best practice, lens), কোনো service না। “Cloud architecture-এর best practice কোথায় পাবো?” → framework। কখনো একে “WAF” বলবে না: ওটা AWS WAF।
• General design principle: capacity আন্দাজ করা বন্ধ করো, production scale-এ test করো, পরীক্ষা-নিরীক্ষা মাথায় রেখে automate করো, বিবর্তনশীল architecture-এর কথা ভাবো, ডেটা দেখে architecture চালাও, game day দিয়ে উন্নতি করো (flash sale-এর মহড়া, ইচ্ছা করে একটা AZ বন্ধ, Fault Injection Service)।
• ছয়টা pillar আর তাদের keyword: Operational excellence (automate, IaC, observe, ছোট ফেরানো যায় এমন change, least overhead), Security (identity, traceability, সব স্তর, data at rest আর in transit), Reliability (নিজে নিজে ফেরা, recovery test, horizontally scale, Multi-AZ, DR), Performance efficiency (global হও, serverless, ঠিক resource, mechanical sympathy), Cost optimization (consumption model, right-size, Savings Plans, Spot, storage class), Sustainability (carbon footprint, utilisation সর্বোচ্চ, Graviton, managed service)। Security আর Sustainability দুটোতেই “cloud-এর / cloud-এর ভেতরে” ভাগ আছে।
• Pillar-গুলো প্রায়ই একে অন্যকে সাহায্য করে, কিন্তু বাস্তব design trade করে; প্রশ্ন যে অগ্রাধিকারের কথা বলে, সেটা মানো (“most cost-effective” বনাম “highest availability regardless of cost”)।
• Well-Architected Tool: একটা workload-এর জন্য বিনা খরচের প্রশ্নমালা; lens (Lens Catalog, custom), HRI আর MRI, improvement plan, milestone, profile, review template, sharing, report, Trusted Advisor আর Jira integration। তুমি যা উত্তর দাও, সে শুধু সেটাই জানে।
• Trusted Advisor: নিজে নিজে account scan, কিছু install করতে হয় না, ছয়টা category (cost, performance, security, fault tolerance, service limits, operational excellence; notes-এর পাঁচটা পুরোনো)। লাল / হলুদ / সবুজ। Basic আর Developer: শুধু মূল security check আর service limit; Business Support+ আর ওপরে: সব check, API, EventBridge, সাপ্তাহিক refresh; Enterprise-এ Priority। Support plan বদলেছে ২০২৫–২৭-এ।
• পার্থক্য: Well-Architected Tool = তুমি একটা design নিয়ে উত্তর দাও; Trusted Advisor = AWS চালু resource scan করে; Config = প্রতিটা বদল তোমার rule দিয়ে; Compute Optimizer = right-sizing; Health Dashboard = তোমার ওপর প্রভাব ফেলা AWS-এর ঘটনা (সব account, EventBridge; API-র জন্য Business Support+)।
• Reference architecture: Architecture Center (diagram), Solutions Library (deploy করা যায়); Quick Starts হয়েছিল Partner Solutions (২০২৩), আর program-টা শেষ।
• DR whitepaper: RPO, RTO, backup and restore → pilot light → warm standby → multi-site; hot standby হলো active/passive; বিস্তারিত ২৩.১-এ।

নিজেকে যাচাই করো: Well-Architected আর Trusted Advisor৩০টি প্রশ্ন