AWS Config, আর CloudWatch বনাম CloudTrail বনাম Config

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

• AWS Config কী, বুঝিয়ে বলতে (তোমার resource-এর configuration-এর জন্য একটা time machine, সাথে একজন compliance পরীক্ষক), এটা কোন কোন প্রশ্নের উত্তর দেয়, আর কেন এটা regional এবং কেন এর configuration recorder চালু থাকতেই হবে।
• Config কীভাবে রেকর্ড করে, বলতে: recorder আর তার recording strategy, continuous না daily recording, global resource type, S3 আর SNS-এ যাওয়া delivery channel, configuration item, history, resource timeline, relationship আর snapshot।
• Config rule ব্যবহার করতে: managed rule আর custom rule (Lambda বা Guard), change-triggered, periodic (১, ৩, ৬, ১২ বা ২৪ ঘণ্টা) আর hybrid trigger, evaluation-এর ফল, proactive mode; আর ব্যাখ্যা করতে যে Config কেন শুধু ধরে, কখনো আটকায় না।
• SSM Automation document দিয়ে remediation সাজাতে, manual বা automatic, retry আর remediation exception সহ; আর notification পেতে EventBridge (compliance বদল) বা SNS (সবকিছু) দিয়ে।
• Aggregator, organization rule আর conformance pack দিয়ে পুরো organization-এ Config ছড়িয়ে দিতে, আর configuration item আর rule evaluation ধরে এর খরচ আন্দাজ করতে।
• CloudWatch, CloudTrail আর Config আলাদা করে চিনতে (সাথে EventBridge, যে সাড়া দেয়): তিনটা lens, জোড়ায় জোড়ায় তুলনা, load balancer-এর উদাহরণ আর master cheat sheet; আর পাশে AWS Health Dashboard, Trusted Advisor, GuardDuty, Security Hub আর Audit Manager-কে ঠিক জায়গায় বসাতে।

#AWS Config কেন: একটা time machine আর একজন compliance পরীক্ষক

লেসন ১৯.১ থেকে ১৯.৬-এ আমরা একটা AWS account-এর ওপর নজর রাখার তিনটা উপায় দেখেছি। CloudWatch মাপে system কেমন চলছে, আর তার log জড়ো করে। CloudTrail রেকর্ড রাখে কে কোন API call করল। EventBridge কিছু ঘটলে সাড়া দেয়। একটা প্রশ্ন তবু বাকি থেকে যায়: আমার resource-গুলো আসলে কোন মুহূর্তে দেখতে কেমন ছিল, আর আমাদের নিয়ম যেমন বলে, সেভাবেই কি configure করা ছিল? এর উত্তরই AWS Config।

AWS Config দুটো কাজ করে:

1. সময়ের সাথে configuration রেকর্ড রাখে। প্রতিটা supported resource-এর (security group, EC2 instance, EBS volume, S3 bucket, IAM role, load balancer, আরও কয়েকশো ধরনের) প্রতিটা মুহূর্তের configuration আর তারপরের প্রতিটা বদল এটা জমিয়ে রাখে। তুমি জিজ্ঞেস করতে পারো: গত সোমবার সকাল ১০টায় এই security group কী কী allow করত? এই bucket-এ encryption কবে বন্ধ হয়েছিল? Owner-এর notes এটাকে বলেছে resource-এর time machine।
2. Compliance যাচাই করে। Config rule প্রতিটা resource-কে মিলিয়ে দেখে, যেমন থাকার কথা তেমন আছে কি না (“প্রতিটা EBS volume encrypted”, “কোনো security group internet থেকে SSH-এর জন্য খোলা না”), আর সেটাকে compliant বা non-compliant বলে দাগ দেয়, এখন এবং সময়ের সাথে। Non-compliant resource remediation দিয়ে ঠিকও করা যায়।

Slide-এর ঢঙে Config যেসব প্রশ্নের উত্তর দেয়:

• আমার কোনো security group-এ কি অবাধ SSH access আছে?
• আমার কোনো bucket কি public access দেয়?
• গত এক মাসে আমার load balancer-এর configuration কীভাবে বদলেছে?
• Auditor যেমন জানতে চান, সারা বছর কি প্রতিটা EBS volume encrypted ছিল?

#Config কীভাবে রেকর্ড করে

#Configuration recorder

