AWS Organizations, OU আর SCP

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

• বুঝিয়ে বলতে পারবে কোম্পানিগুলো কেন একটা না রেখে অনেকগুলো AWS account চালায়, আর একটা account সীমানা হিসেবে কী দেয়: ক্ষতির পরিধি (blast radius), quota, bill আর নিরাপত্তা।
• একটা organization কেমন, বর্ণনা করতে পারবে: management account আর member account, root, OU, account বানানো বনাম দাওয়াত দেওয়া, OrganizationAccountAccessRole, account ছেড়ে যাওয়া আর সরানো।
• consolidated billing বুঝিয়ে বলতে পারবে: একটা bill, সব account মিলিয়ে volume-এর দাম, Reserved Instance আর Savings Plans-এর discount ভাগাভাগি, আর কখন ভাগাভাগি বন্ধ করতে হয়।
• OU-র গাছ সাজাতে পারবে (business unit, environment, project, আর AWS-এর সুপারিশ করা OU), যাতে policy সেই কাঠামো মেনে চলে।
• গাছের যেকোনো জায়গায় একটা SCP কী allow করে, হিসাব করে বের করতে পারবে: default FullAWSAccess, deny-list আর allow-list কৌশল, উত্তরাধিকার, আর কাদের ওপর SCP খাটে না।
• পরিচিত SCP-গুলো লিখতে পারবে (organization ছাড়া আটকানো, Region lock, logging রক্ষা, root user আটকানো, একটা role রক্ষা), আর তাদের সীমাও জানবে।
• SCP, RCP, declarative policy আর অন্য policy-গুলো আলাদা করে চিনতে পারবে, আর tag policy ঠিকভাবে ব্যবহার করতে পারবে, সে কী পারে না সেটাও জেনে।
• AWS Resource Access Manager দিয়ে account-এর মধ্যে resource ভাগ করতে পারবে, আর delegated administrator account থেকে security service চালাতে পারবে।

#একটা account কেন যথেষ্ট না

২ নম্বর chapter-এ তুমি IAM দেখেছ একটা account-এর ভেতরে। কিন্তু বাস্তবের কোম্পানি খুব কমই একটা account নিয়ে থাকে। ঢাকার একটা mobile-banking কোম্পানির হয়তো বিশটা account, একটা বড় ব্যাংকের কয়েকশো। কারণটা সোজা: AWS-এ সবচেয়ে মজবুত সীমানা হলো account। প্রায় সবকিছুই account ধরে আলাদা:

• ক্ষতির পরিধি (blast radius)। ফাঁস হয়ে যাওয়া একটা access key, resource মুছে ফেলা কোনো ভুল script, বা বেশি ক্ষমতা পাওয়া কোনো developer ক্ষতি করতে পারে শুধু নিজের account-এ। Dev account-এর একটা test কখনো Prod account-এর payment database ছুঁতে পারে না, কারণ দুই account-এর মধ্যে কোনো IAM user, role বা resource ভাগ করা নেই, যতক্ষণ না তুমি ইচ্ছে করে জোড়া দাও।
• Quota। service quota (Lambda concurrency, EC2 vCPU, API rate limit) account আর Region ধরে আলাদা। এক account-এর load test বা লাগামছাড়া কোনো job আরেক account-এর quota খেয়ে ফেলতে পারে না। lesson ১৫.২ এটারই কথা দিয়েছিল: জরুরি কাজ পুরোপুরি আলাদা রাখার শক্ত উপায় হলো আলাদা account।
• Bill। প্রতিটা account-এর খরচ আলাদা লাইনে আসে, তাই কোনো tag ছাড়াই প্রতিটা team, product বা গ্রাহকের খরচ আলাদা দেখা যায়।
• নিরাপত্তা আর compliance। auditor-কে বলা যায় “card-এর ডেটা শুধু এই দুটো account-এ থাকে”, তাতে audit-এর পরিধি ছোট থাকে। আলাদা account-এ আলাদা নিয়মও রাখা যায়।

এর বিকল্প, একটা account-এ অনেকগুলো VPC, সবাইকে একই IAM, একই quota আর একই bill-এর মধ্যে রেখে দেয়। IAM policy-তে একটা ভুল হলেই সব খুলে যেতে পারে। স্লাইডে এই তুলনাকে বলা হয়েছে multi account বনাম একটা account-এ অনেক VPC, আর ছোট কোনো প্রজেক্টের বাইরে যেকোনো কিছুর জন্য AWS অনেক account-ই সুপারিশ করে।

অনেক account মানে নতুন একটা ঝামেলা: চল্লিশটা account-এর user, চল্লিশটা bill আর চল্লিশ সেট নিয়ম সামলাবে কীভাবে? এই chapter সেটা নিয়েই। এই lesson-এ কাঠামোটা (Organizations, OU, policy)। Lesson ২০.২ SCP আর RCP-কে condition আর boundary-সহ পুরো যাচাইয়ের ধারায় বসায়, আর lesson ২০.৩ IAM Identity Center দিয়ে মানুষকে সব account-এ একবারেই sign in করায়, আর Control Tower দিয়ে তৈরি-করা একটা organization বানায়।

#AWS Organizations

#Management account আর member account

