AWS Well-Architected Framework
AWS Well-Architected Tool কী এবং কেন জানতে হবে?
Well-Architected Tool হলো AWS-এর দেওয়া একটা blueprint যেটা দিয়ে আপনি যেকোনো cloud architecture evaluate করতে পারবেন। মনে করুন আপনি একটা নতুন system design করছেন বা কোনো existing infrastructure review করছেন। তখন এই Tool আপনাকে বলবে কোন dimension-এ কোথায় gap আছে।
Production-এ এটা কাজে লাগে তিনভাবে: নতুন architecture design করার সময়, incident-এর পরে root cause বুঝতে, এবং cost review-এর সময়।
ছয়টি Pillar – ভেতরে কী এবং কেন এই ভাগ?
AWS Well-Architected Tool ছয়টি pillar-এ ভাগ করা কারণ একটা production system আসলে ছয়টি আলাদা dimension থেকে fail করতে পারে যেমন performance খারাপ হতে পারে, security breach হতে পারে, cost অনিয়ন্ত্রিত হতে পারে, বা system down হতে পারে। প্রতিটি pillar একটা আলাদা failure domain।
এবার প্রতিটি pillar বিস্তারিত দেখি।
Pillar 1 – Operational Excellence
প্রশ্ন: আমরা কি efficiently system চালাতে পারছি এবং সময়ের সাথে improve করতে পারছি?
এটা হলো day-to-day operations এর pillar। Runbook আছে কিনা, incident-এর পর post-mortem হচ্ছে কিনা, deploy করার সময় কোনো manual step আছে কিনা – সব এখানে।
Design Principles:
- Operations as code – CloudFormation, CDK দিয়ে সব automate করুন
- Small, reversible changes – বড় একটা deploy না করে ছোট ছোট করুন
- Anticipate failure – chaos engineering, game day exercises
- Learn from operational events – CloudTrail, CloudWatch Logs থেকে শিক্ষা নাও
ধরুন আপনার company-তে production-এ একটা EC2 instance চলছে। সেখানে একটা web application host করা আছে। রাত ১১টায় একজন junior engineer ভাবলো “এই instance-টা দেখতে অনেকটা test instance-এর মতো, terminate করে দেই।” সে terminate করে দিল। Production গেলো down হয়ে।
এখন প্রশ্ন হলো এটা কার failure?
Operational Excellence failure মানে কী এখানে?
Operational Excellence মানে হলো team জানে কীভাবে কাজ করতে হয়, কোনো action নেওয়ার আগে কী ভাবতে হয়, এবং সেই knowledge শুধু মাথায় না, লেখাও থাকে।
এই ঘটনায় যা ছিল না তাহলো Runbook।
Runbook হলো একটা step-by-step document যেটায় লেখা থাকে “EC2 instance terminate করার আগে এই ৫টা জিনিস check করো।”
EC2 Instance Termination Checklist
────────────────────────────────────
Step 1: Instance-এর Name tag দেখো - "prod" আছে কিনা
Step 2: Environment tag দেখো - Production নাকি Dev?
Step 3: Auto Scaling Group-এর part কিনা confirm করো
Step 4: আপনার team lead-কে Slack-এ notify করো
Step 5: তারপর terminate করো
এই document থাকলে junior engineer automatically Step 1-এ ধরা পড়তো। instance-এ Environment: Production tag দেখে থেমে যেতো।
Runbook না থাকা ছাড়াও আর কী কী ছিল না?
এই একটা incident-এ আসলে কয়েকটা Operational Excellence failure একসাথে:
১. Runbook নেই – কোনো standard procedure লেখা নেই।
২. Tagging strategy নেই বা enforce করা নেই – instance-এ proper tag থাকলে engineer নিজেই বুঝতো এটা production।
৩. Termination Protection enable ছিল না – AWS-এ EC2 instance-এ একটা setting আছে “Enable termination protection” – এটা on থাকলে accidentally terminate করা যায় না, আগে manually disable করতে হয়। এই extra friction-টা incident prevent করতো।
৪. Post-mortem culture নেই – incident-এর পর যদি team বসে “কেন হলো, কীভাবে prevent করবো” এটা না করে, তাহলে পরের মাসে আবার একই ঘটনা হবে।
সংক্ষেপে
Operational Excellence failure মানে হলো process এবং knowledge ছিল না, বা থাকলেও follow করা হয়নি। Security failure হলে বলতাম “তার permission থাকা উচিত ছিল না।” Operational Excellence failure বলছি কারণ “সে permission পেয়েই কাজ করেছে, কিন্তু কীভাবে করতে হয় সেটা কেউ জানতো না বা document করা ছিল না।”
Pillar 2 – Security
প্রশ্ন: আমাদের data কি protected? কে কীসে access করতে পারছে?
Design Principles:
- Strong identity foundation – least privilege, IAM roles, MFA সব জায়গায়
- Enable traceability – CloudTrail, Config দিয়ে সব log করুন
- Apply security at all layers – VPC, Security Group, Application layer সব স্তরে
- Protect data in transit and at rest – TLS, KMS encryption
- Keep people away from data – automation দিয়ে human access কমাও
SOA-C03 connection: এই exam-এ security সবচেয়ে বেশি scenario-based প্রশ্ন আসে। “কীভাবে least privilege দেবেন S3 bucket-এ” এই ধরনের।
Pillar 3 – Reliability
প্রশ্ন: system কি failure থেকে recover করতে পারে? workload কি consistently চলে?
Design Principles:
- Automatically recover from failure – Auto Scaling, Multi-AZ RDS
- Test recovery procedures – DR drill করো, backup restore test করো
- Scale horizontally – single point of failure এড়াও
- Stop guessing capacity – Auto Scaling দিয়ে demand-এর সাথে scale করো
- Manage change in automation – change management automated করো
উদাহরণ: একটা RDS instance যদি single-AZ-তে থাকে, সেটা Reliability pillar-এ fail করে। Multi-AZ enable করলেই automatic failover পাবেন।
Pillar 4 – Performance Efficiency
প্রশ্ন: আমরা কি computing resources efficiently use করছি?
Design Principles:
- Democratize advanced technologies – managed service ব্যবহার করুন, নিজে implement করার চেস্টা না করা (ElastiCache, OpenSearch)
- Go global in minutes – CloudFront, multi-region deployment
- Use serverless architectures – Lambda, Fargate দিয়ে server management কমান
- Experiment more often – A/B test করুন, different instance type try করুন
- Consider mechanical sympathy – workload-এর জন্য সঠিক technology বেছে নিন
CPU-intensive workload-এ compute-optimized instance (c-family) ব্যবহার করুন – general purpose (t-family) না।
Pillar 5 – Cost Optimization
প্রশ্ন: আমরা কি কম খরচে same বা better outcome পাচ্ছি?
Design Principles:
- Implement cloud financial management – FinOps practice করুন
- Adopt consumption model – যতটুকু use করুন ততটুকু pay করুন (Lambda, Fargate)
- Measure overall efficiency – business output per dollar measure করুন
- Stop spending money on undifferentiated heavy lifting – managed service ব্যবহার করুন
- Analyze and attribute expenditure – Cost Explorer, tagging strategy
Exam trap: “Most cost-effective” মানে সবসময় cheapest না। Spot instance সবচেয়ে সস্তা কিন্তু stateful workload-এ appropriate না।
Pillar 6 – Sustainability (2021 সালে add হয়েছে)
প্রশ্ন: আমাদের workload কি environment-এর উপর কম impact ফেলছে?
Design Principles:
- Understand your impact – carbon footprint measure করুন
- Establish sustainability goals – energy efficiency target সেট করুন
- Maximize utilization – idle resource রাখবেন না, right-sizing করুন
- Anticipate and adopt new hardware – newer, more efficient instance use করুন
- Use managed services – AWS নিজেই energy-efficient infrastructure maintain করে
SOA-C03 note: এই pillar থেকে সরাসরি খুব কম প্রশ্ন আসে, কিন্তু concept জানা দরকার।
AWS Well-Architected Tool – Console-এ কীভাবে ব্যবহার করবেন
AWS Console-এ একটা free tool আছে যেটা দিয়ে আপনি নিজের workload review করতে পারবেন।
- AWS Console → search করুন “Well-Architected Tool”
- Dashboard/Workloads → Define workload click করুন
- Workload name, description, Review owner (Email), environment (Production/Pre-production), AWS Regions দিন
- Next → Define workload confirm করুন
- Start review → 6টি pillar-এর question দেখাবে
- প্রতিটি question-এর answer দিন – tool automatically risk identify করবে (High / Medium)
- Improvement plan দেখুন – কোন area-তে কী করতে হবে সেটা বলবে
- Generate report → PDF export করুন
Production-এ যে ভুলগুলো সবাই করে
1. Tool জানে কিন্তু apply করে না। Interview-তে সুন্দর করে আমরা বলতে পারি, কিন্তু actual design-এ single point of failure রেখে দেয়। Pillar check করার জন্য Well-Architected Tool regularly use করুন।
2. Security আর Reliability কে একসাথে ভাবে। এগুলো আলাদা dimension। Multi-AZ RDS Reliability নিশ্চিত করে, কিন্তু যদি IAM policy overly permissive হয় তাহলে Security fail করছে।
3. Cost Optimization শুধু instance downsizing মনে করে। আসলে এটা architecture-level decision। on-demand এর বদলে Spot + On-Demand mix, S3 lifecycle policy, RDS Reserved Instance কেনা – সব মিলিয়ে।
4. Sustainability pillar ignore করে। New workload design-এ right-sizing এবং managed service prefer করলে automatically sustainable হয়।
5. Pillar tradeoff বোঝে না। কখনো কখনো একটা pillar improve করলে অন্যটা compromise হয় যেমন maximum reliability-র জন্য multi-region active-active করলে cost বাড়ে। এই tradeoff সচেতনভাবে নিতে হবে।
“Active-active” মানে হলো দুটো region একসাথে live traffic serve করছে। একটা active, অন্যটা standby না। এর বিপরীত হলো “active-passive” যেখানে একটা region primary, অন্যটা শুধু failover-এর জন্য।
SOA-C03-এ Well-Architected Tool কীভাবে আসে?
Exam-এ এই topic থেকে directly কম প্রশ্ন আসে, কিন্তু প্রতিটি scenario question-এর উত্তর দিতে হলে কোন pillar violate হচ্ছে সেটা বুঝতে হবে।
Sample Question 1:
একটা company-র production RDS database single Availability Zone-এ আছে। Database administrator দেখছেন যে hardware failure-এর ক্ষেত্রে manually intervention করতে হচ্ছে। এটা কোন Well-Architected pillar-এর বিরুদ্ধে এবং solution কী?
A) Security – IAM role enable করুন
B) Reliability – Multi-AZ enable করুন
C) Performance Efficiency – Read Replica যোগ করুন
D) Cost Optimization – Reserved Instance কিনুন
উত্তর: B – Manual intervention মানে automatic recovery নেই, এটা Reliability pillar। Multi-AZ enable করলে automatic failover হবে।
Trap: C দেখতে ভালো লাগতে পারে কারণ Read Replica performance improve করে, কিন্তু এটা failover solution না।
Sample Question 2:
একটা team দেখছে যে তাদের application-এ সব developer সব S3 bucket-এ full access পাচ্ছে। এটা কোন pillar-এর violation?
A) Reliability
B) Cost Optimization
C) Security
D) Operational Excellence
উত্তর: C – Least privilege না থাকা Security pillar-এর সরাসরি violation।
আজকের সারাংশ ও আগামীকালের প্রস্তুতি
Well-Architected Tool মূলত একটা checklist যেটা দিয়ে আপনি যেকোনো AWS architecture-কে ছয়টি dimension-এ evaluate করতে পারবেন যেমন Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, এবং Sustainability। Production-এ এর সবচেয়ে বড় value হলো tradeoff সচেতনভাবে নেওয়া।
Next Day: CloudOps Engineer role – SRE vs DevOps vs CloudOps, Operational Readiness, এবং Runbook। এটা পড়ার কারণ হলো আপনি যে role-এ কাজ করবেন সেটার responsibility কোথায় শেষ হয় এবং কোথায় শুরু হয় – সেটা না জানলে production-এ scope creep এবং blame game হয়। Plus এই concept দিয়ে Phase 1-এর foundation শেষ হবে, তারপর সরাসরি Project 01-এ যাবেন।