Configuration recorder না চলা পর্যন্ত Config কিছুই করে না। Recorder টের পায় কখন একটা resource তৈরি হলো, বদলাল বা মুছে গেল, আর সেটা রেকর্ড করে। যেগুলো জানা জরুরি:

• Config regional। প্রতিটা account-এর প্রতিটা Region-এর আলাদা recorder, আলাদা rule, আলাদা console view। Singapore-এ Config চালু করলে Mumbai সম্পর্কে কিছুই জানা যায় না। অনেক account আর অনেক Region একসাথে দেখতে লাগে একটা aggregator (এই লেসনেই পরে আসছে)।
• Recording strategy। সব supported resource type রেকর্ড করো (console-এ default, AWS পরে যেসব type যোগ করবে সেগুলোসহ), অথবা কিছু type বাদ দিয়ে বাকি সব (যেমন অল্প সময় বাঁচে এমন resource, যারা অনেক item বানায়), অথবা শুধু তালিকা ধরে নির্দিষ্ট type।
• Recording frequency (২০২৩)। Continuous প্রতিটা বদল ঘটামাত্র রেকর্ড করে। Daily প্রতিটা resource-এর জন্য দিনে বড়জোর একটা item রাখে, তাও শুধু বদলালে; সস্তা, কিন্তু মাঝের ধাপগুলো আর প্রায় সাথে সাথে চলা trigger হারিয়ে যায়। Security আর compliance-এর জন্য সাধারণত continuous লাগে।
• Global resource type। IAM user, group, role আর customer managed policy কোনো Region-এ বাঁধা না। এগুলো শুধু একটা Region-এ রেকর্ড করো, নইলে প্রতিটা Region একই জিনিসের duplicate item বানাবে আর duplicate evaluation চালাবে। নতুন global type (Route 53 hosted zone, CloudFront distribution, WAF web ACL এবং আরও কিছু) শুধু তাদের home Region-এ রেকর্ড হয়, বেশিরভাগই us-east-1।
• Permission। Recorder তোমার resource পড়ার জন্য service-linked role AWSServiceRoleForConfig ব্যবহার করে।

#Delivery channel

Delivery channel ঠিক করে Config তার data কোথায় পাঠাবে:

• একটা S3 bucket (বাধ্যতামূলক), যেখানে আসে configuration history file (মোটামুটি প্রতি ৬ ঘণ্টায়, যে resource type বদলেছে তার জন্য) আর configuration snapshot (রেকর্ড করা প্রতিটা resource-এর অবস্থা, চাইলে তখনই, নয়তো প্রতি ১, ৩, ৬, ১২ বা ২৪ ঘণ্টায়)। S3-এ যতদিন খুশি data রাখা যায় (S3 Lifecycle, লেসন ১০.৫), আর slide যেমন বলে, Athena দিয়ে query করা যায় (লেসন ১৭.১)।
• একটা SNS topic (ইচ্ছামতো), যেখানে প্রতিটা configuration বদল আর compliance বদলের notification যায়। Notification নিয়ে নিচে বলছি।

Config নিজের ভেতরে history রাখে default-এ ৭ বছর; retention ৩০ দিন থেকে ৭ বছরের মধ্যে ঠিক করা যায়। কোনো hospital-কে এর বেশি সময় ধরে নিজের setup প্রমাণ করতে হলে S3-এর file-গুলো lifecycle rule দিয়ে রেখে দেয়।

#Configuration item

Configuration item হলো এক মুহূর্তে একটা resource-এর রেকর্ড: notes-এর ভাষায়, resource-এর configuration-এর একটা point-in-time snapshot। এতে থাকে:

• Metadata: resource type, resource ID আর ARN, Region, account, কখন ধরা হলো, status আর একটা version।
• Configuration: resource-এর describe API যা ফেরত দেয়, সেই setting-গুলো (security group হলে প্রতিটা inbound আর outbound rule; volume হলে size, type, encryption আর key)।
• Relationship: এটা কার সাথে জোড়া (এই security group ওই network interface-এ লাগানো, ওই VPC-র ভেতরে)।
• Tag, আর যে API call-গুলো বদলটা ঘটাল তাদের CloudTrail event ID।

প্রতিটা বদলে নতুন একটা configuration item তৈরি হয়, যাতে থাকে পুরো configuration, শুধু পার্থক্যটুকু না। একটা resource-এর item-গুলোর ধারাবাহিক তালিকাই তার configuration history।