AWS Organizations একটা বিনা পয়সার global service, যেটা AWS account-গুলোকে একটা organization-এর মধ্যে জড়ো করে:

• যে account organization বানায়, সে হয় management account। পুরোনো document, owner-এর নোট আর কিছু API field (যেমন MasterAccountId) এখনো একে master account বলে: একই জিনিস, শুধু নাম বদলেছে। সে bill দেয়, account বানায় আর দাওয়াত দেয়, policy সামলায়। management account অন্য account-এ বদলানো যায় না; বদলাতে চাইলে organization-টাই মুছে ফেলতে হবে।
• বাকি প্রতিটা account হলো member account। একটা account একসঙ্গে শুধু একটা organization-এ থাকতে পারে।
• organization-এর ঠিক একটা root থাকে, গাছের মাথা। তার নিচে তুমি organizational unit (OU) বানাও, ফোল্ডারের মতো, যার ভেতরে account আর অন্য OU থাকে। root-এর নিচে OU ৫ ধাপ পর্যন্ত গভীরে বসানো যায়, আর একটা organization-এ ২,০০০ পর্যন্ত OU রাখা যায়। একটা account থাকে ঠিক এক জায়গায়: root-এ, নয়তো একটা OU-তে।
• নতুন একটা organization-এ default-ভাবে ১০টা account রাখা যায় (খোলা থাকা দাওয়াতও গোনা হয়)। management account Service Quotas-এ বেশি চাইতে পারে; বড় কোম্পানি হাজার হাজার account চালায়। একদম নতুন organization কখনো কখনো এর চেয়ে কম quota দিয়ে শুরু হয়।

management account-এর ক্ষমতা সবচেয়ে বেশি, আর তার ওপর SCP খাটে না (নিচে দেখবে)। তাই AWS-এর পরামর্শ: একে প্রায় খালি রাখো। কোনো workload না, খুব অল্প মানুষ, শুধু organization চালানো আর billing।

#Account বানানো আর দাওয়াত দেওয়া

organization-এ account আনার দুটো পথ।

OrganizationAccountAccessRole হলো lesson ২.৪-এর সেই পরিচিত cross-account admin role: management account-এর administrator-রা sts:AssumeRole দিয়ে এতে ঢোকে। অনেক কোম্পানি পরে এর জায়গায় IAM Identity Center-এর permission set (lesson ২০.৩) ব্যবহার করে, আর কে এটা assume করতে পারবে তা কড়া করে বেঁধে দেয়।

#ছেড়ে যাওয়া, সরিয়ে দেওয়া আর অন্য জায়গায় নেওয়া

• একটা member account নিজে ছেড়ে যেতে পারে (LeaveOrganization), অথবা management account তাকে সরিয়ে দিতে পারে। দুই ক্ষেত্রেই account-কে একা চলার মতো হতে হবে: নিজের payment method, যোগাযোগের তথ্য আর support plan লাগবে, আর Organizations-এর বানানো account হলে অন্তত ৪ দিন পুরোনো হতে হবে।
• নভেম্বর ২০২৫ থেকে একটা account সরাসরি এক organization থেকে আরেকটায় যেতে পারে: নতুন organization দাওয়াত দেয়, account accept করে, মাঝখানে কখনো একা হয় না। এর আগে একমাত্র পথ ছিল ছেড়ে যাওয়া → একা থাকা → accept করা। আগে লেখা পরীক্ষার প্রশ্ন পুরোনো পথটাই বলে, আর সেটা এখনো কাজ করে।
• একই organization-এর ভেতরে এক OU থেকে আরেক OU-তে account সরানো (move-account) সঙ্গে সঙ্গে হয়, আর account তখনই গাছের নতুন জায়গার policy পেয়ে যায়। আগে পরীক্ষা করে নাও: কড়া কোনো OU চলতে থাকা workload ভেঙে দিতে পারে।
• management account ছেড়ে যেতে পারে না। একটা organization শেষ করতে চাইলে আগে সব member সরাও, তারপর organization মুছে ফেলো।

এখানে পরীক্ষার প্রিয় বাক্য: “member account যেন organization ছেড়ে যেতে না পারে”। উত্তর: একটা SCP, যেটা organizations:LeaveOrganization deny করে।

#All features নাকি শুধু consolidated billing

একটা organization দুটো feature set-এর একটায় চলে:

• All features (নতুন organization-এর default): consolidated billing সঙ্গে SCP, RCP, tag policy আর বাকি সব policy, AWS service-গুলোর জন্য trusted access, আর delegated administrator।
• শুধু consolidated billing: শুধু একসঙ্গে bill। কোনো ধরনের policy নেই।

শুধু billing দিয়ে শুরু করা পুরোনো organization all features-এ যেতে পারে। দাওয়াত দিয়ে আনা প্রতিটা account-কে এই বদলে রাজি হতে হয় (organization-এর ভেতরে বানানো account-গুলো নিজে থেকেই রাজি)। all features একবার চালু হলে আর ফেরা যায় না। পরীক্ষায় প্রশ্নে SCP লাগলে বুঝবে organization-এ all features লাগবে।

#Consolidated billing

consolidated billing প্রতিটা organization-এ চালু থাকে, কোনো খরচ নেই। এটা তিনটা জিনিস দেয়:

