Tools: Design Secure Access To AWS Resources

🎯 Secure access means you can clearly answer: ## Knowledge ## 1 | Access Controls And Management Across Multiple Accounts ## Common Patterns ## 2 | AWS Federated Access And Identity Services ## IAM & IAM Identity Center ## Simple Comparison ## 3 | AWS Global Infrastructure ## Regions & Availability Zones ## 4 | AWS Security Best Practices ## Principle of least Privilege ## Examples ## 5 | The AWS Shared Responsibility Model ## Security is Shared: ## AWS vs The Customer ## Skills ## A | Apply Best Practices To IAM Users And Root Users ## Multifactor Authentication (MFA) ## B | Design A Flexible Authorization Model That Includes Users, Groups, Roles And Policies ## C | Role-based Access Control Strategy ## AWS STS (Security Token Service): ## Cross-account Access ## D | Multi-Account Security Strategy ## Control Tower & Service Control Policies ## SCP Mindset ## E | Determine Appropriate Use of Resource Policies ## Decision Table ## F | Decide When To Federate A Directory Service With IAM Roles ## Cheat Sheet ## Recap Checklist ✅ ## AWS Whitepapers and Official Documentation ## Core Whitepapers ## AWS Well-Architected Framework – Security Pillar ## IAM Best Practices ## AWS Shared Responsibility Model ## Identity and Federation References ## IAM User Guide ## IAM Identity Center (AWS SSO) Documentation ## AWS Security Token Service (STS) Documentation ## Multi-Account and Governance References ## AWS Organizations User Guide ## Service Control Policies (SCPs) Documentation ## AWS Control Tower Overview Exam Guide: Solutions Architect - Associate 🛡️ Domain 1: Design Secure Architectures 📘 Task Statement 1.1 1 Who is trying to access AWS? 2 What are they allowed to do? 3 Where are they allowed to do it (which account / which resources)? 4 How are they proving it’s really them (password, MFA, federation)? 5 How long should that access last (temporary vs long-term)? This task is mostly about identity + permissions + multi-account setup. As a company grows, a single AWS account gets messy: A multi-account strategy helps you isolate workloads (dev/prod), apply security rules consistently, and reduce risk. SCPs do not grant permissions. They only set the maximum allowed actions in an account/OU. You still need IAM permissions to allow anything. Instead of creating an AWS username for every employee, many organizations use federation so people sign in with their existing company login. Prefer roles + federation for humans, and avoid creating lots of IAM users with long-term credentials. This shows up in access design because: Some services are global: identity or permissions concepts apply broadly Many resources are regional: they “live” in a Region Your access rules may include where actions are allowed, for example: “Only allow deployments in eu-west-1” or “Deny creating resources outside approved Regions” Least privilege means: 1 Don’t give “admin” unless it’s truly needed 2 Grant only the actions required for the job 3 Limit access to specific resources, avoid Resource: "*" If you see broad permissions like Action: "*", the “best answer” is usually narrower permissions + conditions. The root user is the account’s master key. If a scenario says “root user used daily,” the fix is almost always: enable MFA and stop daily root usage. 1 Policies: the permission rules 2 Roles: job hats you wear temporarily 3 Users: individual logins 4 Groups: attach permissions to many IAM users at once Role-based access control means you get access by assuming a role, not by permanently being an admin. This is about controlling many accounts consistently: So effective permissions are: Allowed by IAM AND not blocked by SCP Some services support resource-based policies, policy attached directly to the resource. Common Examples: Resource policies are often used for: Federation is ideal when: Workforce (employees/contractors): federation / IAM Identity Center Workloads (apps/services): IAM roles If you can explain these ideas in simple terms, you are well prepared for Task Statement 1.1: 1. [ ] The root user is protected with MFA and not used for daily work 2. [ ] IAM roles are preferred over long-term IAM users 3. [ ] Least privilege is applied: only needed actions, only needed resources 4. [ ] Multiple AWS accounts are managed centrally 5. [ ] Cross-account access uses role assumption: temporary credentials 6. [ ] Workforce access uses federation or IAM Identity Center 7. [ ] You understand when to use identity-based vs resource-based policies These are the primary AWS documents behind Task Statement 1.1. You do not need to memorize them, use them to understand why AWS security works the way it does. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - Too many people and teams in one place - Permissions become inconsistent and hard to audit - Mistakes have a bigger blast radius - Separating dev/test/prod becomes harder - IAM (Identity and Access Management): the core permissions engine, which has _users, groups, roles and policies _ - IAM Identity Center (AWS SSO): central sign-in for workforce access across accounts, which is best when you have multiple accounts and want one place to manage access - AWS secures the cloud infrastructure: the underlying platform - You secure your configuration and access: identity, permissions, data protection - Enable MFA on root - Don’t use root for daily work - Use roles or controlled identities for admin tasks - Humans: sign in via Identity Center / federation → assume roles - Apps/services: use roles because you don’t and should not store access keys in code. - Issues temporary credentials - Reduces long-term secret exposure - Enables clean cross-account access - Users in Account A assume a role in Account B - No shared passwords - No copying access keys between accounts - Use a structured account layout (prod/dev/security) - Apply org-wide guardrails with SCPs - Keep shared security functions isolated - IAM Policies: what a principal can do - SCPs: what an account is ever allowed to do - S3 buckets, - SQS queues, - SNS topics, - Lambda functions. - Cross-account access to a bucket or queue or topic - Service-to-service permissions - Enforcing conditions like “HTTPS only” - People already have company accounts such as Google Workspace, Okta, Azure AD, AD, etc. - You want easy onboarding and offboarding - You want fewer long-term IAM users - Explains the principles behind secure access design - Covers least privilege, identity management, and governance - This is the mindset behind most security questions - Explains users, roles, groups, and policies - Reinforces why roles and temporary credentials are preferred - Very relevant for root user and IAM user questions - Clarifies what AWS secures vs what you must secure - Helps avoid overengineering or missing responsibility gaps - Deepens understanding of policies, roles, and permission evaluation - Useful for questions involving policy conflicts and access boundaries - Important for workforce access at scale - Frequently relevant when multiple accounts or many users are mentioned - Explains temporary credentials and role assumption - Key for cross-account access and short-lived permissions - Explains organizational units (OUs) and account structure - Critical for understanding SCP behavior - Explains how SCPs restrict permissions - Important for “even admins must not be able to…” scenarios - Helps visualize a standard, secure multi-account setup - Often implied when questions mention “large organization” or “governance”