#History, timeline, relationship আর snapshot

Console-এ প্রতিটা resource-এর একটা resource timeline আছে: সময় ধরে সাজানো তার configuration item-গুলো, প্রতিটা rule-এর compliance ফল সময়ের সাথে, আর প্রতিটা বদলের পাশে সংশ্লিষ্ট CloudTrail event। Slide-এর “Config resource” page এটাই: একটা resource-এর সময়ের সাথে compliance, সময়ের সাথে configuration, সময়ের সাথে CloudTrail API call। অনেক resource একসাথে দেখতে advanced query দিয়ে বর্তমান configuration-এর ওপর SQL-এর মতো SELECT লেখা যায় (“যেসব EBS volume gp3 না”), এমনকি aggregator দিয়ে অনেক account জুড়েও।

Relationship উত্তর দেয় “বদলটা কতদূর ছড়াবে” প্রশ্নের: কোনো security group মুছে ফেলা বা বদলানোর আগে Config দেখায় কে সেটা ব্যবহার করছে। আর snapshot একজন auditor-কে একটা নির্দিষ্ট মুহূর্তে পুরো account-এর অবস্থা তুলে দেয়।

#Config rule

#Managed rule আর custom rule

Config rule বলে দেয় তুমি কোন configuration চাও, আর সেই হিসাবে resource যাচাই করে। প্রতিটা evaluation প্রতিটা resource-এর জন্য একটা ফল দেয়: COMPLIANT, NON_COMPLIANT, বা NOT_APPLICABLE (resource-টা rule-এর যুক্তির বাইরে, যেমন শুধু ALB-এর জন্য বানানো যাচাইয়ে একটা network load balancer)। Rule-এর scope-এর মধ্যে একটা resource-ও non-compliant হলে পুরো rule non-compliant।

• AWS managed rule AWS নিজে লেখে আর রক্ষণাবেক্ষণ করে; তুমি শুধু যোগ করো আর parameter বসাও। Slide বলে “৭৫টার বেশি”: এখন আছে ৮০০-র বেশি। Notes যেগুলোর নাম বলেছে: s3-bucket-ssl-requests-only (bucket policy-তে সাধারণ HTTP deny করা থাকতে হবে), restricted-ssh (কোনো security group 0.0.0.0/0 থেকে port 22 allow করবে না), iam-password-policy (account-এর password policy তোমার parameter মানে কি না)। আরও কয়েকটা জানা ভালো: encrypted-volumes, s3-bucket-public-read-prohibited, required-tags, access-keys-rotated, desired-instance-type, approved-amis-by-id, cloudtrail-enabled, elb-acm-certificate-required।
• Custom rule তোমার নিজের যুক্তির জন্য, দুইভাবে লেখা যায় (slide-এর “Lambda-তেই লিখতে হবে” কথাটা পুরোনো):
  • Custom Lambda rule: Config তোমার Lambda function চালায়, সাথে দেয় configuration item; function সিদ্ধান্ত নিয়ে ফলটা Config-কে জানায়। যাচাইয়ে code বা বাড়তি API call লাগলে এটা।
  • Custom policy rule, Guard-এ লেখা, মানে AWS CloudFormation Guard-এর policy ভাষায়: কয়েক লাইনে বলে দাও কোন property-র মান কী হতে হবে, রক্ষণাবেক্ষণের জন্য কোনো Lambda function নেই।

Slide-এর custom rule-এর উদাহরণগুলো (“প্রতিটা EBS disk gp2 কি না”, “প্রতিটা EC2 instance t2.micro কি না”) ধারণাটা বোঝায়; আজ instance type-এর জন্য managed rule-ই আছে (desired-instance-type), আর এখনকার কোনো team gp2 না, gp3 চাইবে।

#Rule কখন চলে: trigger

• Configuration change: rule-এর scope-এর (resource type, একটা resource ID, বা একটা tag key আর value) কোনো resource বদলালেই rule চলে। Public bucket বা খোলা port কয়েক মিনিটের মধ্যে ধরা পড়ে এভাবেই।
• Periodic: তোমার বেছে নেওয়া সময় পরপর rule চলে: প্রতি ১, ৩, ৬, ১২ বা ২৪ ঘণ্টায় (default ২৪)। Account-level যাচাইয়ের জন্য, যেটা কোনো একটা resource বদলানোর সাথে বাঁধা না, যেমন iam-password-policy বা cloudtrail-enabled।
• Hybrid: কিছু rule-এর দুই ধরনের trigger-ই থাকে।