1. একটা bill, একটা payment method। প্রতিটা member-এর খরচ management account-এর invoice-এ আসে। Cost Explorer-এ তবু account ধরে খরচ আলাদা দেখা যায়, তাই প্রতিটা team নিজের খরচ দেখে। member account-গুলো একে অপরের bill দেখতে পায় না।
2. সব account মিলিয়ে volume-এর দাম। যে দাম ব্যবহার বাড়লে কমে (S3 storage-এর ধাপ, data transfer, আরও কিছু service), সেটা হিসাব হয় সব account-এর মোট ব্যবহার ধরে, যেন সবাই একটাই account। দুটো team-এর একটার ৩০ TB আর আরেকটার ৪০ TB S3 Standard থাকলে, একা একা দুজনেই প্রথম ৫০ TB-র ধাপে থাকত; একসঙ্গে ৭০ TB, তাই শেষ ২০ TB পরের সস্তা ধাপে bill হয়।
3. Reserved Instance আর Savings Plans-এর discount ভাগাভাগি। এক account-এ কেনা commitment আগে সেই account-এর ব্যবহারে লাগে; যা বেঁচে যায়, সেটা অন্য account-এর মিলে যাওয়া ব্যবহারে লাগে (lesson ৪.৪)। organization-এর কোনো account ব্যবহার করতে পারলে কিছুই নষ্ট হয় না।

ভাগাভাগি default-ভাবে চালু, আর management account billing preferences-এ গিয়ে যেকোনো account-এর জন্য এটা বন্ধ করতে পারে (নিজের জন্যও)। যে account-এর ভাগাভাগি বন্ধ, সে নিজের বেঁচে যাওয়া discount অন্যকে দেয় না, অন্যদেরটাও পায় না। group-এর কোনো কোম্পানির যদি নিজের লাভ-ক্ষতির হিসাব থাকে, আর সে অন্যদের ভর্তুকি দেবে না বা অন্যদের থেকে নেবেও না, তখন এটা কাজে লাগে।

#OU-র গাছ সাজানো

OU-র কাজই হলো policy যেন কাঠামো মেনে চলে। একটা OU-তে বসানো policy তার ভেতরের প্রতিটা account আর OU-তে খাটে। তাই গাছটা সাজাও কোথায় কতটা আলাদা নিয়মে চালাতে চাও সেটা ধরে, কোম্পানির organogram ধরে না।

স্লাইডে তিনটা পরিচিত ধরন আছে:

এগুলো মেশানোও যায়: একটা business-unit OU-র ভেতরে Prod আর Dev sub-OU থাকতে পারে। AWS-এর নিজের গাইড (“Organizing your AWS environment using multiple accounts”) কিছু OU-র সুপারিশ করে, বেশির ভাগ organization শেষমেশ এগুলোতেই পৌঁছায়:

দরকারমতো আরও আসে: Deployments (CI/CD), Exceptions (যে account-এর বিশেষ নিয়ম লাগে), Transitional (কিনে নেওয়া কোম্পানি থেকে সদ্য আসা account), Individual business users।

স্লাইডে আরও আছে, অনেক account থাকলে কী কী কেন্দ্র থেকে করা যায়: billing-এর জন্য tag-এর একই মান, প্রতিটা account-এ CloudTrail চালু করে log পাঠানো একটা log account-এর central bucket-এ (lesson ১৯.৬), CloudWatch Logs একটা central logging account-এ জড়ো করা, আর administration-এর জন্য cross-account role। এগুলোর সব নিচে বা lesson ২০.৩ আর ১৯.৬-এ আছে।

#Service control policy

#SCP কী, আর কী না

একটা service control policy (SCP) হলো একটা JSON policy, প্রায় IAM policy-র মতোই লেখা, যেটা বসানো হয় root, একটা OU বা একটা account-এ। এটা ঠিক করে দেয় প্রভাবিত member account-গুলোর IAM user আর role সর্বোচ্চ কতটা করতে পারবে। lesson ২.২ এর পরিচয় দিয়েছিল; এবার সব নিয়ম:

• SCP কখনো কিছু দেয় না। আসল permission হলো SCP আর IAM policy-র (আর boundary, আর RCP-র) মিল (intersection)। যে user-এর কোনো IAM policy নেই, SCP সব action allow করলেও সে কিছুই পারে না।
• member account-এর প্রতিটা IAM user আর role-এর ওপর খাটে, ওই account-এর root user-এর ওপরেও, AdministratorAccess-ওয়ালা administrator-দের ওপরেও। এজন্যই এটা সত্যিকারের পাহারা: account-এর ভেতরের কেউ এটা সরাতে পারে না।
• management account-এ কখনো খাটে না। সেখানকার user আর role-কে সীমিত করে শুধু তাদের নিজের IAM policy, যে SCP-ই বসাও।
• service-linked role-এ কখনো খাটে না। AWS service যে role দিয়ে তোমার হয়ে কাজ করে (Auto Scaling, GuardDuty, Organizations নিজে), সেগুলো চলতেই থাকে, তাই কড়া SCP-ও AWS-এর নিজের যোগাযোগ ভাঙতে পারে না।
• শুধু তোমার নিজের member account-এর principal-এর ওপর খাটে। member account-এর কোনো bucket policy যদি বাইরের একটা account-কে পড়তে দেয়, SCP সেই বাইরের জনের ব্যাপারে কিছুই করে না। এই ফাঁকটাই RCP ভরাট করে (নিচে)।
• root-এর কিছু নিজস্ব কাজ SCP দিয়ে একদমই আটকানো যায় না (যেমন root হয়ে Enterprise Support plan-এ sign up করা)।

