{"id":266,"date":"2026-04-13T10:20:44","date_gmt":"2026-04-13T10:20:44","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-organizations-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance\/"},"modified":"2026-04-13T10:20:44","modified_gmt":"2026-04-13T10:20:44","slug":"aws-organizations-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-organizations-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance\/","title":{"rendered":"AWS Organizations Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Management and governance"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Management and governance<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>AWS Organizations is an AWS Management and governance service that helps you centrally manage and govern multiple AWS accounts. It provides a structured way to group accounts, apply guardrails, and manage billing across an organization.<\/p>\n\n\n\n<p>In simple terms: <strong>AWS Organizations lets you build an \u201caccount hierarchy\u201d (like folders and subfolders) and enforce organization-wide rules<\/strong>\u2014so teams can move fast without breaking security, compliance, or cost boundaries.<\/p>\n\n\n\n<p>Technically, AWS Organizations is a <strong>global AWS control-plane service<\/strong> that creates an organization with a <strong>management account<\/strong>, <strong>member accounts<\/strong>, <strong>organizational units (OUs)<\/strong>, and <strong>policies<\/strong> (most notably <strong>Service Control Policies\u2014SCPs<\/strong>). It integrates closely with identity (IAM), logging (CloudTrail), security services (Security Hub, GuardDuty, etc.), and landing-zone solutions like <strong>AWS Control Tower<\/strong>.<\/p>\n\n\n\n<p>The main problem it solves is the \u201cmulti-account sprawl\u201d problem: when teams create many AWS accounts for isolation (which is a best practice), it becomes hard to manage access, governance, compliance, and billing consistently. AWS Organizations gives you a centralized governance layer for that multi-account environment.<\/p>\n\n\n\n<blockquote>\n<p>Naming note (current terminology): AWS used to refer to the \u201cmaster account.\u201d The current term is <strong>management account<\/strong>. Member accounts are <strong>member accounts<\/strong> (not \u201cchild\u201d accounts). These are terminology updates, not a different service.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is AWS Organizations?<\/h2>\n\n\n\n<p><strong>Official purpose (what it\u2019s for):<\/strong><br\/>\nAWS Organizations helps you <strong>centrally manage and govern<\/strong> your environment as you grow and scale on AWS. It enables consolidated billing, hierarchical grouping of accounts, and organization-wide policy controls.<\/p>\n\n\n\n<p><strong>Core capabilities:<\/strong>\n&#8211; Create and manage multiple AWS accounts programmatically.\n&#8211; Organize accounts into a hierarchy using <strong>roots<\/strong> and <strong>organizational units (OUs)<\/strong>.\n&#8211; Apply organization-wide governance using <strong>policies<\/strong> (for example <strong>SCPs<\/strong>).\n&#8211; Enable and manage <strong>trusted access<\/strong> with other AWS services (so those services can operate across your organization).\n&#8211; Centralize billing through <strong>consolidated billing<\/strong> and support cost allocation approaches.<\/p>\n\n\n\n<p><strong>Major components:<\/strong>\n&#8211; <strong>Organization<\/strong>: The top-level container.\n&#8211; <strong>Management account<\/strong>: The account that owns the organization and pays the bill under consolidated billing.\n&#8211; <strong>Member accounts<\/strong>: Accounts that are part of the organization.\n&#8211; <strong>Root<\/strong>: The top-most node in the hierarchy (you can have one root; OUs hang under it).\n&#8211; <strong>Organizational units (OUs)<\/strong>: Groupings of accounts used for governance and delegation.\n&#8211; <strong>Policies<\/strong>: Governance documents you attach to the root, OUs, or accounts. The most common are:\n  &#8211; <strong>Service Control Policies (SCPs)<\/strong> to set maximum permissions boundaries for accounts\/OUs.\n  &#8211; Other organization policy types may be available depending on your AWS environment and enabled features (verify current availability in the official docs).<\/p>\n\n\n\n<p><strong>Service type:<\/strong><br\/>\nA <strong>management\/governance control-plane service<\/strong> (not a data-plane service). It doesn\u2019t run your workloads; it governs how accounts and permissions are structured.<\/p>\n\n\n\n<p><strong>Scope (regional\/global):<\/strong><br\/>\nAWS Organizations is considered a <strong>global service<\/strong>. You can use it from the AWS Management Console and APIs without being tied to a single Region in the way compute services are. Many integrated services remain regional (for example, GuardDuty or CloudTrail trails have region-specific behavior), but the organization structure itself is global.<\/p>\n\n\n\n<p><strong>How it fits into the AWS ecosystem:<\/strong>\n&#8211; <strong>Identity foundation:<\/strong> Works with IAM and (commonly) <strong>AWS IAM Identity Center<\/strong> (successor name for AWS Single Sign-On) for workforce identity in a multi-account structure.\n&#8211; <strong>Security foundation:<\/strong> Security services can be delegated administrators across the org (service-dependent).\n&#8211; <strong>Landing zones:<\/strong> <strong>AWS Control Tower<\/strong> uses AWS Organizations under the hood to set up and govern multi-account environments.\n&#8211; <strong>Logging and audit:<\/strong> AWS CloudTrail can be configured for organization-wide visibility (for example, organization trails\u2014verify current requirements in CloudTrail docs).<\/p>\n\n\n\n<p>Official docs entry point:<br\/>\nhttps:\/\/docs.aws.amazon.com\/organizations\/latest\/userguide\/orgs_introduction.html<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use AWS Organizations?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Clear cost ownership and chargeback:<\/strong> Separate accounts per team\/product\/environment and consolidate billing for centralized payment and discounts (where applicable).<\/li>\n<li><strong>Faster onboarding:<\/strong> Create accounts from a controlled pipeline instead of ad-hoc \u201cwho owns what?\u201d processes.<\/li>\n<li><strong>Risk reduction:<\/strong> Avoid \u201cone big account\u201d blast radius and reduce cross-team interference.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Strong isolation boundary:<\/strong> An AWS account is a powerful isolation boundary for IAM, service quotas, and many resource scopes.<\/li>\n<li><strong>Central policy management:<\/strong> Apply SCPs to enforce guardrails across many accounts without managing each account independently.<\/li>\n<li><strong>Standardized structure:<\/strong> Build repeatable patterns for dev\/test\/prod, shared services, and security accounts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Consistent governance at scale:<\/strong> Apply rules once to an OU and have them inherit down the tree.<\/li>\n<li><strong>Delegation patterns:<\/strong> Delegate administration of certain AWS services to specific accounts (service-dependent) without sharing the management account broadly.<\/li>\n<li><strong>Automation-friendly:<\/strong> Use Organizations APIs\/CLI to integrate account provisioning into CI\/CD or service catalog workflows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Preventive controls:<\/strong> SCPs can enforce \u201cthis account can never do X,\u201d even if someone attaches an overly permissive IAM policy locally.<\/li>\n<li><strong>Central auditability:<\/strong> Organizations changes are logged via AWS CloudTrail management events.<\/li>\n<li><strong>Separation of duties:<\/strong> Security teams can operate security tooling in dedicated accounts while application teams operate in separate accounts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Organizations helps you scale governance; it\u2019s not about runtime performance of workloads. The key \u201cscaling\u201d is organizational: more accounts, more teams, more services, more policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You expect <strong>multiple accounts<\/strong> (now or soon).<\/li>\n<li>You need <strong>central governance<\/strong> (SCP guardrails, consistent structure).<\/li>\n<li>You want <strong>consolidated billing<\/strong> with multiple accounts.<\/li>\n<li>You plan to adopt <strong>AWS Control Tower<\/strong> or a landing-zone model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it (or should delay)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You truly only need <strong>one account<\/strong> and don\u2019t expect growth (rare for production).<\/li>\n<li>You can\u2019t accept the operational overhead of multi-account governance yet (though starting early usually reduces long-term pain).<\/li>\n<li>Your organization is constrained by policies requiring separate payers\/contracts that cannot be consolidated (this is uncommon but can happen\u2014verify with AWS Sales\/Support if relevant).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is AWS Organizations used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Finance \/ fintech:<\/strong> Strong separation of duties and strict compliance needs.<\/li>\n<li><strong>Healthcare:<\/strong> Data segregation and auditing.<\/li>\n<li><strong>SaaS and tech:<\/strong> Multi-tenant architectures, internal platform teams, rapid environment creation.<\/li>\n<li><strong>Retail \/ e-commerce:<\/strong> Multiple workloads and teams with clear cost ownership.<\/li>\n<li><strong>Public sector:<\/strong> Strong governance and workload separation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building internal cloud platforms.<\/li>\n<li>DevOps\/SRE teams standardizing environments.<\/li>\n<li>Security engineering \/ GRC teams enforcing preventive controls.<\/li>\n<li>FinOps teams implementing chargeback and spend governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Multi-environment setups:<\/strong> Separate accounts for dev\/test\/stage\/prod.<\/li>\n<li><strong>Shared services model:<\/strong> Dedicated accounts for networking, CI\/CD tooling, logging, and security tooling.<\/li>\n<li><strong>Business-unit segmentation:<\/strong> Each BU gets an OU and multiple accounts.<\/li>\n<li><strong>M&amp;A \/ multi-entity organizations:<\/strong> Separate subsidiaries in separate OUs with consistent guardrails.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production:<\/strong> Almost always used for real governance (SCPs, separation of duties, delegated admins).<\/li>\n<li><strong>Dev\/test:<\/strong> Commonly used to provision ephemeral accounts or sandbox accounts with strict guardrails.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where AWS Organizations is the right tool.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Consolidated billing for many accounts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Multiple AWS accounts create fragmented bills and duplicated admin effort.<\/li>\n<li><strong>Why AWS Organizations fits:<\/strong> Consolidated billing brings accounts under one payer and provides consolidated cost visibility.<\/li>\n<li><strong>Example:<\/strong> A company has 12 product teams with separate AWS accounts; Finance wants a single payer and consolidated reporting.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Organizational unit (OU) structure for environment separation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Dev and prod resources are mixed and risky.<\/li>\n<li><strong>Why it fits:<\/strong> You can create OUs like <code>Dev<\/code>, <code>Test<\/code>, <code>Prod<\/code> and apply different governance policies.<\/li>\n<li><strong>Example:<\/strong> Apply stricter SCPs to <code>Prod<\/code> while allowing broader experimentation in <code>Dev<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Preventive security guardrails with Service Control Policies (SCPs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A team accidentally grants admin access and creates risky public resources.<\/li>\n<li><strong>Why it fits:<\/strong> SCPs define the <strong>maximum allowed permissions<\/strong>, limiting what IAM policies can do.<\/li>\n<li><strong>Example:<\/strong> Deny disabling CloudTrail or deny creating internet gateways in sensitive accounts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Dedicated security tooling accounts (security OU)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Security tools and audit logs are spread across app accounts.<\/li>\n<li><strong>Why it fits:<\/strong> A security OU can host centralized tooling accounts with delegated admin where supported.<\/li>\n<li><strong>Example:<\/strong> One account runs Security Hub\/GuardDuty admin; findings roll up org-wide.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Centralized logging account<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Investigations are slow because logs are distributed and mutable.<\/li>\n<li><strong>Why it fits:<\/strong> Multi-account design allows a dedicated log archive account; Organizations supports org-wide patterns (with CloudTrail\/other tooling).<\/li>\n<li><strong>Example:<\/strong> Centralize CloudTrail logs and retain them with strict access controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Account vending \/ automated account provisioning<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Creating new accounts is slow and inconsistent.<\/li>\n<li><strong>Why it fits:<\/strong> Organizations APIs support programmatic account creation; Control Tower can standardize further.<\/li>\n<li><strong>Example:<\/strong> An internal portal provisions new accounts into the right OU with baseline policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Delegated administration for AWS services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Management account access is too sensitive to share widely.<\/li>\n<li><strong>Why it fits:<\/strong> Many AWS services support <strong>delegated administrator<\/strong> so operations can happen in designated accounts.<\/li>\n<li><strong>Example:<\/strong> Security team manages GuardDuty as delegated admin without daily use of the management account.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Sandbox OU with strict limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Engineers need experimentation but risk cost or security incidents.<\/li>\n<li><strong>Why it fits:<\/strong> Place sandbox accounts into a sandbox OU with SCPs that restrict expensive services or disallow risky configurations.<\/li>\n<li><strong>Example:<\/strong> Deny provisioning of certain instance families or deny creation of internet-facing load balancers (policy design required).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) M&amp;A: keep acquired business isolated but governed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> An acquired company needs autonomy but must meet corporate governance.<\/li>\n<li><strong>Why it fits:<\/strong> Move their accounts into a subsidiary OU and apply baseline policies while allowing BU-specific policies.<\/li>\n<li><strong>Example:<\/strong> Corporate enforces logging and region restrictions; BU controls everything else.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Standardize tag governance (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Cost allocation and inventory are unreliable due to inconsistent tags.<\/li>\n<li><strong>Why it fits:<\/strong> Organizations supports tag governance patterns (policy support depends on AWS features enabled\u2014verify in official docs).<\/li>\n<li><strong>Example:<\/strong> Enforce required tag keys like <code>CostCenter<\/code> and <code>Owner<\/code> for supported services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Control where workloads can run (region guardrails)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Data residency requirements prohibit non-approved Regions.<\/li>\n<li><strong>Why it fits:<\/strong> SCPs can restrict API actions based on requested region (requires careful design).<\/li>\n<li><strong>Example:<\/strong> Only allow <code>us-east-1<\/code> for most services; keep global services functional.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Separate regulated workloads from general workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A PCI\/regulated workload needs strict separation from general product workloads.<\/li>\n<li><strong>Why it fits:<\/strong> Different OUs\/accounts with tailored guardrails and logging\/monitoring patterns.<\/li>\n<li><strong>Example:<\/strong> A <code>PCI<\/code> OU with tight SCPs, restricted networking, and strong logging controls.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 1: Organization and multi-account hierarchy (roots, OUs, accounts)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Creates a hierarchical structure to group AWS accounts.<\/li>\n<li><strong>Why it matters:<\/strong> Governance is easier when applied to groups rather than one account at a time.<\/li>\n<li><strong>Practical benefit:<\/strong> Apply policies to an OU and have them inherited by all accounts within it.<\/li>\n<li><strong>Caveats:<\/strong> OU design becomes foundational\u2014changing it later can be operationally disruptive if policies are tightly coupled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 2: Consolidated billing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Consolidates charges from multiple member accounts into the management account\u2019s bill.<\/li>\n<li><strong>Why it matters:<\/strong> Simplifies payment and can enable consolidated cost views.<\/li>\n<li><strong>Practical benefit:<\/strong> One payer, multiple accounts, consolidated reporting.<\/li>\n<li><strong>Caveats:<\/strong> Billing consolidation is not the same as full cost allocation; you still need tagging, cost categories, and reporting discipline.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 3: Centralized account management (create\/invite\/remove accounts)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you create new AWS accounts or invite existing accounts into the organization.<\/li>\n<li><strong>Why it matters:<\/strong> Standardizes account provisioning and ownership.<\/li>\n<li><strong>Practical benefit:<\/strong> Automate account vending, ensure accounts land in the right OU.<\/li>\n<li><strong>Caveats:<\/strong> Account creation has prerequisites (unique email, phone verification in some cases) and quotas. Account closure has its own lifecycle.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 4: Service Control Policies (SCPs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> SCPs set the <strong>maximum available permissions<\/strong> for accounts\/OUs. They do not grant permissions; they limit what IAM permissions can do.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents entire classes of risky actions even if local IAM policies are overly permissive.<\/li>\n<li><strong>Practical benefit:<\/strong> Implement preventive guardrails (deny disabling logging, restrict Regions, block certain services).<\/li>\n<li><strong>Caveats:<\/strong> SCPs can lock you out of actions if misconfigured. Test in non-production OUs first. Also note that some permissions needed to manage the organization may behave differently; verify specifics in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 5: Policy inheritance and attachment model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Policies can be attached to the root, OUs, or accounts and inherited down the tree.<\/li>\n<li><strong>Why it matters:<\/strong> Enables layered governance (baseline + environment-specific + workload-specific).<\/li>\n<li><strong>Practical benefit:<\/strong> A \u201cbaseline\u201d SCP at root and stricter SCPs at <code>Prod<\/code> OU.<\/li>\n<li><strong>Caveats:<\/strong> Debugging effective permission becomes harder with multiple policies. You need a strong change process.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 6: Delegated administrator (service-dependent)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you designate a member account as an admin for certain AWS services across the organization.<\/li>\n<li><strong>Why it matters:<\/strong> Keeps the management account locked down while enabling central operations.<\/li>\n<li><strong>Practical benefit:<\/strong> Security tooling admin account can manage findings and configs across member accounts.<\/li>\n<li><strong>Caveats:<\/strong> Not every AWS service supports delegated admin. Each service has its own onboarding steps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 7: Trusted access for AWS services (service integrations)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows supported AWS services to integrate with AWS Organizations and perform org-wide operations.<\/li>\n<li><strong>Why it matters:<\/strong> Enables centralized security, compliance, and operations tooling.<\/li>\n<li><strong>Practical benefit:<\/strong> Easier org-wide enablement\/management for supported services.<\/li>\n<li><strong>Caveats:<\/strong> Enabling trusted access is a governance decision; it expands a service\u2019s scope. Review security implications per service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 8: Organization-level visibility and APIs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> APIs to list accounts, OUs, policies, and organizational relationships.<\/li>\n<li><strong>Why it matters:<\/strong> Enables automation, inventory, and continuous governance.<\/li>\n<li><strong>Practical benefit:<\/strong> Build internal tooling that checks if every account is in the right OU with the right guardrails.<\/li>\n<li><strong>Caveats:<\/strong> Like many control-plane APIs, changes may be eventually consistent; design automation to handle retries.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 9: Policy types beyond SCPs (availability varies\u2014verify)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> AWS Organizations supports multiple policy types (SCPs are the most common). Other policy types exist for specific governance domains.<\/li>\n<li><strong>Why it matters:<\/strong> Allows governance beyond just permissions boundaries, depending on your needs and what AWS currently supports.<\/li>\n<li><strong>Practical benefit:<\/strong> Centralize certain governance configurations across accounts.<\/li>\n<li><strong>Caveats:<\/strong> Policy type support and service coverage can change; always confirm in the AWS Organizations User Guide.<\/li>\n<\/ul>\n\n\n\n<p>Reference:<br\/>\nhttps:\/\/docs.aws.amazon.com\/organizations\/latest\/userguide\/orgs_manage_policies.html<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>AWS Organizations is a <strong>control plane<\/strong> that maintains:\n&#8211; An <strong>organization directory<\/strong> (accounts, OUs, roots)\n&#8211; A <strong>policy engine<\/strong> for organization policies (especially SCP evaluation)\n&#8211; <strong>Integration points<\/strong> with other AWS services using trusted access and delegated admin patterns<\/p>\n\n\n\n<p>When a principal (user\/role) in a member account calls an AWS API, AWS evaluates permissions roughly like this:\n1. <strong>Identity-based policies<\/strong> (IAM user\/role policies)\n2. <strong>Resource-based policies<\/strong> (where applicable)\n3. <strong>Permission boundaries \/ session policies<\/strong> (where applicable)\n4. <strong>Organizations SCPs<\/strong> (as an additional \u201cfilter\u201d that can deny actions)\n5. <strong>Other AWS authorization logic<\/strong> (service-specific)<\/p>\n\n\n\n<p>Important: <strong>SCPs do not grant<\/strong> permissions. Even if an SCP allows something, IAM still must allow it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control flow:<\/strong> You create OUs, accounts, and attach policies from the management account (or authorized delegated administrators for certain actions).<\/li>\n<li><strong>Workload\/API flow:<\/strong> Member accounts run workloads normally. AWS Organizations policies influence authorization decisions for those accounts.<\/li>\n<li><strong>Audit flow:<\/strong> Organizations API activity is logged in CloudTrail (management events). Org-wide logging patterns are typically implemented with CloudTrail, Config, and security services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Key integrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Control Tower:<\/strong> Uses Organizations for account factory, OUs, and guardrails (SCP-based and detective controls).<\/li>\n<li><strong>AWS IAM Identity Center:<\/strong> Commonly used with Organizations for centralized workforce access to multiple accounts.<\/li>\n<li><strong>AWS CloudTrail:<\/strong> Logs Organizations API actions; org-wide trails can support centralized logging patterns (see CloudTrail docs).<\/li>\n<li><strong>AWS security services:<\/strong> Many support org integrations and delegated admin (GuardDuty, Security Hub, Inspector, Macie\u2014verify per service).<\/li>\n<li><strong>AWS Billing\/Cost tools:<\/strong> Consolidated billing is foundational for Cost Explorer and other billing visibility features.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>AWS Organizations itself has no data-plane dependencies for your workloads, but multi-account best practices commonly include:\n&#8211; Central logging (S3, CloudTrail, CloudWatch Logs)\n&#8211; Central security tooling (Security Hub, GuardDuty, IAM Identity Center)\n&#8211; Networking patterns (shared VPCs, Transit Gateway) implemented across accounts<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Authentication:<\/strong> Standard AWS authentication (IAM users\/roles, federated identities).<\/li>\n<li><strong>Authorization:<\/strong> Organizations API access is controlled by IAM permissions in the management account. SCPs then affect what member accounts can do in their own accounts.<\/li>\n<li><strong>Separation of duties:<\/strong> Keep the management account highly restricted; use delegated admin accounts and break-glass procedures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<p>AWS Organizations is a control-plane service accessed over AWS public endpoints. No VPC endpoint is typically required (verify current endpoint options in official docs if your environment restricts outbound internet).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable CloudTrail for management events and ensure Organizations events are captured.<\/li>\n<li>Consider organization-wide logging and security baselines (often via Control Tower).<\/li>\n<li>Track policy changes via change management and CI\/CD for policy documents.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Simple architecture diagram<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  A[Management account&lt;br\/&gt;AWS Organizations] --&gt; B[Root]\n  B --&gt; C[OU: Security]\n  B --&gt; D[OU: Workloads]\n  D --&gt; E[Account: Dev]\n  D --&gt; F[Account: Prod]\n  A --&gt; G[SCPs \/ Org Policies]\n  G --&gt; D\n  G --&gt; C\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Production-style architecture diagram<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  subgraph Org[AWS Organization]\n    MA[Management account&lt;br\/&gt;Billing + Org admin]\n    R[Root]\n    OU1[OU: Security]\n    OU2[OU: Shared Services]\n    OU3[OU: Workloads]\n    A1[Log Archive account]\n    A2[Security Tooling account&lt;br\/&gt;Delegated admin where supported]\n    A3[Networking account]\n    P1[Prod app account]\n    D1[Dev app account]\n  end\n\n  MA --&gt; R\n  R --&gt; OU1\n  R --&gt; OU2\n  R --&gt; OU3\n  OU1 --&gt; A1\n  OU1 --&gt; A2\n  OU2 --&gt; A3\n  OU3 --&gt; P1\n  OU3 --&gt; D1\n\n  SCP[SCP baseline + OU-specific SCPs] --&gt; R\n  SCP --&gt; OU1\n  SCP --&gt; OU3\n\n  CT[CloudTrail \/ Audit] --- MA\n  CT --- A1\n  SH[Security services&lt;br\/&gt;(e.g., Security Hub\/GuardDuty)] --- A2\n  ID[AWS IAM Identity Center] --- MA\n  ID --- P1\n  ID --- D1\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/tenancy requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An AWS account that will become the <strong>management account<\/strong> for AWS Organizations.<\/li>\n<li>A valid payment method for the management account (billing must be enabled).<\/li>\n<li>If creating new member accounts: unique email addresses per account.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need IAM permissions in the management account to:\n&#8211; Create and manage an organization (Organizations APIs)\n&#8211; Create OUs, attach policies, and (optionally) create accounts\n&#8211; Create\/assume roles for cross-account verification steps in this lab<\/p>\n\n\n\n<p>AWS-managed IAM policies often used for learning\/labs (review before use):\n&#8211; <code>AWSOrganizationsFullAccess<\/code> (broad)\n&#8211; Additional permissions for IAM and STS actions used in the lab (for example, assuming roles)<\/p>\n\n\n\n<p>In production, prefer least privilege and separate roles for:\n&#8211; Org admins\n&#8211; Billing admins\n&#8211; Security admins\n&#8211; Account provisioning pipeline<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Organizations itself is typically <strong>no additional charge<\/strong>, but member accounts can incur costs when services are used.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS CLI v2 installed and configured on your workstation, or use <strong>AWS CloudShell<\/strong>.<\/li>\n<li>AWS CLI install: https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/li>\n<li>Permissions to run <code>aws organizations<\/code> commands.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Organizations is a <strong>global service<\/strong>, but AWS Management Console still asks you to pick a Region; the org features are not Region-bound in the same way as compute\/storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>AWS Organizations has service quotas (examples include limits for number of accounts, OUs, SCP size, etc.). Do not rely on memory\u2014check the current quotas here:<br\/>\nhttps:\/\/docs.aws.amazon.com\/organizations\/latest\/userguide\/orgs_reference_limits.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services (optional but common)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS CloudTrail for audit logging<\/li>\n<li>AWS IAM Identity Center for workforce SSO across accounts<\/li>\n<li>AWS Control Tower for landing zone automation (optional)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Current pricing model (accurate, non-fabricated)<\/h3>\n\n\n\n<p>AWS Organizations is generally offered <strong>at no additional charge<\/strong>. You pay for the AWS resources and services you use in each account (and for any integrated services you enable).<\/p>\n\n\n\n<p>Verify on the official pricing page (or Organizations product page links):<br\/>\n&#8211; AWS Organizations product page: https:\/\/aws.amazon.com\/organizations\/<br\/>\n&#8211; AWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/p>\n\n\n\n<blockquote>\n<p>If pricing or special features change over time, verify the current model in official AWS pricing documentation.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions<\/h3>\n\n\n\n<p>While AWS Organizations itself is typically free, your total cost is driven by:\n&#8211; Number of accounts (indirectly increases:\n  &#8211; Logging costs (CloudTrail, S3 storage)\n  &#8211; Security service costs (GuardDuty, Security Hub, etc.)\n  &#8211; Compliance tooling costs (Config, etc.)\n&#8211; Policy-driven architecture decisions:\n  &#8211; Centralized logging (S3, CloudWatch Logs, KMS)\n  &#8211; Cross-account networking (Transit Gateway, VPC sharing, etc.)\n&#8211; Automation and operations:\n  &#8211; CI\/CD pipelines, configuration management, inventory tooling<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>AWS Organizations is not commonly described with a \u201cfree tier\u201d because it\u2019s generally not billed directly. Your member accounts may use the AWS Free Tier for certain services depending on eligibility.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CloudTrail:<\/strong> Organization-wide logging increases event volume and storage.<\/li>\n<li><strong>AWS Config:<\/strong> Multi-account compliance at scale can become a notable cost driver.<\/li>\n<li><strong>Security services:<\/strong> Enabling org-wide threat detection across accounts increases per-account\/per-Region charges.<\/li>\n<li><strong>KMS:<\/strong> Encrypting centralized logs can add KMS request costs.<\/li>\n<li><strong>Data transfer:<\/strong> Centralized logging and cross-account architectures can create inter-Region or inter-AZ transfer costs (depending on design).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<p>AWS Organizations doesn\u2019t move your workload data. But the operating model it enables (central logs, central security, shared services) can cause:\n&#8211; Cross-account and cross-Region log delivery costs\n&#8211; VPC networking and routing costs (TGW, NAT, inter-Region peering, etc.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with a <strong>minimal account set<\/strong> (for example: management, security, logging, shared services, workloads).<\/li>\n<li>Use SCPs to <strong>reduce accidental spend<\/strong> (for example, blocking certain expensive services in sandbox).<\/li>\n<li>Centralize logs, but apply lifecycle policies and retention aligned to compliance.<\/li>\n<li>Use cost allocation tags and cost categories consistently from the start.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A learning setup can be near-zero incremental cost if you:\n&#8211; Create OUs and SCPs only (no workload resources)\n&#8211; Avoid enabling paid security services org-wide\n&#8211; Avoid storing logs for long periods<\/p>\n\n\n\n<p>Costs appear when you create billable resources (EC2, NAT Gateways, extensive CloudTrail data events, Config rules, etc.).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, your cost model typically includes:\n&#8211; Central logging storage + KMS encryption + lifecycle\n&#8211; Security tooling across accounts\/Regions\n&#8211; CI\/CD and shared services accounts\n&#8211; Networking hub\/spoke and egress controls<\/p>\n\n\n\n<p>Because pricing is Region- and usage-dependent, use the <strong>AWS Pricing Calculator<\/strong> and service pricing pages for each integrated service.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create a basic multi-account governance structure with AWS Organizations:\n1. Confirm or create an organization.\n2. Create an OU structure.\n3. Create a member account (or use an existing one).\n4. Create and attach an SCP that restricts API calls to a single allowed Region (carefully designed).\n5. Validate the SCP by attempting actions in allowed vs disallowed Regions.\n6. Clean up.<\/p>\n\n\n\n<p>This lab focuses on AWS Organizations itself (Management and governance). It avoids expensive resources and keeps risk low, but <strong>SCPs can break access<\/strong> if misapplied\u2014follow the steps exactly and test on a non-production account.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Environment:<\/strong> One management account + one member account.<\/li>\n<li><strong>Tools:<\/strong> AWS CLI v2 (CloudShell is fine).<\/li>\n<li><strong>Outcome:<\/strong> You will have:<\/li>\n<li>An OU called <code>Workloads-Lab<\/code><\/li>\n<li>A member account placed into that OU<\/li>\n<li>An SCP attached to that OU that denies actions in non-approved Regions (with safeguards)<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Important: Region-restriction SCPs are subtle. This lab uses <code>StringNotEqualsIfExists<\/code> to avoid denying global services when the Region context key is absent. Always verify against official IAM condition key behavior.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Configure AWS CLI and confirm identity<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Open <strong>AWS CloudShell<\/strong> in the management account, or use your local terminal with AWS CLI configured.<\/p>\n<\/li>\n<li>\n<p>Confirm who you are:<\/p>\n<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws sts get-caller-identity\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see the <code>Account<\/code> ID of your management account identity and an ARN for your IAM user\/role.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Check if AWS Organizations is already enabled<\/h3>\n\n\n\n<p>Run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws organizations describe-organization\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong>\n&#8211; If you already have an organization, you\u2019ll see details including the organization ID (like <code>o-xxxxxxxxxx<\/code>) and feature set.\n&#8211; If you get an error such as <code>AWSOrganizationsNotInUseException<\/code>, then you don\u2019t have an org yet.<\/p>\n\n\n\n<p>If you don\u2019t have an org, create one:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws organizations create-organization --feature-set ALL\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The organization is created with <strong>ALL<\/strong> features enabled.<\/p>\n\n\n\n<blockquote>\n<p>Notes:\n&#8211; AWS Organizations has two primary modes: consolidated billing only vs \u201cAll features.\u201d Most governance features (like SCPs) require <strong>All features<\/strong>.\n&#8211; If you are adopting AWS Control Tower, it also expects an AWS Organizations foundation.<\/p>\n<\/blockquote>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws organizations describe-organization\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create an OU for the lab<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Get the Root ID:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations list-roots\n<\/code><\/pre>\n\n\n\n<p>Copy the <code>Id<\/code> value (example: <code>r-xxxx<\/code>).<\/p>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Create an OU named <code>Workloads-Lab<\/code> under the root:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">ROOT_ID=\"r-xxxx\"   # replace with your root id\naws organizations create-organizational-unit \\\n  --parent-id \"$ROOT_ID\" \\\n  --name \"Workloads-Lab\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You get an OU object with an <code>Id<\/code> like <code>ou-xxxx-yyyyyyyy<\/code>.<\/p>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Store the OU ID for later:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">OU_ID=\"ou-xxxx-yyyyyyyy\"  # replace with your OU id\n<\/code><\/pre>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws organizations list-organizational-units-for-parent --parent-id \"$ROOT_ID\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create (or attach) a member account<\/h3>\n\n\n\n<p>You have two options:<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option A (recommended for a real test): Create a new member account<\/h4>\n\n\n\n<p>Creating accounts is realistic but can take time and requires a unique email address.<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws organizations create-account \\\n  --email \"unique-email@example.com\" \\\n  --account-name \"org-lab-member-1\" \\\n  --role-name \"OrganizationAccountAccessRole\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You get a <code>CreateAccountStatus<\/code> with an <code>Id<\/code>.<\/p>\n\n\n\n<p>Account creation is asynchronous. Poll until it succeeds:<\/p>\n\n\n\n<pre><code class=\"language-bash\">STATUS_ID=\"car-xxxxxxx\"  # replace with the returned status Id\naws organizations describe-create-account-status --create-account-request-id \"$STATUS_ID\"\n<\/code><\/pre>\n\n\n\n<p>When status becomes <code>SUCCEEDED<\/code>, note the new <code>AccountId<\/code>.<\/p>\n\n\n\n<p>List accounts to confirm:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws organizations list-accounts\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Option B: Invite an existing AWS account into the org<\/h4>\n\n\n\n<p>If you already have a separate AWS account you control, you can invite it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws organizations invite-account-to-organization \\\n  --target '{\"Type\":\"ACCOUNT\",\"Id\":\"123456789012\"}' \\\n  --notes \"Org lab invite\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> An invitation is sent. You must accept it from the invited account (console or CLI).<br\/>\nAcceptance is performed in the invited account (verify steps in official docs):<br\/>\nhttps:\/\/docs.aws.amazon.com\/organizations\/latest\/userguide\/orgs_manage_accounts_invites.html<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Move the member account into the OU<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Identify the member account ID (from Step 4). Set variables:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">MEMBER_ACCOUNT_ID=\"123456789012\"  # replace\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Determine the current parent of that account (often the root):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations list-parents --child-id \"$MEMBER_ACCOUNT_ID\"\n<\/code><\/pre>\n\n\n\n<p>Set:<\/p>\n\n\n\n<pre><code class=\"language-bash\">CURRENT_PARENT_ID=\"r-xxxx\"  # replace with the returned parent Id\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Move account into <code>Workloads-Lab<\/code> OU:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations move-account \\\n  --account-id \"$MEMBER_ACCOUNT_ID\" \\\n  --source-parent-id \"$CURRENT_PARENT_ID\" \\\n  --destination-parent-id \"$OU_ID\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> No output on success.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws organizations list-accounts-for-parent --parent-id \"$OU_ID\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create an SCP that restricts Regions (lab-safe pattern)<\/h3>\n\n\n\n<p>This SCP denies actions when the requested region is not <code>us-east-1<\/code>. It uses <code>StringNotEqualsIfExists<\/code> to reduce impact on global services.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create a policy document file <code>deny-non-us-east-1.json<\/code>:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; deny-non-us-east-1.json &lt;&lt; 'EOF'\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"DenyRequestsOutsideUsEast1\",\n      \"Effect\": \"Deny\",\n      \"Action\": \"*\",\n      \"Resource\": \"*\",\n      \"Condition\": {\n        \"StringNotEqualsIfExists\": {\n          \"aws:RequestedRegion\": \"us-east-1\"\n        }\n      }\n    }\n  ]\n}\nEOF\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Create the SCP in AWS Organizations:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations create-policy \\\n  --name \"DenyNonUsEast1Lab\" \\\n  --description \"LAB: Deny API actions outside us-east-1 using RequestedRegion condition\" \\\n  --type \"SERVICE_CONTROL_POLICY\" \\\n  --content file:\/\/deny-non-us-east-1.json\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Output includes a policy <code>Id<\/code> like <code>p-xxxxxxx<\/code>.<\/p>\n\n\n\n<p>Set:<\/p>\n\n\n\n<pre><code class=\"language-bash\">SCP_ID=\"p-xxxxxxx\"  # replace\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Attach the SCP to the lab OU<\/h3>\n\n\n\n<p>Attach:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws organizations attach-policy --policy-id \"$SCP_ID\" --target-id \"$OU_ID\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> No output on success.<\/p>\n\n\n\n<p>Verify attachment:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws organizations list-policies-for-target --target-id \"$OU_ID\" --filter SERVICE_CONTROL_POLICY\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Validate by assuming into the member account and testing Regions<\/h3>\n\n\n\n<p>To test the SCP effect, assume the cross-account role in the member account (created by Organizations account creation flow if you used Option A; for existing accounts, ensure a role exists and trust is configured).<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Assume role:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">ROLE_ARN=\"arn:aws:iam::${MEMBER_ACCOUNT_ID}:role\/OrganizationAccountAccessRole\"\n\naws sts assume-role \\\n  --role-arn \"$ROLE_ARN\" \\\n  --role-session-name \"org-scp-lab\"\n<\/code><\/pre>\n\n\n\n<p>Copy the returned <code>AccessKeyId<\/code>, <code>SecretAccessKey<\/code>, and <code>SessionToken<\/code>.<\/p>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Export temporary credentials (in the same shell):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">export AWS_ACCESS_KEY_ID=\"ASIA...\"\nexport AWS_SECRET_ACCESS_KEY=\"...\"\nexport AWS_SESSION_TOKEN=\"...\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Test an allowed Region action (example: list S3 buckets is global-ish; for a clearer region test, create a bucket in us-east-1 vs us-west-2).<br\/>\nFirst, try creating an S3 bucket in <strong>us-east-1<\/strong> (allowed). Bucket names must be globally unique\u2014change the suffix:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">BUCKET_ALLOWED=\"org-scp-lab-allowed-$(date +%s)\"\naws s3api create-bucket \\\n  --bucket \"$BUCKET_ALLOWED\" \\\n  --region us-east-1\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Bucket creation succeeds.<\/p>\n\n\n\n<ol class=\"wp-block-list\" start=\"4\">\n<li>Now try creating a bucket in <strong>us-west-2<\/strong> (should be denied by SCP). Again, use a unique name:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">BUCKET_DENIED=\"org-scp-lab-denied-$(date +%s)\"\naws s3api create-bucket \\\n  --bucket \"$BUCKET_DENIED\" \\\n  --region us-west-2 \\\n  --create-bucket-configuration LocationConstraint=us-west-2\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The request fails with an <strong>explicit deny<\/strong>. The error often indicates an authorization failure due to an explicit deny (from Organizations\/SCP evaluation).<\/p>\n\n\n\n<blockquote>\n<p>If you don\u2019t see an explicit deny, confirm:\n&#8211; The account is in the correct OU\n&#8211; The SCP is attached to that OU\n&#8211; The organization is using \u201cAll features\u201d\n&#8211; Your request really targets <code>us-west-2<\/code><\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use these checks back in the management account context (remove the temporary creds or open a new shell).<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Confirm the account\u2019s parent OU:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations list-parents --child-id \"$MEMBER_ACCOUNT_ID\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Confirm SCPs attached to the OU:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations list-policies-for-target --target-id \"$OU_ID\" --filter SERVICE_CONTROL_POLICY\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Confirm the SCP content (fetch and review):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations describe-policy --policy-id \"$SCP_ID\"\n<\/code><\/pre>\n\n\n\n<p>You should see the JSON policy content you created.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and realistic fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong><code>AWSOrganizationsNotInUseException<\/code><\/strong>\n&#8211; <strong>Cause:<\/strong> Organization not created yet.\n&#8211; <strong>Fix:<\/strong> Run <code>create-organization --feature-set ALL<\/code> in the management account.<\/p>\n<\/li>\n<li>\n<p><strong>SCP seems to have no effect<\/strong>\n&#8211; <strong>Cause:<\/strong> The org might not have \u201cAll features,\u201d the account isn\u2019t in the target OU, or the policy isn\u2019t attached.\n&#8211; <strong>Fix:<\/strong> Verify feature set with <code>describe-organization<\/code>, confirm OU placement with <code>list-parents<\/code>, and confirm attachment with <code>list-policies-for-target<\/code>.<\/p>\n<\/li>\n<li>\n<p><strong>AssumeRole fails (<code>AccessDenied<\/code>)<\/strong>\n&#8211; <strong>Cause:<\/strong> The role may not exist in the member account, or trust\/permissions aren\u2019t correct.\n&#8211; <strong>Fix:<\/strong> If you created the account via Organizations and specified <code>--role-name OrganizationAccountAccessRole<\/code>, it should exist. For invited accounts, create a cross-account role in the member account and allow the management account principal to assume it.<\/p>\n<\/li>\n<li>\n<p><strong>Bucket creation fails in us-east-1<\/strong>\n&#8211; <strong>Cause:<\/strong> Bucket name not unique or S3 policy restrictions.\n&#8211; <strong>Fix:<\/strong> Use a unique name; ensure you\u2019re using correct regional parameters.<\/p>\n<\/li>\n<li>\n<p><strong>You accidentally blocked needed actions with SCP<\/strong>\n&#8211; <strong>Cause:<\/strong> SCP denies too broadly.\n&#8211; <strong>Fix:<\/strong> Detach the SCP from the OU from the management account, or move the account out of that OU. Always test on non-prod first.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Cleanup is important to avoid confusion later.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>If still assumed into the member role, unset temporary credentials:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Delete the S3 bucket created in us-east-1 (if created):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws s3api delete-bucket --bucket \"$BUCKET_ALLOWED\" --region us-east-1\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Detach the SCP:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations detach-policy --policy-id \"$SCP_ID\" --target-id \"$OU_ID\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"4\">\n<li>Delete the SCP:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations delete-policy --policy-id \"$SCP_ID\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"5\">\n<li>(Optional) Move the member account back to root if desired:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations move-account \\\n  --account-id \"$MEMBER_ACCOUNT_ID\" \\\n  --source-parent-id \"$OU_ID\" \\\n  --destination-parent-id \"$ROOT_ID\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"6\">\n<li>Delete the OU (must be empty):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws organizations delete-organizational-unit --organizational-unit-id \"$OU_ID\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"7\">\n<li>\n<p>If you created a member account just for the lab:\n&#8211; You can remove it from the organization, but <strong>closing an AWS account<\/strong> is a separate process and has implications. Follow AWS official guidance for account closure and be cautious.<\/p>\n<\/li>\n<li>\n<p>If this entire organization was only for a lab and you want to delete it:\n&#8211; You must remove\/close member accounts so only the management account remains, then delete the organization (verify exact requirements in official docs):<br\/>\nhttps:\/\/docs.aws.amazon.com\/organizations\/latest\/userguide\/orgs_manage_org_delete.html<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Adopt a multi-account strategy early.<\/strong> Retrofitting governance into a single \u201cmega account\u201d is painful.<\/li>\n<li><strong>Use a standard OU layout<\/strong> aligned to business and risk:<\/li>\n<li>Common pattern: <code>Security<\/code>, <code>SharedServices<\/code>, <code>Workloads<\/code> with sub-OUs like <code>Prod<\/code>, <code>NonProd<\/code>, <code>Sandbox<\/code>.<\/li>\n<li><strong>Prefer separate accounts<\/strong> for:<\/li>\n<li>Logging (log archive)<\/li>\n<li>Security tooling<\/li>\n<li>Shared networking<\/li>\n<li>CI\/CD tooling<\/li>\n<li><strong>Keep the management account special:<\/strong> Use it primarily for organization management and billing, not for hosting workloads.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use AWS IAM Identity Center<\/strong> (where appropriate) for workforce access across accounts; avoid long-lived IAM users.<\/li>\n<li><strong>Least privilege for Organizations administration:<\/strong> Separate roles for:<\/li>\n<li>Organization admins<\/li>\n<li>Account provisioning operators<\/li>\n<li>Security policy admins<\/li>\n<li><strong>Use SCPs as guardrails, not as your whole IAM strategy.<\/strong><\/li>\n<li><strong>Test SCPs in a sandbox OU first.<\/strong> SCP mistakes can block business operations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use multiple accounts to improve <strong>cost attribution<\/strong>.<\/li>\n<li>Apply consistent tagging strategies and cost categories (outside Organizations itself).<\/li>\n<li>Create sandbox accounts and use SCPs to reduce accidental high-cost provisioning (careful design required).<\/li>\n<li>Centralize expensive tooling thoughtfully; evaluate per-account enablement costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<p>AWS Organizations is not a workload performance service. The key \u201cperformance\u201d best practice is <strong>operational scalability<\/strong>:\n&#8211; Use automation (CLI\/SDK\/IaC) for repetitive organization tasks.\n&#8211; Avoid manual, one-off policy changes in production.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat org governance changes like production changes: reviews, approvals, rollback plans.<\/li>\n<li>Use break-glass access patterns for emergencies (separate accounts\/roles, strong MFA, auditing).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable CloudTrail and log all Organizations changes.<\/li>\n<li>Document OU\/policy intent clearly (policy descriptions, internal docs).<\/li>\n<li>Keep a policy repository (version control) for SCP JSON documents.<\/li>\n<li>Use delegated admins for supported services instead of broad access to the management account.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Name OUs and accounts consistently:<\/li>\n<li><code>prod-&lt;app&gt;<\/code>, <code>nonprod-&lt;app&gt;<\/code>, <code>shared-network<\/code>, <code>security-tooling<\/code>, <code>log-archive<\/code><\/li>\n<li>Decide early whether OU structure maps to:<\/li>\n<li>environments (prod\/non-prod), or<\/li>\n<li>business units, or<\/li>\n<li>risk tiers<br\/>\n  Mixing all three without a plan can lead to confusion.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Organizations administration is controlled by <strong>IAM permissions in the management account<\/strong>.<\/li>\n<li>SCPs affect what principals in member accounts can do (and can enforce preventive controls).<\/li>\n<li>Use role-based access and federation for human access; minimize long-lived credentials.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<p>AWS Organizations doesn\u2019t store your application data, so encryption topics mainly apply to what you build around it:\n&#8211; Encrypt centralized logs (S3 + KMS) in log archive accounts.\n&#8211; Encrypt security findings storage where applicable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<p>Organizations is accessed through AWS APIs. Your main exposure is:\n&#8211; Who can call Organizations APIs?\n&#8211; Who can change SCPs\/OUs\/accounts?<\/p>\n\n\n\n<p>Restrict these actions heavily and require strong authentication.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Don\u2019t embed account access keys in automation. Use:<\/li>\n<li>STS assume-role with short-lived credentials<\/li>\n<li>IAM Identity Center for human access<\/li>\n<li>Store sensitive automation secrets in AWS Secrets Manager or similar services, not in code repositories.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure CloudTrail logs Organizations actions.<\/li>\n<li>Consider centralizing CloudTrail logs in a dedicated log archive account.<\/li>\n<li>Monitor for changes to:<\/li>\n<li>SCP attachments<\/li>\n<li>account movement between OUs<\/li>\n<li>delegated admin registration<\/li>\n<li>trusted access enablement<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>Organizations helps implement preventive controls, but compliance requires broader controls:\n&#8211; Detective controls (Config, Security Hub, etc.)\n&#8211; Evidence retention (logs)\n&#8211; Separation of duties and access reviews<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Using the management account for day-to-day workload operations.<\/li>\n<li>Attaching overly broad \u201cdeny\u201d SCPs to the wrong OU.<\/li>\n<li>No break-glass path for production incidents.<\/li>\n<li>Enabling service integrations\/trusted access without security review.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Implement a landing zone (AWS Control Tower or an equivalent custom design) for consistent baselines.<\/li>\n<li>Separate duties across accounts and roles:<\/li>\n<li>Security OU<\/li>\n<li>Logging account<\/li>\n<li>Shared services\/networking account<\/li>\n<li>Maintain policy-as-code for SCPs with peer review.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Use these as a checklist before production rollout.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits exist for:<\/li>\n<li>number of accounts per organization<\/li>\n<li>number of OUs and nesting depth<\/li>\n<li>number and size of policies (SCP size limits)<\/li>\n<li>API request rates<br\/>\nCheck official quotas: https:\/\/docs.aws.amazon.com\/organizations\/latest\/userguide\/orgs_reference_limits.html<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Organizations is global, but <strong>the services you govern are regional<\/strong>. SCP \u201cregion restrictions\u201d must be carefully designed and tested.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises (indirect)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Organizations itself is usually free, but <strong>org-wide enablement<\/strong> of:<\/li>\n<li>CloudTrail data events<\/li>\n<li>AWS Config rules<\/li>\n<li>Security services<br\/>\ncan scale costs quickly across accounts and Regions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some AWS services integrate with Organizations only when:<\/li>\n<li>\u201cAll features\u201d is enabled<\/li>\n<li>trusted access is enabled<\/li>\n<li>delegated admin is configured<br\/>\nAlways follow the specific service\u2019s setup guide.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>SCP debugging<\/strong> can be difficult when multiple SCPs are inherited. Keep policies modular and well documented.<\/li>\n<li>Account creation and moves may be <strong>eventually consistent<\/strong>\u2014automation should retry.<\/li>\n<li>Invited accounts require acceptance and may have constraints if they are already in another organization.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating from a single account to multi-account often requires:<\/li>\n<li>refactoring IAM and CI\/CD<\/li>\n<li>redesigning networking<\/li>\n<li>rethinking logging and incident response<\/li>\n<li>Migrating existing independent accounts into one organization requires:<\/li>\n<li>aligning guardrails<\/li>\n<li>reconciling billing ownership<\/li>\n<li>handling service-linked roles and delegated administration transitions<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The management account has special significance; avoid relying on assumptions. Confirm behaviors (especially around SCP effects and billing responsibilities) in official docs for your exact setup.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>AWS Organizations is the native AWS solution for multi-account management and governance. Alternatives are typically:\n&#8211; Other AWS governance services that complement Organizations\n&#8211; Equivalent constructs in other cloud providers\n&#8211; Self-managed processes (manual accounts, scripts) that don\u2019t provide the same control-plane governance<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>AWS Organizations<\/strong><\/td>\n<td>Multi-account governance and billing on AWS<\/td>\n<td>Native integration, OU hierarchy, SCP guardrails, consolidated billing<\/td>\n<td>Requires planning; SCP mistakes can be disruptive<\/td>\n<td>Any serious multi-account AWS environment<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Control Tower<\/strong><\/td>\n<td>Landing zone + guardrails + account factory<\/td>\n<td>Opinionated best practices; automates org setup; guardrails<\/td>\n<td>Less flexible than fully custom; adds operational model<\/td>\n<td>You want a standardized landing zone quickly<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS IAM (single account)<\/strong><\/td>\n<td>Small single-account setups<\/td>\n<td>Simple; fewer moving parts<\/td>\n<td>Doesn\u2019t scale; weak isolation; no OU\/SCP layer<\/td>\n<td>Only for very small or temporary environments<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Resource Access Manager (RAM)<\/strong><\/td>\n<td>Sharing resources across AWS accounts<\/td>\n<td>Makes multi-account sharing easier<\/td>\n<td>Not a replacement for governance and billing<\/td>\n<td>Use alongside Organizations for cross-account sharing<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Management Groups + Azure Policy<\/strong><\/td>\n<td>Azure multi-subscription governance<\/td>\n<td>Strong policy governance in Azure<\/td>\n<td>Different cloud, different primitives<\/td>\n<td>If your platform is Microsoft Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud Organization\/Folder\/Projects + Org Policy<\/strong><\/td>\n<td>GCP governance<\/td>\n<td>Strong org\/folder policies in GCP<\/td>\n<td>Different cloud model<\/td>\n<td>If your platform is Google Cloud<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed (manual multi-account)<\/strong><\/td>\n<td>Very small setups avoiding centralized governance<\/td>\n<td>Low initial complexity<\/td>\n<td>Lacks centralized controls, error-prone<\/td>\n<td>Only if you cannot use Organizations (rare)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated company with strict governance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial services enterprise has 200+ AWS accounts across multiple teams. They need strict preventive controls, centralized audit logging, and separation of duties for compliance.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>AWS Organizations with OUs: <code>Security<\/code>, <code>SharedServices<\/code>, <code>Workloads\/Prod<\/code>, <code>Workloads\/NonProd<\/code>, <code>Sandbox<\/code><\/li>\n<li>Dedicated accounts:<ul>\n<li><code>log-archive<\/code> (central S3 for CloudTrail\/Config logs)<\/li>\n<li><code>security-tooling<\/code> (delegated admin for supported services)<\/li>\n<li><code>network-hub<\/code> (shared networking constructs)<\/li>\n<\/ul>\n<\/li>\n<li>SCPs:<ul>\n<li>Baseline at root: deny disabling essential logging\/security baselines (carefully designed)<\/li>\n<li><code>Prod<\/code> OU: tighter restrictions (regions, approved services)<\/li>\n<li><code>Sandbox<\/code> OU: cost\/risk containment guardrails<\/li>\n<\/ul>\n<\/li>\n<li><strong>Why AWS Organizations was chosen:<\/strong> It\u2019s the AWS-native governance layer that integrates with security and identity tooling and scales to hundreds of accounts.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced risk of unauthorized actions through SCP guardrails<\/li>\n<li>Clearer audit and incident response via centralized logging<\/li>\n<li>Faster account provisioning with consistent baselines<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: fast-growing SaaS with cost visibility needs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup started in one AWS account. As customers and teams grew, billing became confusing and permissions got messy.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>AWS Organizations with OUs: <code>Workloads<\/code>, <code>Sandbox<\/code><\/li>\n<li>Accounts:<ul>\n<li><code>prod<\/code> (production workloads)<\/li>\n<li><code>nonprod<\/code> (dev\/test)<\/li>\n<li><code>shared<\/code> (CI\/CD, container registry, shared tools)<\/li>\n<\/ul>\n<\/li>\n<li>Minimal SCPs:<ul>\n<li>Deny a short list of risky actions in nonprod\/sandbox (tested)<\/li>\n<\/ul>\n<\/li>\n<li><strong>Why AWS Organizations was chosen:<\/strong> Multi-account provides isolation and cost ownership without building a custom governance system.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Clean separation between environments<\/li>\n<li>Easier cost tracking per environment\/team<\/li>\n<li>Reduced chance of dev changes impacting production<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is AWS Organizations the same as AWS Control Tower?<\/strong><br\/>\nNo. <strong>AWS Organizations<\/strong> is the core multi-account governance\/billing service. <strong>AWS Control Tower<\/strong> builds on Organizations to provide an opinionated landing zone, guardrails, and account provisioning automation.<\/p>\n\n\n\n<p>2) <strong>Do SCPs grant permissions?<\/strong><br\/>\nNo. SCPs only <strong>limit<\/strong> what permissions can be used in an account. IAM policies still must allow the action.<\/p>\n\n\n\n<p>3) <strong>Can an SCP lock me out of an account?<\/strong><br\/>\nIt can block actions broadly and disrupt operations. Use careful testing, staged rollouts, and break-glass procedures.<\/p>\n\n\n\n<p>4) <strong>Is AWS Organizations regional?<\/strong><br\/>\nIt\u2019s generally treated as a <strong>global<\/strong> service, but the services you manage are regional and may behave differently by Region.<\/p>\n\n\n\n<p>5) <strong>Do I need multiple AWS accounts?<\/strong><br\/>\nNot strictly, but multi-account is a well-established AWS best practice for isolation, governance, and cost attribution.<\/p>\n\n\n\n<p>6) <strong>What\u2019s the \u201cmanagement account\u201d?<\/strong><br\/>\nThe account that owns the organization and is responsible for organization administration and consolidated billing.<\/p>\n\n\n\n<p>7) <strong>Can I change the management account later?<\/strong><br\/>\nChanging payer\/management arrangements is non-trivial and may have constraints. Verify current AWS-supported processes in official documentation if you need this.<\/p>\n\n\n\n<p>8) <strong>What\u2019s an OU used for?<\/strong><br\/>\nTo group accounts and apply policies (like SCPs) and governance consistently to that group.<\/p>\n\n\n\n<p>9) <strong>How do invited accounts work?<\/strong><br\/>\nYou can invite existing AWS accounts to join your organization. They must accept the invitation, and there are constraints if they\u2019re already in another organization.<\/p>\n\n\n\n<p>10) <strong>Is AWS Organizations free?<\/strong><br\/>\nAWS Organizations is typically <strong>no additional charge<\/strong>, but the services you enable and resources you run in member accounts are billed normally. Verify current pricing in official AWS sources.<\/p>\n\n\n\n<p>11) <strong>How does AWS Organizations relate to IAM Identity Center?<\/strong><br\/>\nOrganizations provides the multi-account structure; IAM Identity Center can provide centralized workforce access into those accounts.<\/p>\n\n\n\n<p>12) <strong>Should I run workloads in the management account?<\/strong><br\/>\nBest practice is generally <strong>no<\/strong>. Keep it for org administration and billing; use separate workload accounts.<\/p>\n\n\n\n<p>13) <strong>Can SCPs enforce tagging?<\/strong><br\/>\nSCPs are not a general-purpose \u201ctag enforcement engine.\u201d Tag governance depends on AWS capabilities and services. Organizations may support tag-related policies depending on current features\u2014verify in official docs.<\/p>\n\n\n\n<p>14) <strong>How do I audit changes to OUs and SCPs?<\/strong><br\/>\nUse AWS CloudTrail management event logs and centralize them for retention and monitoring.<\/p>\n\n\n\n<p>15) <strong>What\u2019s the fastest way to start with a secure multi-account setup?<\/strong><br\/>\nFor many teams, AWS Control Tower is the fastest standardized approach. If you need a custom landing zone, start with AWS Organizations plus a documented OU\/policy model and strong logging\/security baselines.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn AWS Organizations<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>AWS Organizations User Guide \u2013 Introduction<\/td>\n<td>Core concepts, terminology, workflows<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>AWS Organizations \u2013 Managing accounts<\/td>\n<td>Account creation\/invites\/moves in depth<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>AWS Organizations \u2013 Policies and SCPs<\/td>\n<td>Authoritative SCP behavior and policy types<\/td>\n<\/tr>\n<tr>\n<td>Official reference<\/td>\n<td>AWS Organizations service quotas\/limits<\/td>\n<td>Prevent surprises when scaling<\/td>\n<\/tr>\n<tr>\n<td>Official product page<\/td>\n<td>AWS Organizations product page<\/td>\n<td>High-level capabilities and official entry points<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>AWS Pricing Calculator<\/td>\n<td>Estimate integrated service costs across accounts<\/td>\n<\/tr>\n<tr>\n<td>Official IAM docs<\/td>\n<td>IAM JSON policy elements + condition keys<\/td>\n<td>Needed to write correct SCP patterns<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>AWS Control Tower documentation<\/td>\n<td>How Organizations is used in landing zones<\/td>\n<\/tr>\n<tr>\n<td>Videos<\/td>\n<td>AWS YouTube channel (search \u201cAWS Organizations\u201d and \u201cSCP\u201d)<\/td>\n<td>Walkthroughs and best practices from AWS<\/td>\n<\/tr>\n<tr>\n<td>Community (reputable)<\/td>\n<td>AWS Blogs (search Organizations, SCP, multi-account)<\/td>\n<td>Practical patterns and design considerations<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<p>Helpful official URLs (entry points):\n&#8211; AWS Organizations docs: https:\/\/docs.aws.amazon.com\/organizations\/latest\/userguide\/\n&#8211; Organizations limits: https:\/\/docs.aws.amazon.com\/organizations\/latest\/userguide\/orgs_reference_limits.html\n&#8211; AWS Organizations product page: https:\/\/aws.amazon.com\/organizations\/\n&#8211; AWS Pricing Calculator: https:\/\/calculator.aws\/#\/\n&#8211; IAM policy reference: https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/reference_policies_elements.html<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>AWS governance, DevOps, automation, cloud operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>DevOps fundamentals, tooling, governance basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams<\/td>\n<td>CloudOps, monitoring, governance operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs and reliability-focused engineers<\/td>\n<td>Reliability, operations, incident response patterns<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams adopting AI Ops<\/td>\n<td>AIOps concepts, automation in operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content<\/td>\n<td>Engineers seeking structured guidance<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training<\/td>\n<td>Beginners to advanced DevOps practitioners<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps consulting\/training<\/td>\n<td>Teams needing flexible coaching<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training<\/td>\n<td>Ops teams needing hands-on help<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting<\/td>\n<td>Multi-account design, governance, automation<\/td>\n<td>AWS Organizations OU\/SCP design; landing zone planning; account vending pipelines<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training<\/td>\n<td>Governance, DevOps transformation, platform engineering<\/td>\n<td>Implement multi-account governance; CI\/CD + IAM patterns; operational readiness<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting<\/td>\n<td>Cloud operations, security basics, automation<\/td>\n<td>Cloud governance enablement; policy-as-code processes; observability setup<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before AWS Organizations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS fundamentals: IAM users\/roles\/policies, Regions\/AZs, VPC basics, CloudTrail basics<\/li>\n<li>AWS account security basics: MFA, root account protections, least privilege<\/li>\n<li>Basic billing concepts: consolidated billing vs cost allocation tags, Cost Explorer<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after AWS Organizations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Control Tower<\/strong> (if you want a managed landing zone)<\/li>\n<li>IAM Identity Center multi-account access patterns<\/li>\n<li>Centralized logging architectures (CloudTrail org trails, S3 log archive patterns)<\/li>\n<li>Multi-account security operations:<\/li>\n<li>GuardDuty \/ Security Hub org administration (service-specific)<\/li>\n<li>Incident response in a multi-account environment<\/li>\n<li>Infrastructure as Code for governance:<\/li>\n<li>SCP policy-as-code workflows<\/li>\n<li>Account provisioning automation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Platform Engineer<\/li>\n<li>Cloud\/Solutions Architect<\/li>\n<li>DevOps Engineer \/ SRE<\/li>\n<li>Security Engineer \/ Cloud Security Architect<\/li>\n<li>FinOps Analyst \/ Cloud Cost Manager<\/li>\n<li>Cloud Operations Engineer<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>AWS Organizations appears as a concept across multiple AWS certification domains (governance, security, multi-account). A common progression:\n&#8211; AWS Certified Cloud Practitioner (foundations)\n&#8211; AWS Certified Solutions Architect \u2013 Associate\n&#8211; AWS Certified Security \u2013 Specialty (or equivalent, if current)\n&#8211; AWS Certified Solutions Architect \u2013 Professional<\/p>\n\n\n\n<p>Always verify the latest AWS certification roadmap and exam guides on the official AWS Training and Certification site.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a small landing zone:<\/li>\n<li>OUs for prod\/nonprod\/sandbox<\/li>\n<li>SCP baseline and environment-specific SCPs<\/li>\n<li>Central log archive account pattern (design-only or implement with CloudTrail + S3)<\/li>\n<li>Implement \u201caccount vending\u201d:<\/li>\n<li>Script account creation with AWS CLI and place accounts in correct OU<\/li>\n<li>Add automated guardrails attachment<\/li>\n<li>Create an SCP library:<\/li>\n<li>region restriction (carefully)<\/li>\n<li>deny disabling CloudTrail<\/li>\n<li>deny leaving organization (where applicable\u2014verify exact controls)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Account<\/strong>: An AWS account; a strong isolation boundary for resources, IAM, and many service limits.<\/li>\n<li><strong>AWS Organizations<\/strong>: AWS service for multi-account management, governance, and consolidated billing.<\/li>\n<li><strong>Management account<\/strong>: The account that owns the organization and pays the consolidated bill.<\/li>\n<li><strong>Member account<\/strong>: Any account that belongs to an organization but is not the management account.<\/li>\n<li><strong>Organization<\/strong>: The overall container for accounts, OUs, and policies.<\/li>\n<li><strong>Root<\/strong>: The top-level node in the AWS Organizations hierarchy.<\/li>\n<li><strong>OU (Organizational Unit)<\/strong>: A group of accounts used to apply and inherit policies.<\/li>\n<li><strong>SCP (Service Control Policy)<\/strong>: A policy that limits the maximum permissions for accounts\/OUs in an organization.<\/li>\n<li><strong>Policy attachment<\/strong>: The act of attaching a policy (like an SCP) to a root, OU, or account.<\/li>\n<li><strong>Inheritance<\/strong>: Policies attached to a parent (root\/OU) apply to child OUs\/accounts.<\/li>\n<li><strong>Delegated administrator<\/strong>: A member account authorized to administer certain AWS services across the organization (service-dependent).<\/li>\n<li><strong>Trusted access<\/strong>: An integration setting that allows an AWS service to operate with AWS Organizations across accounts.<\/li>\n<li><strong>Landing zone<\/strong>: A standardized multi-account baseline with governance, security, and networking patterns.<\/li>\n<li><strong>Break-glass access<\/strong>: Emergency access procedure (highly controlled) for critical incidents.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>AWS Organizations is the core <strong>AWS Management and governance<\/strong> service for managing multiple AWS accounts with a centralized hierarchy, consolidated billing, and governance controls like <strong>Service Control Policies (SCPs)<\/strong>. It matters because multi-account setups are a best practice for isolation, security, and scalable operations\u2014and without a governance layer, multi-account environments become difficult to control.<\/p>\n\n\n\n<p>Cost-wise, AWS Organizations is typically <strong>no additional charge<\/strong>, but it enables patterns (central logging, org-wide security tooling) that can materially affect your bill. Security-wise, it\u2019s foundational: SCPs provide preventive guardrails, and delegated administration helps keep the management account tightly locked down.<\/p>\n\n\n\n<p>Use AWS Organizations when you have (or expect) multiple AWS accounts and need consistent guardrails and billing governance. Your next learning step is usually either <strong>AWS Control Tower<\/strong> (for a managed landing zone) or a deeper focus on <strong>SCP design<\/strong>, <strong>identity federation\/IAM Identity Center<\/strong>, and <strong>centralized logging and security operations<\/strong> across the organization.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Management and governance<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,33],"tags":[],"class_list":["post-266","post","type-post","status-publish","format-standard","hentry","category-aws","category-management-and-governance"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/266","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=266"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/266\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=266"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=266"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=266"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}