চাইলে যেকোনো rule তখনই চালানো যায় (start-config-rules-evaluation)।

#ধরে, কিন্তু আটকায় না

#Remediation: rule যা খুঁজে পায়, তা ঠিক করা

#SSM Automation document

Remediation মানে non-compliant resource ঠিক করা। Config এটা করে AWS Systems Manager Automation document (runbook) দিয়ে (Systems Manager হলো লেসন ২৫.৩):

• AWS-managed document চেনা সমস্যাগুলোর সমাধান দেয়: AWS-DisableS3BucketPublicReadWrite (bucket-এ Block Public Access চালু করে), AWS-DisableIncomingSSHOnPort22, AWSConfigRemediation-RevokeUnusedIAMUserCredentials, AWSConfigRemediation-EnableEbsEncryptionByDefault এবং আরও অনেক।
• Custom document যা খুশি করতে পারে, managed-গুলোতে যে যুক্তি নেই তার জন্য Lambda function চালানো পর্যন্ত।
• Parameter আসে rule থেকে, সাধারণত non-compliant resource-এর ID (bucket-এর নাম, security group-এর ID), সাথে একটা automation role (AutomationAssumeRole), যেটা runbook-কে resource বদলানোর permission দেয়।

দুটো mode:

• Manual: console-এ “Remediate” বোতাম থাকে; একজন মানুষ ভেবে দেখে click করে। ঝুঁকির সমাধানে এটাই নিরাপদ।
• Automatic: resource non-compliant হওয়ামাত্র Config document চালায়। সাথে retry: default-এ ৬০ সেকেন্ডের মধ্যে ৫ বার পর্যন্ত চেষ্টা (MaximumAutomaticAttempts ১ থেকে ২৫, RetryAttemptSeconds হলো সময়ের window)। সবগুলো চেষ্টা fail করলে Config ওই resource-এর জন্য একটা remediation exception বসিয়ে থেমে যায়, যাতে ভাঙা একটা সমাধান অনন্তকাল ঘুরতে না থাকে।

Slide-এর উদাহরণ: একটা rule খুঁজে পায় কোনো IAM user-এর access key অনেকদিন ব্যবহার হয়নি (NON_COMPLIANT), আর automatic remediation AWSConfigRemediation-RevokeUnusedIAMUserCredentials সেটা deactivate করে দেয়, ৫ বার retry সহ।

#Notification: EventBridge নাকি SNS

সমস্যার খবর পাওয়ার দুটো উপায়, দুটোই slide-এ আছে:

• EventBridge (alert-এর জন্য এটাই ভালো)। Config default event bus-এ event পাঠায়, বিশেষ করে “Config Rules Compliance Change” (আর “Config Configuration Item Change”)। একটা EventBridge rule (লেসন ১৯.৫) শুধু তোমার দরকারি rule-গুলোর NON_COMPLIANT ফল মিলিয়ে SNS, Lambda, SQS বা কোনো ticketing tool-এ পাঠাতে পারে। নিখুঁত, filter করা যায়।
• Delivery channel-এর SNS। Config তার সব notification topic-এ publish করে: প্রতিটা configuration বদল, compliance বদল, snapshot আর history পাঠানোর খবর। পুরোটা পাওয়া যায়, কিন্তু খুব হট্টগোল: SNS subscription filter policy দিয়ে বা subscriber-এর দিকে filter করো।

#অনেক account আর Region জুড়ে Config

#Aggregator

Configuration aggregator অনেক account আর Region থেকে configuration আর compliance data এক account-এ জড়ো করে, সাধারণত একটা security বা audit account-এ। Source হতে পারে পুরো AWS Organization (Organizations দিয়ে অনুমতি, management account বা একটা delegated administrator থেকে), অথবা আলাদা আলাদা account-এর তালিকা, যেখানে প্রত্যেককে aggregator-কে অনুমতি দিতে হয়।

Aggregator একটা শুধু-পড়ার view: সবখানের resource আর compliance দেখায়, সবগুলোর ওপর advanced query চালানো যায়, কিন্তু rule বানায় না, কিছু evaluate করে না, remediation-ও করে না। Rule আর remediation তবু চলে প্রতিটা account আর Region-এ, আর এই কারণেই প্রতিটা source Region-এ recorder চালু থাকতে হবে।