#উত্তরাধিকার: প্রতিটা ধাপে Allow, যেকোনো জায়গায় Deny

গাছটা হলো Root → OU → sub-OU → account। একটা account-এর কোনো principal-এর request এলে AWS root থেকে ওই account পর্যন্ত সরাসরি পথে বসানো প্রতিটা SCP দেখে:

1. যেকোনো জায়গার Deny জেতে। পথের যেকোনো ধাপের কোনো SCP action-টা deny করলে request deny। root-এর একটা Deny প্রতিটা member account-এ পৌঁছায়; একটা OU-র Deny তার ভেতরের সবকিছুতে।
2. প্রতিটা ধাপে Allow। পথের প্রতিটা ধাপে (root, প্রতিটা OU, account নিজে) অন্তত একটা বসানো SCP থাকতে হবে যেটা action allow করে। একটা ধাপেও না থাকলে action deny, বাকি সব ধাপ allow করলেও। সব জায়গায় FullAWSAccess থাকলে এটা নিজে থেকেই মেটে; allow-list ব্যবহার করলে ঠিক এই জায়গাটাতেই ভুল হয়।
3. তারপর IAM। SCP ছেড়ে দিলে তবেই account-এর নিজের IAM policy-র প্রশ্ন আসে, আর সেটাকেও allow করতে হবে।

খেয়াল করো, দুটো আলাদা আচরণ: Deny নিজে থেকেই নিচে নামে, কিন্তু Allow নামে না। root-এ EC2 allow করা একটা SCP, যে OU FullAWSAccess সরিয়েছে তাকে কিছুই দেয় না; সেই OU-কে নিজেকেই EC2 allow করতে হবে।

#Deny-list নাকি allow-list কৌশল

বেশির ভাগ organization দুটো মেশায়: workload-এর জন্য deny-list, Sandbox OU-র জন্য allow-list।

#স্লাইডের গাছের উদাহরণ

স্লাইডের গাছটা ধাপে ধাপে মিলিয়ে দেখা দরকার, কারণ পরীক্ষায় ঠিক এমন ছবিই আসে:

প্রতিটা ক্ষেত্রেই account-এর IAM policy-কে তবু permission-টা দিতে হবে।

#পরিচিত SCP-গুলো

organization ছেড়ে যাওয়া deny (root-এ বসাও):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyLeaveOrg",
    "Effect": "Deny",
    "Action": "organizations:LeaveOrganization",
    "Resource": "*"
  }]
}

Region lock, global service-গুলোকে বাদ রেখে (কেন NotAction লাগে, lesson ২.২-এ দেখেছ):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideSingaporeAndMumbai",
    "Effect": "Deny",
    "NotAction": [
      "iam:*", "sts:*", "organizations:*", "route53:*", "cloudfront:*",
      "support:*", "budgets:*", "waf:*", "globalaccelerator:*", "health:*"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["ap-southeast-1", "ap-south-1"] },
      "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/break-glass-admin" }
    }
  }]
}

ArnNotLike condition একটা জরুরি অবস্থার role-কে ছাড় দেয়; Deny খাটতে হলে দুটো condition-ই সত্যি হতে হবে।

logging আর security service রক্ষা:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectSecurityServices",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail",
      "guardduty:DeleteDetector", "guardduty:DisassociateFromMasterAccount",
      "config:StopConfigurationRecorder", "config:DeleteConfigurationRecorder"
    ],
    "Resource": "*"
  }]
}

member account-এর root user আটকানো:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyRootUser",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" } }
  }]
}

প্রতিটা account-এ একটা security role রক্ষা, শুধু security team নিজে ছাড়া:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ProtectSecurityAuditRole",
    "Effect": "Deny",
    "Action": [
      "iam:DeleteRole", "iam:UpdateAssumeRolePolicy", "iam:AttachRolePolicy",
      "iam:DetachRolePolicy", "iam:PutRolePolicy", "iam:DeleteRolePolicy"
    ],
    "Resource": "arn:aws:iam::*:role/security-audit",
    "Condition": {
      "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/security-team-admin" }
    }
  }]
}

আরও কিছু পরিচিত SCP: IAM user বা access key বানানো deny (মানুষ Identity Center ব্যবহার করবে), finance ছাড়া কেউ Reserved Instance কিনতে পারবে না, শুধু নির্দিষ্ট EC2 instance type allow, S3 bucket public করা deny, IMDSv2 বাধ্যতামূলক।

#SCP-র লেখার নিয়ম আর সীমা

