Episode 22: Multi-Account AWS - Identity & Governance at Scale | SAA-C03

Hey everyone, Balu here, welcome back to TechTalk with Balu, your complete guide to Async the AWS Solutions Architect Associate Exam. Today we're tackling episode 22, and we're moving up a level. So far, we've mostly talked about building things inside a single AWS account, but real companies don't operate that way. A growing organization ends up with dozens, sometimes hundreds of AWS accounts, and they need a way to manage all of them together. They need centralized billing, consistent security guardrails, a single sign-on experience for their employees, and a way to prove they're staying compliant. That's what this episode is all about. We'll cover AWS organizations, which is the foundation for managing many accounts at once. We'll dig into service control policies, which are the guardrails that restrict what accounts can do. We'll then look at AWS IM-ID Decentre, the single sign-on service that used to be called AWS SSO. We'll cover AWS directory service for connecting your existing Microsoft Active Directory to AWS. We'll then touch on control tower for setting up a well-governed multi-account environment automatically. We'll cover resource access manager for sharing resources between accounts, and then we'll clarify where cognitive fits, and it's easy to confuse with the enterprise IM-DT services. We're keeping the same interactive format with pulse checks, trap spotlights, and memory hooks, and we're staying with the shorter puncher length. So let's get started. Let's begin with the service that makes everything else in this episode possible, which is AWS Organizations. AWS Organizations is a global service that lets you manage multiple AWS accounts from one central place. The structure works like this. You have one management account, which used to be called the master account, and it sits at the top. Everything else is a member account, and each member account can only belong to one organization at a time. Now, why would a company want many accounts instead of one big account with everything inside it? There are some real advantages. You get natural isolation between environments, so your production account is completely separate from your development account, which limits the blast radius if something were to go wrong. You can use tagging standards across accounts for billing purposes. You can then enable CloudTrial on all accounts and send those logs to one central logging account. You can send CloudWatch logs to a central account as well, and then you can establish cross account roles for administrative access. One of the biggest immediate benefits is to consolidate billing. When you bring all of your accounts into one organization, you get a single payment method covering everything, and you get pricing benefits from aggregated usage. For example, the combined EC2NS3 usage across all your accounts counts towards volume discounts, and you can share reserved instance and savings plans discounts across accounts too. So accounts that individually wouldn't hit a discount tier can collectively benefit from this. There is also an API available, which lets you automate the creation of new AWS accounts. Now, to organize all these accounts, organizations use organizational units, or what we called OUs. And OU is just a container for accounts, and you can nest them. At the top, you have the root, and underneath it, you build a tree of OUs. You might organize your OUs by business unit with a sales OU, a retail OU, and a finance OU. Or you might organize by environment with the production OU, a development OU, and a test OU, if you get the point. Or you might organize by the project, the structure is entirely up to you, and it usually mirrors how the company itself is organized. So here is a memory hook to lock all of this in. Think of AWS organizations as the corporate headquarters for all your AWS accounts. The management account is the head office that pays all the bills and sets the rules. The OUs are the departments, and the member accounts are the individual teams working within those departments. Now, let's talk about how you actually control what those accounts are allowed to do, which brings us to service control policies, or what we call SCPs. A service control policy is a rule that you apply to an OU, or an individual account, to restrict what the users and rules inside that can do. This is the guardrail mechanism for your whole organization. For example, you could write an SCP that says no account in development OU is allowed to use any region except one, or that a particular OU can never touch a specific service. There are a few critical things to understand about how SCPs work, and the exam tests these precisely. The first is that SCPs do not apply to management account. The management account always keep full administrative power, no matter what SCPs you set. This is actually a reason not to run workloads in your management account because you can't restrict them. The second is how SCPs interact with permissions, and SCP does not grant any permission by itself. It only sets the maximum boundary of what is possible. You still need IM policies to actually grant permissions to users and rules. Think of it this way, the SCP defines what's allowed at the organizational level, and IM defines what's actually granted at the user level. A user can only do something if both SCP allows it and their IM policy grants it. The third point is about hierarchy. For an action to be allowed in a target account, there must be an explicit path of allow permissions from the root through every OU in the direct path down to that account. Just like IM, SCPs don't allow anything by default, so if you're using an allow list strategy, you will have to explicitly allow that service every level of the tree. Most companies use one of the two strategies. A block list strategy starts by allowing everything, which is the default, and then explicitly denies specific services or actions you don't want. This is the most common approach, and allow list strategy starts by denying everything and then explicitly allows only specific services you do want, which is the more restrictive and more work to maintain. Let me give you a classic mental model with an example. Imagine that the management account can do absolutely anything because SCPs never apply to it. Then under a sandbox OU, you can attach an SCP that denies S3. Now every account inside that sandbox OU can do anything except use S3. If you then add another deny for EC2 on one specific account, that single account then loses both S3 and EC2, while it's sibling accounts only lose S3. The denies accumulate as you go down the tree. There's also a related feature where the quick mention here which is called tag policies. Tag policies help you standardize tags across all the resources in your organization. You define which tag keys are allowed and what values they can have, which helps enormously with cost allocation and with attribute-based access control. They can flag non-compliant tagging and generate reports of what's tagged correctly and what isn't. Let's do a quick pulse check here. Here's the scenario. A company wants to make absolutely sure that no account in their organization except the management account can ever launch resources outside the EU-West1 region regardless of what individual account administrators try to do. What AWS feature should they use? Let's take a moment and think about it. The answer here is service control policy because the requirement is an organization wide restriction that individual account admins cannot override and SCP is exactly the tool here. You had attached an SCP most likely at the root or top level OU that denies any action outside EU-West1 and remember it won't affect the management account which keeps full power regardless. Here's a trap to watch out for. Don't confuse SCPs with IM policies and IM policy grants permissions to a specific user or role and SCP on the other hand restricts the maximum permissions available to an entire account or OU but it never grants anything on its own. When a question describes an organization wide guardrail that account owners can't bypass that's typically an SCP. When it describes giving a specific user access to a specific resource, then that's IM. For your memory hook, think of an SCP as buildings master rulebook posted at the friendle. It says what's forbidden inside and nobody in the building can override it but it doesn't hand anyone a key. IM here is the individual key that actually lets a specific person into a specific room. You need both to get in. Now, let's talk about how employees actually log in across all these accounts which is where AWS IM-indity center comes in. You will also see it referred to by its old name, AWS Single Sion so keep both names in mind for the exam. IM-indity center gives your users one single login for everything they need. That includes all of your AWS accounts in your organization, business cloud applications like Salesforce, Box and Microsoft 365, any custom applications that support SAML 2.0 standard and even EC2 Windows instances. Instead of managing separate credentials in every account, a user logs in once and gets access to everything they are entitled to. Behind the scenes, you need an identity source which is where your user entities actually live. IM-indity center gives you a couple of options here. It has a built-in "indity store" so you can create and manage users right inside it or you can connect a third party identity provider such as Microsoft Active Directory, one login or "Octa". Many enterprises already have their users in Active Directory so they connect that. The core concept for managing access here is called Permission Set. A permission set is a collection of one or more IM policies that you have. You assign to users and groups to define what they can do. Here's how it comes all together in practice. You might have a group called Developers containing, let's say, Alice and Bob. You create a permission set called Read-Only Access and another called Full Access. Then you assign the appropriate permission set to the group for specific accounts. So the Developers group might get full access in development account, but only Read-Only Access in the Perection account. One place to manage it all, apply it consistently across every account. I, Mind2DCender, also supports application assignments, which give single sign-on access to those SAML 2.0 business applications. You provide the required URLs, certificates and metadata and your users get seamless access. And there is a powerful feature also called Attribute-Based Access Control or ABAC for shot. This lets you define fine-grained permissions based on Attributes stored about your users, such as their cost center, their job title and their location. The real benefit is that you define the permissions once based on Attributes and then you can change your users' access simply by changing their attributes rather than rewriting policies. For example, you define that database administrators can manage RDS and Aurora and then anyone whose attributes mark them as a database admin automatically gets that access across the relevant accounts. Let's do a pulse check here, here's a scenario. A company has 50 AWS accounts under organizations and they want their employees to log in one time and access whichever accounts they're authorized for using the company's existing Microsoft Active Directory as the identity source. What service should they use? The answer is AWS IM-indity center, it provides that one single sign-on across all the accounts in the organization and it integrates directly with Active Directory as the identity source. Permission sets them control which accounts each employee can reach and what they can do there. For your memory hook, think of IM-indity center as the master key card system for a corporate campus. Each employee gets one batch, they tap it once and it opens exactly the doors they're allowed through across every building. Think of the permission sets as the access levels programmed onto each of their batches. Now since we've just mentioned Active Directory, let's cover AWS Directory service which is how you bring Microsoft Active Directory into AWS. First a quick refresher on what Active Directory even is. Microsoft Active Directory runs on Windows Server and it's a central database of objects like user accounts, computers, printers, file shares and security groups. It provides centralized security management for Windows environments. Organizations that run on Windows almost always have Active Directory at the center of their identity setup. AWS Directory services give you three main options for working with Active Directory in the cloud and the differences matter for the exam. The first is AWS managed Microsoft AD. This creates your very own full Active Directory inside AWS managed by AWS. You can manage users locally in the cloud, it supports multi-factor authentication and crucially, you can establish a trust relationship with your own premise Active Directory. That means your cloud directory and your own premise directory can work together while both continue to exist. You use this when you want a real standalone Active Directory presence in AWS that can also connect back to on premise. The second is called AD connector. This is a directory gateway, essentially, a proxy that redirects requests back to your own premise Active Directory. With an AD connector, your users stay managed entirely on premise. Nothing is stored in the cloud directory. It just forwards authentication requests your existing on premise AD and it supports multi-factor authentication. You use this when you want your users to stay on premise but still access AWS services. The third is symbol AD. This is an Active Directory compatible managed directory in AWS but it's a lighter weight option and importantly, it cannot be joined to an on-premise Active Directory. Use this for simple standalone needs where you don't need integration with an existing on-premise directory. So here is a trap to watch out for. The distinction between these three come down to where your users are managed and whether you need on-premise integration. If you need a full AD in the cloud that trusts your on-premise directory, that's AWS managed Microsoft AD. If you want to keep all users on premise and just proxy authentication, that's AD connector. And on the other hand, if you want a simple standalone directory with no on-premise connection at all, that's simple AD. For your memory hook, think of it this way. AWS managed Microsoft AD is like opening a fully staffed branch office that coordinates with headquarters. AD connector is just a phone line forwarding every question back to the headquarters and a simple AD is a small independent office that doesn't talk to the headquarters at all. Now, let's talk about setting up a whole multi-account environment the easy way which is AWS Control Tower. Setting up a well-organized secure multi-account environment by hand is a lot of work. You had had to configure organizations, set up all your OUs, write your SCPs, configure logging, establish your identity setup and make sure everything follows best practices. Well Control Tower does all of that for you. AWS Control Tower is the easy way to set up and govern a secure, compliant multi-account AWS environment based on best practices. Under the hood, it actually uses AWS organizations to create and manage the accounts. So basically, it sits on top of everything we have already discussed. The benefits are that it automates the setup of your entire environment in just a few clicks. It automates ongoing policy management, it detects policy violations and can remediate them and it lets you monitor compliance through an interactive dashboard. The key feature to understand here is guardrails. Guardrails provide ongoing governance for your Control Tower environment and they come in two types. Preventive guardrails stop bad things from happening in the first place and they are implemented using service control policies. For example, a preventive guardrail might restrict which regions can be used across all your accounts. Because it's an SCP, the action is simply blocked before it can happen. Detective guardrails on the other hand don't block anything, but they detect when something is out of compliance and they are implemented using AWS config. For example, a detective guardrail might identify any untied resources across your accounts. For it finds a violation, it can trigger a notification and even an automated remediation. That preventive versus detective distinction is a nice callback to episode 18 where we talked about differences between preventing and detecting. Preventive uses SCPs which is prevention, detective uses config which is detection. For your memory hook, think of Control Tower as hiring a general contractor to build and inspect your entire office complex to code rather than building it yourself brick by brick. The preventive guardrails are the locked doors that stop people going where they should be and the detective guardrails are the security cameras that flag anything out of place. Let's cover one more sharing service that ties into the multi-account world which is AWS Resource Access Manager or called RAM for short. Resource Access Manager lets you share AWS resources that you own with other AWS accounts, including other accounts in your organization. Instead of duplicating resources in every account, you create them once and share them. Common examples include sharing a transit gateway which we talked about in the last episode, sharing VPC subnets so multiple accounts can deploy into a shared network, sharing route 53 resolver rules and sharing license manager configurations. The big win here is efficiency and consistency. Rather than each account building its own copy of the shared infrastructure, you centralize it and share access to it. This reduces duplication, saves money and keeps things consistent across the organization. For your memory hook, think of RAM as a shared tool library for the whole company. Instead of every department buying its own expensive equipment, one department owns it and lends it out to others who need it. Before we get on to the trap section, let's quickly clarify where Amazon Cognito fits because it's easy to confuse with enterprise identity services we have covered today. Everything else in this episode has been about your own company's identities, your employees, your accounts, your administrators and so on and so forth. Cognito is different on the other hand. Cognito is about giving identity to external users of your web or mobile application. Your customers, in other words, not your staff. Cognito has two main pieces, Cognito user pools that provide sign-in functionality for your users of your app and they integrate with API Gateway and application load balancer. This is a serverless user database for your web and mobile apps, handling username and password login, password resets, email and phone verification, multi-factor authentication and federated login from your providers like Facebook, Google and SML. Cognito entity pools on the other hand provide temporary AWS credentials so those users can access AWS resources directly. Here's the distinction that appears always in the exam. When you see phrases like hundreds or thousands of users or mobile users or authenticating app users with providers like Facebook and Google, that generally points to Cognito. When you see internal employees logging into AWS accounts, that's IM-indity center. Cognito is for people using your product whereas IM-indity center is for the people building it. For your memory hook, IM-indity center is the employee barge system for your staff, while co-ognitor is the guest registration desk for your customers. Both handle I-indity, but for completely different groups of people. Alright, so let's pull everything together with exam traps. The first trap is SCP versus IM. An SCP restricts the maximum permissions for an account or OU, but grants nothing by itself. Remember that IM grants actual permissions to users and rules. You need both for an action to succeed, and SCPs never apply to the management account. The second trap is the SCP hierarchy. For an allowless strategy, you need an explicit allow at every level from the root down to the target account. Denies accumulate as you move down the tree. The third trap is IM-indity center versus IM. I-indity center is for single sign-on across many accounts and applications, typically for a workforce, whereas plain IM is for managing users and rules within single account. When you see single sign-on across an organization, think I-indity center. The fourth trap is directory service options. AWS managed Microsoft AD is a full directory in the cloud that can trust on premise. AD connector is a proxy that keeps users on premise. Limble AD is standalone with no on-premise integration. The fifth trap is controlled tower guardrails, preventive guardrails use SCPs and block actions, whilst detective guardrails use AWS config and flag violations. The sixth trap is co-ognitor versus IM-indity center. Co-ognitor is for external app users, that's your customers, especially mobile and social login, whereas I-indity center is for internal workforce access to AWS accounts. The seventh trap is consolidated billing. Remember organizations give you a single bill, aggregated volume requests and shared reserve instances and service plan discounts across all accounts. For question asks how to get volume pricing discounts across many accounts, that's consolidated billing under organizations. The eighth trap is resource access manager. When you need to share a resource like transit gateway, VPC subnet or route 53 resolver rules across accounts, that's generally RAM. One duplicate the resources, just share it. The ninth trap is the control tower sits on top of organizations. It doesn't replace organizations. It uses organizations under the hood to automate a best practice multi-account setup. If a question asks for the easiest way to set up a governed multi-account environment from scratch, that is generally control tower. And the tenth trap is tag policies. When a question asks how to enforce consistent tagging standards across an entire organization for cost allocation, that's organization's tag policies. Okay, let's do a rapid fire summary to lock everything in. AWS organizations manage many accounts centrally. You get one management account plus member accounts, consolidated billing with aggregated discounts and organizational units to structure everything. Service control policies are your organization wide guardrails. They set the maximum boundary but granted nothing on their own. They never apply to management account and they work by explicit allow or deny rules down to the OU hierarchy. I am Mindy Descentre, formerly called the AWS single sign-on, gives your workforce one login across all accounts and applications. Permission sets define access, it integrates with active directory and other identity providers and it supports attribute based access control. AWS directory service connects Microsoft active directory to AWS. Each Microsoft AD is a full cloud directory that can trust on premise. AD connector is a proxy keeping users on premise and symbol AD is just standalone. Control tower automates a secure best practice multi-account setup on top of organizations using preventive guardrails built on a CPS and detective guardrails built on config. Resource access manager or RAM shares resources like transit gateway and VPC subnets across accounts instead of duplicating them. Then finally remember that Cognito handles identity for your external application users, your customers, which is by the way completely separate from the internal workforce identity that identity center handles. Alright, so that's episode 22 on managing AWS at scale across many accounts. We started by covering AWS organizations as the foundation for multi-account management with consolidated billing and organizational units. We then covered service control policies as the guardrails that restrict what accounts can do. We then covered IM-indity centers for workforce single sign-on. We covered directory service for bringing active directory into AWS. We covered control tower for automating a well-governed environment. We then covered resource access manager for sharing resources across accounts. And then we clarified how Cognito fits handling your external customers rather than your internal stuff. So here's the big takeaway. As organizations grow, identity and governance stop being about a single account and start being about coordinating many accounts consistently and securely. Organizations is the foundation, SAPs are the guardrails, IM-indity center is the front door of your workforce and control tower ties all of it together automatically. Master tool to the right requirement and the multi-account questions on the exam become very straightforward. We have now completed 22 main episodes and you're deep into the governance and identity material that suppress a good architect from a great one. If this episode helped these concepts click for you please do consider to leave a five-star rating on my podcast and please do consider to share it with anyone who's studying for the AWS exam. It genuinely helps the channel grow. So until next time keep building, keep governing and I'll see you in the next episode. This is Baloo signing off, bye.