#Organization rule আর conformance pack

• Organization Config rule: management account বা Config-এর delegated administrator থেকে একবারে organization-এর প্রতিটা account-এ একটা rule বসানো (put-organization-config-rule)। Member account সেটা বদলাতে বা মুছতে পারে না, আর নতুন account আপনা থেকেই পেয়ে যায়।
• Conformance pack: একটা YAML template, যার ভেতরে অনেকগুলো Config rule আর তাদের remediation action এক বান্ডিলে; একটা account আর Region-এ deploy করো, বা পুরো organization-এ organization conformance pack হিসেবে। AWS নমুনা pack দেয়, যেমন CIS benchmark, NIST framework, HIPAA, PCI আর AWS Well-Architected-এর security pillar-এর জন্য “Operational Best Practices for…”। একটা pack একটা compliance score দেখায়।

#Config-এর খরচ কত

Config-এর কোনো free tier নেই। টাকা দিতে হয় প্রতি Region, প্রতি account ধরে (us-east-1-এর দাম):

বিশ্ববিদ্যালয়ের জন্য একটা চটজলদি হিসাব: ২,০০০টা resource, প্রত্যেকটা মাসে গড়ে ৫ বার বদলায়, মানে ১০,০০০টা item, প্রায় USD 30। ত্রিশটা change-triggered rule এই বদলগুলো যাচাই করলে হাজার হাজার evaluation, আরও USD 30 থেকে 50। ফাঁদ হলো ঘন ঘন জন্ম-মৃত্যু আর ঘন ঘন যাচাই: একটা Auto Scaling group দিনে শত শত instance চালু আর বন্ধ করলে, বা EMR cluster, প্রতিটা অল্পায়ু resource-এর জন্য item তৈরি হয় (ওই type-গুলো বাদ দাও, বা daily রেকর্ড করো), আর হাজার হাজার resource-এ ১ ঘণ্টার periodic rule evaluation-এর সংখ্যা গুণ করে বাড়িয়ে দেয়।

#CloudWatch বনাম CloudTrail বনাম Config

#একটা account-এর ওপর তিনটা lens

পরীক্ষার option-এ এই তিনটাকে একরকম লাগে, কারণ তিনটাই “monitor” করে। কিন্তু তারা আলাদা জিনিস দেখে:

Slide-এ আরও কয়েকটা লাইন আছে, মনে রাখার মতো। CloudWatch dashboard-ও দেয়, log জড়ো করা আর বিশ্লেষণ, আর “event আর alerting” (CloudWatch Events, এখন EventBridge)। CloudTrail account-এ সবার API call রেকর্ড করে, আর নির্দিষ্ট resource-এর জন্য trail বানানো যায় (data event)। Slide CloudTrail-কে বলে “global service”: ঠিক করে বললে CloudTrail একটা regional service; একটা multi-Region trail (console-এর default) সব Region একটা bucket-এ জড়ো করে, আর IAM, STS, CloudFront-এর মতো global service-এর event রেকর্ড হয় us-east-1-এ (লেসন ১৯.৬)। Config configuration-এর বদল রেকর্ড করে, rule ধরে resource যাচাই করে, আর বদল আর compliance-এর timeline দেয়।

#জোড়ায় জোড়ায় তুলনা

CloudWatch বনাম CloudTrail। CloudWatch দেখায় performance-এর ওপর প্রভাব: EC2-এর CPU ৮০%-এর ওপরে, log-এ ERROR লাইন। CloudTrail দেখায় কোন কাজ থেকে এটা হলো: user John একটা EC2 instance চালু করেছে, বা security group firewall-এ নতুন port খুলে দিয়েছে। বাস্তবে: CloudWatch alarm বাজায়, CloudTrail দায়ী user বা API call খুঁজে দেয়।

CloudTrail বনাম Config। CloudTrail রেকর্ড করে ঘটনাটা: “দুপুর ১২:০০-এ port 22 খোলার জন্য AuthorizeSecurityGroupIngress API call হয়েছে।” Config রেকর্ড করে ফলাফলের অবস্থা: “security group X এখন NON_COMPLIANT, কারণ port 22 0.0.0.0/0-এর জন্য খোলা।” কে কী করল তার audit report-এর জন্য CloudTrail; আইনগত compliance আর resource-এর হিসাব রাখার জন্য Config। একে অপরের সাথে জোড়াও: Config-এর timeline প্রতিটা বদলের পাশে CloudTrail event দেখায়।