লেখার ধরন IAM-এরই, একটা বড় ব্যতিক্রম ছাড়া: SCP-তে Principal বা NotPrincipal element নেই, কারণ এটা সবসময় যে account-এ বসানো তার principal-দের ওপর খাটে। নির্দিষ্ট principal ধরতে চাইলে উদাহরণগুলোর মতো aws:PrincipalArn-এর ওপর condition দাও। সেপ্টেম্বর ২০২৫ থেকে SCP পুরো IAM policy language বোঝে: condition, NotAction, NotResource আর নির্দিষ্ট resource ARN এখন Allow statement-এও চলে, আগের মতো শুধু Deny-তে না। পুরোনো লেখায় (আর স্লাইডে) পাবে, SCP-র Allow statement শুধু "Resource": "*" নিতে পারে, condition ছাড়া; এটা আর সত্যি না, যদিও পরীক্ষার প্রশ্ন সেই সময়ের লেখা হতে পারে।

#SCP-র বাইরে: RCP আর declarative policy

#Resource control policy

Resource control policy (RCP), নভেম্বর ২০২৪ থেকে আছে, অন্য authorization policy। SCP যেখানে তোমার principal-রা কী করতে পারবে তার সীমা টানে, RCP সেখানে সীমা টানে তোমার resource-এর ওপর, যে কেউ কী করতে পারবে তার: তোমার নিজের principal, অন্য organization-এর principal, এমনকি নাম-পরিচয়হীন request-ও।

• root, OU বা account-এ বসে, SCP-র মতোই নিচে নামে, আর এটাও কিছু দেয় না।
• RCP চালু করলেই RCPFullAWSAccess সব জায়গায় বসে যায়, আর এটা সরানো যায় না। তাই বাস্তবে RCP লেখা হয় "Principal": "*"-সহ Deny statement হিসেবে।
• প্রতিটা জায়গায় ৫টা পর্যন্ত (RCPFullAWSAccess ধরে), প্রতিটা ৫,১২০ অক্ষর।
• খাটে শুধু যে service-গুলো সমর্থন করে সেগুলোতে। শুরুতে তালিকা ছিল S3, STS, KMS, SQS আর Secrets Manager, পরে বড় হয়েছে (২০২৬-এর শেষে DynamoDB, CloudWatch Logs, ECR, Cognito, OpenSearch Serverless আর আরও অনেক)। EC2 তালিকায় নেই।
• SCP-র মতোই management account-এর resource বা service-linked role-এ কখনো খাটে না, আর AWS managed KMS key-তেও খাটে না।

সাধারণ RCP হলো একটা data perimeter: organization-এর প্রতিটা S3 bucket, queue, key আর secret-এ access deny করো, যদি না caller organization-এর ভেতরের কেউ (aws:PrincipalOrgID) হয়, বা তোমার হয়ে কাজ করা কোনো AWS service হয়। তাহলে কোনো developer ভুল করে bucket policy-তে "Principal": "*" লিখলেও গ্রাহকের কাগজপত্র বাইরে যায় না।

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "OnlyOurOrgCanTouchOurData",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:*", "sqs:*", "kms:*", "secretsmanager:*", "sts:AssumeRole"],
    "Resource": "*",
    "Condition": {
      "StringNotEqualsIfExists": { "aws:PrincipalOrgID": "o-a1b2c3d4e5" },
      "BoolIfExists": { "aws:PrincipalIsAWSService": "false" }
    }
  }]
}

পুরো যাচাইয়ের ধারায় SCP আর RCP ঠিক কোথায় বসে, resource-based policy, boundary আর session policy-র সঙ্গে, সেটা আছে lesson ২০.২-এ।

#Declarative policy

Declarative policy (ডিসেম্বর ২০২৪) API request যাচাই করেই না। এটা যে account-গুলোর ওপর বসে, সেখানে একটা service-এর configuration ঠিক করে দেয়, আর AWS সেটা ধরে রাখে, পরে যোগ হওয়া API আর feature-এর ক্ষেত্রেও। প্রথমটা Amazon EC2-এর জন্য, যেমন জোর করে বসাতে পারে: নতুন instance-এ default হিসেবে IMDSv2, AMI আর EBS snapshot public করে ভাগ করা বন্ধ, VPC Block Public Access, serial console access বন্ধ, আর শুধু অনুমোদিত provider-এর image। কেউ বন্ধ করা কিছু করতে গেলে তুমি নিজে যে error message লিখে রেখেছ সেটা পায়। SCP-র উল্টো, declarative policy management account-এও খাটে।

#অন্য policy-গুলো

SCP বা RCP নয় এমন প্রতিটা policy-কে AWS-এর গাইড এখন দ্বিতীয় একটা দলে রাখে, যার নাম declarative policy (ওপরের EC2 policy-ও এই দলেরই)। প্রত্যেকটা ব্যবহারের আগে root-এ চালু করতে হয়। যেগুলো চিনে রাখা দরকার:

এগুলোর সবগুলোই (SCP আর RCP-র উল্টো) management account-এও খাটে, আর যেকোনো account-এর effective policy, মানে উত্তরাধিকারের পর আসলে যা দাঁড়ায়, দেখে নেওয়া যায়।

#Tag policy

#Tag policy কী করে

একটা tag policy পুরো organization-এ tag এক রকম রাখে। tag দিয়ে cost report বা access control তখনই চলে, যখন সবাই একইভাবে লেখে: AWS-এর কাছে CostCenter, costcenter আর Cost-Center তিনটা আলাদা key, আর একটা ধরে cost report বানালে বাকি দুটো বাদ পড়ে।