CloudWatch বনাম Config। CloudWatch হলো metric-এর প্রায় real-time monitoring: memory, disk I/O, network latency। Config হলো point-in-time configuration audit: এই EBS volume কি encrypted? এই S3 bucket-এ কি default encryption, versioning, দরকারি sensitivity tag আছে? Notes Config-এর উদাহরণ হিসেবে “এই bucket-এ কি malware scanning আছে?” কথাটাও বলেছে; এটা এমন কোনো bucket setting না যা Config যাচাই করে। Object-এ malware খোঁজা হলো GuardDuty Malware Protection for S3-এর কাজ (লেসন ২১.৭)।

#Load balancer-এর উদাহরণ

একটা Application Load Balancer-এর জন্য slide-এর উদাহরণ:

• CloudWatch: আসা connection আর request-এর সংখ্যা, error code (HTTP 4xx আর 5xx) সময়ের সাথে শতাংশে, latency, আর load balancer-এর performance-এর একটা dashboard।
• Config: load balancer-এর security group rule আর configuration-এর বদল (listener, attribute) ট্র্যাক করা, আর নিশ্চিত করা যে একটা SSL/TLS certificate সবসময় লাগানো আছে (managed rule elb-acm-certificate-required, বা redirect-এর জন্য alb-http-to-https-redirection-check)।
• CloudTrail: load balancer-টা কে বদলাল, কোন API call দিয়ে।

#কোন প্রশ্নের উত্তর কোন tool

Notes-এর master cheat sheet, সাথে সেই প্রতিবেশীরা যাদের পরীক্ষায় ফাঁদ হিসেবে দেওয়া হয়:

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

#System design-এ Config

• Landing zone-এর detective স্তর। Multi-account organization-এ প্রতিটা account আর Region-এ Config চলে, aggregator আর conformance pack সামলানো হয় একটা security বা audit account থেকে, আর S3 delivery bucket থাকে আলাদা একটা log-archive account-এ, CloudTrail log-এর সাথে, bucket policy আর Object Lock দিয়ে সুরক্ষিত। AWS Control Tower ঠিক এটাই বানিয়ে দেয়; তার detective control-গুলো আসলে Config rule (লেসন ২০.৩)।
• আটকাও, ধরো, ঠিক করো। SCP আর service setting আটকায়; Config rule ধরে; SSM remediation ঠিক করে; EventBridge আর SNS জানায়। যে সমাধান নিরাপদ আর ফিরিয়ে আনা যায় (public access বন্ধ, 0.0.0.0/0-এর SSH rule সরানো), সেগুলো automatic করো; ঝুঁকিরগুলো manual রাখো।
• বদল আর incident-এর তদন্ত। Config-এর history বলে “outage-এর আগে কী বদলেছিল?”; CloudTrail বলে কে; CloudWatch দেখায় প্রভাব কখন শুরু হলো। তিনটা একসাথে ব্যবহার করো।
• Audit-এর প্রমাণ। সময়ের সাথে compliance history, conformance pack-এর score, আর Athena দিয়ে query করা S3 snapshot, auditor ঠিক এগুলোই চান। তোমার regulator যতদিন চায় ততদিন history রাখো (hospital হলে ৭ বছর, S3 copy-র জন্য S3 Lifecycle দিয়ে Glacier-এ)।
• আগে থেকেই ধরো। Pipeline-এ proactive evaluation আর CloudFormation Guard deployment-এর আগেই সমস্যা ধরে; account-এ যা পৌঁছায়, Config-এর detective rule তবু তার ওপর নজর রাখে।

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

একটা Region-এ Config চালু করো, rule যোগ করো, remediate করো, আর history দেখো। Output ছোট করা; নাম, ID আর সংখ্যা উদাহরণ মাত্র। Config item আর evaluation ধরে bill করে, তাই শেষে সব পরিষ্কার করে ফেলো।

1. ১. Recorder আর delivery channel চালু করো

   aws configservice put-configuration-recorder \
     --configuration-recorder name=default,roleARN=arn:aws:iam::111122223333:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig \
     --recording-group allSupported=true,includeGlobalResourceTypes=true \
     --recording-mode recordingFrequency=CONTINUOUS
   
   aws configservice put-delivery-channel --delivery-channel \
     'name=default,s3BucketName=config-history-example,snsTopicARN=arn:aws:sns:ap-southeast-1:111122223333:config-all,configSnapshotDeliveryProperties={deliveryFrequency=TwentyFour_Hours}'
   
   aws configservice start-configuration-recorder --configuration-recorder-name default
   aws configservice describe-configuration-recorder-status
   

   "ConfigurationRecordersStatus": [ { "name": "default", "recording": true,
     "lastStatus": "SUCCESS", "lastStartTime": "2026-11-01T09:12:03+06:00" } ]
   

   includeGlobalResourceTypes=true শুধু একটা Region-এ দাও।

2. ২. দুটো managed rule যোগ করো

   aws configservice put-config-rule --config-rule '{
     "ConfigRuleName": "restricted-ssh",
     "Source": { "Owner": "AWS", "SourceIdentifier": "INCOMING_SSH_DISABLED" },
     "Scope": { "ComplianceResourceTypes": ["AWS::EC2::SecurityGroup"] } }'
   
   aws configservice put-config-rule --config-rule '{
     "ConfigRuleName": "iam-password-policy",
     "Source": { "Owner": "AWS", "SourceIdentifier": "IAM_PASSWORD_POLICY" },
     "InputParameters": "{\"MinimumPasswordLength\":\"14\"}",
     "MaximumExecutionFrequency": "TwentyFour_Hours" }'
   

   SourceIdentifier হলো managed rule-এর identifier (INCOMING_SSH_DISABLED মানেই restricted-ssh)।

3. ৩. একটা rule ভাঙো আর ফল পড়ো

   aws ec2 authorize-security-group-ingress --group-id sg-0prod1234example \
     --protocol tcp --port 22 --cidr 0.0.0.0/0
   
   # এক-দুই মিনিট পরে
   aws configservice get-compliance-details-by-config-rule \
     --config-rule-name restricted-ssh --compliance-types NON_COMPLIANT
   

   "EvaluationResults": [ { "EvaluationResultIdentifier": { "EvaluationResultQualifier": {
       "ConfigRuleName": "restricted-ssh", "ResourceType": "AWS::EC2::SecurityGroup",
       "ResourceId": "sg-0prod1234example" } },
     "ComplianceType": "NON_COMPLIANT", "ResultRecordedTime": "2026-11-01T12:01:22+06:00" } ]
   

4. ৪. Automatic remediation যোগ করো

   aws configservice put-remediation-configurations --remediation-configurations '[{
     "ConfigRuleName": "restricted-ssh",
     "TargetType": "SSM_DOCUMENT",
     "TargetId": "AWS-DisableIncomingSSHOnPort22",
     "Parameters": {
       "SecurityGroupIds": { "ResourceValue": { "Value": "RESOURCE_ID" } },
       "AutomationAssumeRole": { "StaticValue": { "Values": ["arn:aws:iam::111122223333:role/config-remediation"] } } },
     "Automatic": true,
     "MaximumAutomaticAttempts": 5,
     "RetryAttemptSeconds": 60 }]'
   
   aws configservice describe-remediation-execution-status --config-rule-name restricted-ssh
   

   "RemediationExecutionStatuses": [ { "ResourceKey": { "resourceId": "sg-0prod1234example" },
     "State": "SUCCEEDED", "StepDetails": [ { "Name": "DisableIncomingSSHTemplate", "State": "SUCCEEDED" } ] } ]
   

   RESOURCE_ID non-compliant security group-এর ID runbook-এ পৌঁছে দেয়।

5. ৫. অতীতে ফিরে দেখো

   aws configservice get-resource-config-history \
     --resource-type AWS::EC2::SecurityGroup --resource-id sg-0prod1234example --limit 3 \
     --query 'configurationItems[].{time:configurationItemCaptureTime,status:configurationItemStatus}'
   
   aws configservice select-resource-config --expression \
     "SELECT resourceId, configuration.volumeType WHERE resourceType = 'AWS::EC2::Volume' AND configuration.encrypted = false"
   

   [ { "time": "2026-11-01T12:34:58+06:00", "status": "OK" },
     { "time": "2026-11-01T12:00:41+06:00", "status": "OK" },
     { "time": "2026-10-01T09:00:12+06:00", "status": "ResourceDiscovered" } ]
   "Results": [ "{\"resourceId\":\"vol-07ab12cd34example\",\"configuration\":{\"volumeType\":\"gp2\"}}" ]
   