একটা tag policy প্রতিটা tag-এর জন্য ঠিক করে দিতে পারে:

• key-এর বানান, বড়-ছোট অক্ষরসহ (CostCenter),
• অনুমোদিত মান (retail, cards, treasury, বা একটা wildcard pattern),
• কোন resource type-এর জন্য policy-টা enforce হবে (ec2:instance, s3:bucket…)।

{
  "tags": {
    "costcenter": {
      "tag_key": { "@@assign": "CostCenter" },
      "tag_value": { "@@assign": ["retail", "cards", "treasury"] },
      "enforced_for": { "@@assign": ["ec2:instance"] }
    }
  }
}

enforced_for না থাকলে policy শুধু report করে: management account (বা একটা delegated administrator) Tag Editor-এ পুরো organization-এর একটা tag compliance report বানায়, আর নিয়ম-না-মানা tag বদল হলে EventBridge সাড়া দিতে পারে। enforced_for থাকলে, ওই resource type-এ নিয়ম ভাঙা কোনো tag দেওয়ার কাজ বাতিল হয়। tag policy উত্তরাধিকারের operator (@@assign, @@append, @@remove) ব্যবহার করে, তাই root যা ঠিক করেছে তার সঙ্গে একটা OU নতুন মান যোগ করতে পারে, আর যেকোনো account-এর effective tag policy দেখা যায়।

#Tag policy কী করে না

#Tag, খরচ আর access

এক রকম tag-এর ওপর দুটো জিনিস দাঁড়িয়ে থাকে:

• Cost allocation tag। Cost Explorer আর Cost and Usage Report-এ দেখাতে হলে tag key-কে তবু Billing console-এ activate করতে হয় (lesson ১.৪)। tag policy এগুলো এক রকম রাখে; activate করে না।
• ABAC (attribute-based access control): এমন IAM policy, যেটা caller-এর tag আর resource-এর tag মেলায়, যেমন “যে instance-এর Team tag তোমার নিজের সমান, শুধু সেগুলো তুমি বন্ধ করতে পারবে”। tag-এ একটা বানান ভুল এমন নিয়ম চুপচাপ ভেঙে দেয়, তাই tag policy একে রক্ষা করে (lesson ২০.২)।

#পুরো organization জুড়ে service চালানো

#Trusted access আর delegated administrator

অনেক AWS service Organizations বোঝে: CloudTrail, Config, GuardDuty, Security Hub, IAM Identity Center, Firewall Manager, AWS Backup, CloudFormation stack sets, IAM Access Analyzer আর আরও কিছু। দুটো সুইচ এদের জোড়া দেয়:

• Trusted access service-টাকে সব account জুড়ে কাজ করতে দেয়, যেমন প্রতিটা নতুন account-এ নিজে থেকে GuardDuty চালু করা, বা CloudTrail-এ একটা organization trail বানানো, যেটা প্রতিটা account-এর কাজ এক bucket-এ লেখে।
• Delegated administrator হলো একটা member account, যাকে management account পুরো organization-এর জন্য একটা service চালানোর দায়িত্ব দেয়। GuardDuty, Security Hub আর Config সাধারণত security tooling account-কে দেওয়া হয়, তাই security team সেখানে কাজ করে, আর রোজকার কাজে কাউকে management account-এ ঢুকতে হয় না। delegated administrator account-এর ওপর SCP খাটে, কারণ এগুলো member account।

Organizations নিজেও একটা resource-based delegation policy দিয়ে policy সামলানোর দায়িত্ব একটা member account-কে দিতে পারে, তাই একটা platform team management account-এ না ঢুকেই SCP সামলাতে পারে।

#AWS Resource Access Manager

অনেক account থাকলে প্রায়ই চাও একটা resource-এর একটাই কপি কয়েকটা account ব্যবহার করুক। AWS Resource Access Manager কপি না করে account-এর মধ্যে resource ভাগ করে দেয়। তুমি একটা resource share বানাও, তাতে resource যোগ করো, আর principal যোগ করো: account, OU, বা পুরো organization।

সাধারণত যা ভাগ করা হয়:

• VPC subnet (VPC sharing): একটা network account VPC-র মালিক; application account-গুলো ভাগ করা subnet-এ তাদের instance, database আর load balancer চালু করে। অংশগ্রহণকারীরা VPC, subnet বা route table বদলাতে বা মুছতে পারে না, একে অপরের resource-ও না। subnet শুধু organization-এর ভেতরেই ভাগ করা যায়।
• Transit Gateway, যাতে অন্য account-গুলো তাদের VPC একটা কেন্দ্রীয় hub-এ জোড়ে (lesson ২২.৬)।
• Route 53 Resolver rule (lesson ৮.৫), prefix list, IPAM pool, License Manager configuration, Aurora DB cluster, Network Firewall policy, capacity reservation আর আরও অনেক কিছু।

management account AWS Organizations-এর সঙ্গে sharing চালু করার পর organization-এর ভেতরের share দাওয়াত ছাড়াই কাজ করে। organization-এর বাইরের account-এ share মানে একটা দাওয়াত, যেটা accept করতে হয়।

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