6. ৬. EventBridge দিয়ে alert পাও

   aws events put-rule --name config-noncompliant --event-pattern '{
     "source": ["aws.config"],
     "detail-type": ["Config Rules Compliance Change"],
     "detail": { "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] } } }'
   
   aws events put-targets --rule config-noncompliant \
     --targets Id=sec-team,Arn=arn:aws:sns:ap-southeast-1:111122223333:security-alerts
   

   SNS topic-এর access policy-তে events.amazonaws.com-কে publish করার অনুমতি দিতে হবে (লেসন ১৯.৫)।

7. ৭. পুরো organization জড়ো করো (audit account থেকে)

   aws configservice put-configuration-aggregator --configuration-aggregator-name org-all \
     --organization-aggregation-source RoleArn=arn:aws:iam::444455556666:role/config-aggregator,AllAwsRegions=true
   
   aws configservice get-aggregate-compliance-details-by-config-rule \
     --configuration-aggregator-name org-all --config-rule-name restricted-ssh \
     --account-id 777788889999 --aws-region ap-south-1 --compliance-type NON_COMPLIANT
   

8. ৮. পরিষ্কার করো

   aws configservice delete-remediation-configuration --config-rule-name restricted-ssh
   aws configservice delete-config-rule --config-rule-name restricted-ssh
   aws configservice delete-config-rule --config-rule-name iam-password-policy
   aws configservice stop-configuration-recorder --configuration-recorder-name default
   aws events remove-targets --rule config-noncompliant --ids sec-team
   aws events delete-rule --name config-noncompliant
   

#সারসংক্ষেপ

মূল কথাগুলো

• AWS Config = resource-এর time machine (configuration history) + compliance পরীক্ষক (rule)। Regional; ওই Region-এ configuration recorder চালু না থাকলে কিছুই হয় না। Delivery channel: S3 (history file, snapshot; Athena দিয়ে query) আর ইচ্ছামতো SNS।
• Configuration item হলো এক মুহূর্তে একটা resource-এর পুরো configuration, সাথে relationship, tag আর সংশ্লিষ্ট CloudTrail event। Resource timeline সময়ের সাথে configuration, compliance আর CloudTrail call দেখায়। Global IAM type একটা Region-এ রেকর্ড করো; continuous বা daily recording।
• Rule: managed (এখন ৮০০+; slide-এর “৭৫টার বেশি” পুরোনো) বা custom (Lambda বা Guard)। Trigger: configuration change, periodic (১, ৩, ৬, ১২, ২৪ ঘণ্টা), hybrid। ফল COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE। Proactive mode deploy-এর আগে যাচাই করে, কিন্তু কিছু আটকায় না।
• ধরে, আটকায় না: Config কখনো deny করে না। আটকাতে SCP, IAM, S3 Block Public Access, EBS encryption by default।
• Remediation = SSM Automation document (AWS-managed বা custom, Lambda ডাকতে পারে), manual বা automatic, retry (default ৬০ সেকেন্ডে ৫ বার, সর্বোচ্চ ২৫), তারপর remediation exception। একটা automation role লাগে।
• Notification: EventBridge-এর compliance-change event (filter করা, নিখুঁত) বা delivery channel-এর SNS (সব event, filter করে নাও)।
• বড় পরিসরে: aggregator (শুধু পড়ে, multi-account multi-Region), organization rule, conformance pack (YAML: rule + remediation)। খরচ: প্রতি item USD 0.003 (continuous), প্রতি rule evaluation USD 0.001, কোনো free tier নেই।
• তিনটা lens: CloudWatch = performance আর health (metric, log, alarm); CloudTrail = কে কোন API call করল; Config = resource দেখতে কেমন আর compliant কি না; EventBridge = সাড়া দেওয়া আর route করা। S3-এ malware → GuardDuty, Config না। Audit Manager নতুন customer নিচ্ছে না (এপ্রিল ২০২৬)।

নিজেকে যাচাই করো: AWS Config আর তিনটা lens৩০টি প্রশ্ন