• member account-এর একজন admin এমন কাজে AccessDenied পায়, যেটা তার IAM policy allow করে। account-এর ওপরে তাকাও: পথে কোনো SCP-র Deny, বা allow-list-এর কোনো ধাপে service-টা লেখা নেই। error message সাধারণত বলে দেয় “with an explicit deny in a service control policy” বা “because no service control policy allows”।
• root-এ নতুন SCP বসাতেই production ভেঙে পড়ল। এটা একসঙ্গে প্রতিটা member account-এ পৌঁছে গেছে। আগে একটা staging OU-তে পরীক্ষা করো।
• “কড়া করার জন্য” FullAWSAccess সরানো হলো, আর সব থেমে গেল। এটা না থাকলে ওই ধাপ শুধু তার অন্য SCP-তে লেখা জিনিসই allow করে। প্রতিটা পথের প্রতিটা ধাপে Allow লাগে।
• Region lock admin-দের IAM থেকে আটকে দিল। Deny-তে global service বাদ দিয়ে NotAction না লিখে Action: "*" লেখা হয়েছে।
• পরীক্ষায় পাহারা কাজ করে, কিন্তু একটা account-এ করে না। ওটা management account, যেখানে SCP কখনো খাটে না। অথবা কাজটা করেছে একটা service-linked role।
• central team দাওয়াত দিয়ে আনা account-এ ঢুকতে পারছে না। দাওয়াতি account OrganizationAccountAccessRole পায় না; কাউকে বানাতে হবে।
• একটা account ছেড়ে যেতে বা সরানো যাচ্ছে না। একা চলার জন্য তার payment method, যোগাযোগের তথ্য বা support plan নেই, account-টা খুব নতুন, অথবা কোনো SCP ছেড়ে যাওয়া deny করে।
• tag report বলছে সব ঠিক, অথচ bill-এ tag-ছাড়া খরচ। tag policy tag-ছাড়া resource দেখে না, আর cost allocation tag activate করতে হয়।
• SCP থাকা সত্ত্বেও বাইরের একটা account bucket পড়ছে। SCP বাইরের জনকে সীমিত করে না; RCP বা resource policy-তে aws:PrincipalOrgID ব্যবহার করো।

#System design আর পরীক্ষায় কীভাবে আসে

• শুরু থেকেই অনেক account। production, non-production, security log, ভাগ করা network আর sandbox-এর জন্য আলাদা account। management account খালি রাখো। বাস্তবে Control Tower এই কাঠামোটা তোমার জন্য বানিয়ে দেয়।
• পাহারা, দারোয়ান না। root-এ অল্প কয়েকটা SCP (ছেড়ে যাওয়া deny, logging রক্ষা, Region lock, root আটকানো), Sandbox-এ কড়া allow-list, Suspended-এ প্রায় সব Deny।
• Data perimeter। RCP (বা resource policy-তে aws:PrincipalOrgID), যাতে শুধু তোমার organization তোমার ডেটায় পৌঁছাতে পারে।
• সবকিছু কেন্দ্রে। একটা organization trail, Config aggregator, GuardDuty আর Security Hub চলে একটা delegated administrator account থেকে; log থাকে একটা log archive account-এ, যেখান থেকে কেউ মুছতে পারে না।
• ভাগ করো, কপি কোরো না। network আর DNS resource ভাগ হয় AWS Resource Access Manager দিয়ে।

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

একটা test organization-এর management account থেকে (তোমার কোম্পানির আসলটা থেকে কখনো না), CLI configure করা থাকলে। Organizations global; এর endpoint us-east-1-এ।

# আমি কোন organization-এ? (output-এ পুরোনো "Master" নামগুলো খেয়াল করো।)
aws organizations describe-organization
# {
#   "Organization": {
#     "Id": "o-a1b2c3d4e5",
#     "Arn": "arn:aws:organizations::111122223333:organization/o-a1b2c3d4e5",
#     "FeatureSet": "ALL",
#     "MasterAccountArn": "arn:aws:organizations::111122223333:account/o-a1b2c3d4e5/111122223333",
#     "MasterAccountId": "111122223333",
#     "MasterAccountEmail": "aws-root@example.com"
#   }
# }

# root, তারপর তার নিচে একটা Workloads OU
aws organizations list-roots --query 'Roots[].[Id,Name]' --output text
# r-ab12  Root
aws organizations create-organizational-unit --parent-id r-ab12 --name Workloads
# { "OrganizationalUnit": { "Id": "ou-ab12-cdef3456", "Name": "Workloads", ... } }

# organization-এর ভেতরেই সরাসরি একটা account বানাও (asynchronous)
aws organizations create-account --email payments-prod@example.com --account-name payments-prod
# { "CreateAccountStatus": { "Id": "car-0a1b2c3d4e5f", "State": "IN_PROGRESS", ... } }
aws organizations describe-create-account-status --create-account-request-id car-0a1b2c3d4e5f \
  --query 'CreateAccountStatus.[State,AccountId]' --output text
# SUCCEEDED  444455556666
aws organizations move-account --account-id 444455556666 \
  --source-parent-id r-ab12 --destination-parent-id ou-ab12-cdef3456
aws organizations list-accounts-for-parent --parent-id ou-ab12-cdef3456 \
  --query 'Accounts[].[Id,Name,Status]' --output table

# ছেড়ে যাওয়া deny করা একটা SCP, root-এ বসানো
aws organizations create-policy --type SERVICE_CONTROL_POLICY --name DenyLeaveOrg \
  --description "Member accounts cannot leave" --content file://deny-leave.json
# { "Policy": { "PolicySummary": { "Id": "p-a1b2c3d4", "Name": "DenyLeaveOrg", ... } } }
aws organizations attach-policy --policy-id p-a1b2c3d4 --target-id r-ab12
aws organizations list-policies-for-target --target-id 444455556666 \
  --filter SERVICE_CONTROL_POLICY --query 'Policies[].Name'
# [ "FullAWSAccess" ]   <- শুধু সরাসরি বসানোগুলো; root-এর DenyLeaveOrg উত্তরাধিকারে আসে

# Tag policy: type চালু করো, একটা বসাও, তারপর দেখো একটা account আসলে কী পায়
aws organizations enable-policy-type --root-id r-ab12 --policy-type TAG_POLICY
aws organizations create-policy --type TAG_POLICY --name CostCenterTags --content file://tags.json
aws organizations attach-policy --policy-id p-e5f6a7b8 --target-id ou-ab12-cdef3456
aws organizations describe-effective-policy --policy-type TAG_POLICY --target-id 444455556666

# network account থেকে (সেখানে চালাও) Workloads OU-র সঙ্গে একটা subnet ভাগ করো
aws ram enable-sharing-with-aws-organization          # একবারই, management account থেকে
aws ram create-resource-share --name shared-app-subnets \
  --resource-arns arn:aws:ec2:ap-southeast-1:777788889999:subnet/subnet-0abc1234def567890 \
  --principals arn:aws:organizations::111122223333:ou/o-a1b2c3d4e5/ou-ab12-cdef3456

তারপর নতুন account থেকে (OrganizationAccountAccessRole assume করে) aws organizations leave-organization চালিয়ে দেখো, আর AccessDenied message-টা পড়ো: সেখানে service control policy-র নাম থাকবে। একটা test OU-তে allow-list বসিয়ে তার FullAWSAccess সরাও, আর দেখো কোন কোন command fail করতে শুরু করে।

#সারসংক্ষেপ

মূল কথা

• AWS account সবচেয়ে মজবুত সীমানা: ক্ষতির পরিধি, quota, bill আর নিরাপত্তার নিয়ম সবই account ধরে। অনেক account ব্যবহার করো, আর AWS Organizations দিয়ে সামলাও।
• একটা management account (আগের নাম “master”), অনেক member account, প্রত্যেকে ঠিক একটা organization-এ; একটা root, ৫ ধাপ পর্যন্ত গভীর OU; default-ভাবে ১০টা account।
• account বানালে OrganizationAccountAccessRole নিজে থেকেই আসে; দাওয়াতি account-এ হাতে বানাতে হয়। ছেড়ে যেতে একা চলার তথ্য লাগে; নভেম্বর ২০২৫ থেকে account সরাসরি এক organization থেকে আরেকটায় যেতে পারে।
• Consolidated billing: একটা bill, volume-এর ধাপে সবার ব্যবহার যোগ, RI আর Savings Plans-এর discount ভাগ (প্রতিটা account-এর জন্য বন্ধ করা যায়)। যেকোনো policy-র জন্য all features লাগে।
• OU সাজাও শাসনের দরকার ধরে: business unit, environment, project; AWS সুপারিশ করে Security, Infrastructure, Workloads, Sandbox, Policy staging, Suspended।
• SCP member account-এর IAM user আর role-এর সর্বোচ্চ সীমা টানে, root user-এরও; কিছু দেয় না; management account, service-linked role বা বাইরের কারও ওপর কখনো খাটে না।
• default-ভাবে সব জায়গায় FullAWSAccess বসানো (“default-ভাবে deny” না)। পথের যেকোনো জায়গার Deny জেতে; allow-list-এ প্রতিটা ধাপে Allow লাগে।
• পরিচিত SCP: ছেড়ে যাওয়া deny, NotAction-সহ Region lock, logging রক্ষা, root আটকানো, role রক্ষা। প্রতিটা জায়গায় ১০টা, ১০,২৪০ অক্ষর; সেপ্টেম্বর ২০২৫ থেকে পুরো IAM language; Principal element নেই।
• RCP (নভেম্বর ২০২৪) সমর্থিত service-এর resource-এ যে কেউ কী করতে পারবে তার সীমা টানে: data perimeter। Declarative policy EC2-র configuration ঠিক করে। backup, AI opt-out, chat আর অন্য policy service সামলায়।
• Tag policy key-এর বানান আর অনুমোদিত মান ঠিক রাখে, নিয়ম-না-মানা tag আটকাতেও পারে, কিন্তু কোনো tag বাধ্যতামূলক করে না: তার জন্য aws:RequestTag / aws:TagKeys-সহ SCP বা Config required-tags।
• Delegated administrator একটা member account থেকে GuardDuty, Security Hub, Config আর অন্যগুলো চালায়। AWS Resource Access Manager subnet, Transit Gateway আর Resolver rule কপি না করে ভাগ করে।

নিজেকে যাচাই করো: Organizations, OU আর SCP৩১টি প্রশ্ন