{"id":319,"date":"2026-04-13T15:32:30","date_gmt":"2026-04-13T15:32:30","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-identity-and-access-management-iam-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance\/"},"modified":"2026-04-13T15:32:30","modified_gmt":"2026-04-13T15:32:30","slug":"aws-identity-and-access-management-iam-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-identity-and-access-management-iam-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance\/","title":{"rendered":"AWS Identity and Access Management (IAM) Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, identity, and compliance"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Security, identity, and compliance<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>AWS Identity and Access Management (IAM) is AWS\u2019s core service for controlling <strong>who<\/strong> can sign in to AWS and <strong>what<\/strong> they can do once authenticated. It is the foundation of access control for nearly every AWS service and a required competency for anyone operating production workloads on AWS.<\/p>\n\n\n\n<p>In simple terms: <strong>IAM lets you create identities (users, roles), group them, and attach permissions so the right people and systems have the right access\u2014no more, no less.<\/strong> IAM also supports federation (using external identity providers) and temporary credentials (so you can avoid long-lived keys).<\/p>\n\n\n\n<p>Technically, IAM is a global AWS service that evaluates requests to AWS APIs based on a policy evaluation logic: authentication (proving identity), authorization (policy evaluation), and enforcement (allow\/deny). IAM policies\u2014written in JSON\u2014define permissions using actions, resources, and conditions. IAM integrates deeply with AWS Security, identity, and compliance capabilities such as AWS CloudTrail for audit logging, AWS Organizations for multi-account governance, and AWS IAM Access Analyzer for policy validation and external access findings.<\/p>\n\n\n\n<p>IAM solves the problem of <strong>secure, scalable, auditable access control<\/strong> across accounts, teams, and workloads\u2014supporting least privilege, separation of duties, and compliance requirements.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is AWS Identity and Access Management (IAM)?<\/h2>\n\n\n\n<p><strong>Official purpose:<\/strong> AWS Identity and Access Management (IAM) helps you securely control access to AWS resources by managing users, roles, and permissions. (See the AWS IAM documentation: https:\/\/docs.aws.amazon.com\/iam\/)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Identity management:<\/strong> Create and manage IAM users, groups, and roles.<\/li>\n<li><strong>Access management:<\/strong> Define and enforce permissions using IAM policies (managed and inline).<\/li>\n<li><strong>Temporary credentials and role assumption:<\/strong> Use AWS Security Token Service (STS) capabilities through IAM roles for short-lived credentials.<\/li>\n<li><strong>Federation:<\/strong> Integrate with identity providers (IdPs) using standards like <strong>SAML 2.0<\/strong> and <strong>OpenID Connect (OIDC)<\/strong> for workforce and workload access patterns.<\/li>\n<li><strong>Account-level controls:<\/strong> Enforce password policy, credential reporting, and access analysis tools.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM users:<\/strong> Human or legacy application identities with long-term credentials (passwords and\/or access keys).<\/li>\n<li><strong>IAM groups:<\/strong> Collections of users to simplify permission management (permissions are attached to groups; groups are not used for authentication by AWS services).<\/li>\n<li><strong>IAM roles:<\/strong> Identities with <strong>no long-term credentials<\/strong> that are assumed by principals (users, services, external identities) to obtain temporary credentials.<\/li>\n<li><strong>Policies (JSON):<\/strong><\/li>\n<li><strong>AWS managed policies:<\/strong> Created and maintained by AWS.<\/li>\n<li><strong>Customer managed policies:<\/strong> Created and maintained by you; reusable across identities.<\/li>\n<li><strong>Inline policies:<\/strong> Embedded directly in a single user\/group\/role; not reusable.<\/li>\n<li><strong>Permissions boundaries:<\/strong> Maximum permissions guardrail for a role or user.<\/li>\n<li><strong>Policy evaluation tools:<\/strong> Policy simulator, access advisor, last accessed info, and IAM Access Analyzer (service feature in the IAM family).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type and scope<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service type:<\/strong> Control-plane\/security service.<\/li>\n<li><strong>Scope:<\/strong> <strong>Account-scoped<\/strong> (IAM entities belong to an AWS account).<\/li>\n<li><strong>Regionality:<\/strong> IAM is generally treated as a <strong>global service<\/strong> (not tied to a specific region), though it controls access to resources in all regions. Some related features and integrations may have regional considerations\u2014verify behavior in official docs for your use case.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How IAM fits into the AWS ecosystem<\/h3>\n\n\n\n<p>IAM sits at the center of AWS Security, identity, and compliance:\n&#8211; Every AWS API call is authenticated and authorized\u2014often using IAM policies.\n&#8211; IAM roles are the standard way AWS services (like EC2, Lambda, ECS) get permissions to call other AWS services.\n&#8211; IAM is commonly combined with:\n  &#8211; <strong>AWS Organizations<\/strong> (service control policies, multi-account strategy)\n  &#8211; <strong>AWS CloudTrail<\/strong> (auditing API activity)\n  &#8211; <strong>AWS IAM Identity Center<\/strong> (recommended for workforce SSO; separate service)\n  &#8211; <strong>Amazon Cognito<\/strong> (app end-user identity; separate service)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use AWS Identity and Access Management (IAM)?<\/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>Reduce breach risk:<\/strong> Enforce least privilege and eliminate shared credentials.<\/li>\n<li><strong>Enable compliance:<\/strong> Centralize access control and auditing for standards like ISO 27001, SOC, PCI DSS, HIPAA (requirements vary).<\/li>\n<li><strong>Scale securely:<\/strong> Support multiple teams, environments, and accounts without ad-hoc access management.<\/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>Fine-grained authorization:<\/strong> Control access per API action, resource ARN, and conditions (MFA, source IP, VPC endpoint, tags).<\/li>\n<li><strong>Temporary credentials by default:<\/strong> Roles + STS reduce exposure from leaked access keys.<\/li>\n<li><strong>Cross-account access:<\/strong> Securely share access between AWS accounts without copying resources or creating duplicate identities.<\/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>Repeatable governance:<\/strong> Standardize permission models via managed policies, permission boundaries, and infrastructure-as-code.<\/li>\n<li><strong>Auditability:<\/strong> Combine IAM with CloudTrail to track \u201cwho did what, when, from where.\u201d<\/li>\n<li><strong>Lifecycle controls:<\/strong> Credential reports, access advisor, and last accessed data support access reviews.<\/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>MFA enforcement:<\/strong> Require MFA for sensitive actions or role assumption.<\/li>\n<li><strong>Separation of duties:<\/strong> Different roles for deployment, operations, security, and billing.<\/li>\n<li><strong>Guardrails:<\/strong> Permissions boundaries and (with AWS Organizations) SCPs to prevent unsafe permissions.<\/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>IAM is designed for large-scale authorization across AWS. From an architectural view, the main \u201cscaling\u201d concerns are governance and policy manageability (policy sprawl), not throughput tuning.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose AWS Identity and Access Management (IAM) when you need:\n&#8211; AWS-native authorization for AWS resources\n&#8211; Strong control over API permissions\n&#8211; Secure service-to-service access using roles\n&#8211; Cross-account access patterns\n&#8211; Audit-ready access management foundations<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When they should not choose it<\/h3>\n\n\n\n<p>IAM is not the best fit when:\n&#8211; You need <strong>end-user identity<\/strong> for customer-facing apps (use <strong>Amazon Cognito<\/strong> or external IdP).\n&#8211; You need workforce SSO and centralized user lifecycle for humans at scale (use <strong>AWS IAM Identity Center<\/strong> integrated with an IdP; IAM still underpins permissions, but Identity Center is the front door).\n&#8211; You need a full PAM (Privileged Access Management) product with checkout\/approval workflows\u2014IAM can enforce permissions, but approval workflows are typically external.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is AWS Identity and Access Management (IAM) 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 and fintech:<\/strong> Strong audit trails, least privilege, separation of duties.<\/li>\n<li><strong>Healthcare:<\/strong> Regulated access, traceability, and tight permissions.<\/li>\n<li><strong>SaaS and technology:<\/strong> Multi-account environments, CI\/CD automation, OIDC federation.<\/li>\n<li><strong>Retail and e-commerce:<\/strong> Secure operations access and service roles at scale.<\/li>\n<li><strong>Government\/education:<\/strong> Centralized governance, compliance reporting, controlled delegation.<\/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>Cloud platform teams (landing zone, account vending)<\/li>\n<li>Security engineering and IAM governance teams<\/li>\n<li>DevOps\/SRE teams managing CI\/CD and runtime permissions<\/li>\n<li>Application teams needing least-privilege service access<\/li>\n<li>Operations\/helpdesk teams handling controlled access requests<\/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>Microservices<\/strong> on ECS\/EKS using task\/service account roles<\/li>\n<li><strong>Serverless<\/strong> (Lambda execution roles + scoped permissions)<\/li>\n<li><strong>Data platforms<\/strong> (S3, Athena, Glue, Lake Formation\u2014often with tight IAM integration)<\/li>\n<li><strong>Multi-account architectures<\/strong> (central security\/billing + workload accounts)<\/li>\n<li><strong>Hybrid<\/strong> and external workloads using federation and\/or IAM Roles Anywhere (verify applicability)<\/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>Production environments with strict role separation and approvals<\/li>\n<li>Dev\/test environments with looser controls but still avoiding shared keys<\/li>\n<li>Shared services accounts (logging, security tooling) with cross-account access<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production:<\/strong> Use roles, federation, MFA, permission boundaries, strong logging, and periodic access reviews.<\/li>\n<li><strong>Dev\/test:<\/strong> Still avoid root and shared credentials; use temporary credentials and minimize broad policies to prevent \u201cdev policy drift\u201d into production.<\/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, frequently used scenarios for AWS Identity and Access Management (IAM). Each includes the problem, why IAM fits, and a short example.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Least-privilege access for human administrators<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Admins need access, but full admin everywhere increases risk.<\/li>\n<li><strong>Why IAM fits:<\/strong> Fine-grained policies and role-based access let you scope access by function and environment.<\/li>\n<li><strong>Example:<\/strong> \u201cOperationsRole\u201d can manage EC2 and Auto Scaling but cannot modify IAM or billing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Secure service-to-service permissions (no embedded secrets)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Applications need to call AWS APIs without storing static keys.<\/li>\n<li><strong>Why IAM fits:<\/strong> IAM roles provide temporary credentials for AWS services (EC2 instance profiles, Lambda execution roles, ECS task roles).<\/li>\n<li><strong>Example:<\/strong> A Lambda function assumes an execution role with permission to read a single DynamoDB table.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Cross-account access for centralized security operations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A security team needs read-only visibility into many AWS accounts.<\/li>\n<li><strong>Why IAM fits:<\/strong> Cross-account roles with external IDs and least privilege are standard patterns.<\/li>\n<li><strong>Example:<\/strong> A \u201cSecurityAuditRole\u201d in each account is assumable by a central \u201cSecurityTooling\u201d account.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) CI\/CD pipelines with short-lived credentials (OIDC federation)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> CI\/CD systems often use long-lived keys that leak.<\/li>\n<li><strong>Why IAM fits:<\/strong> IAM supports federated access with OIDC providers; roles can be assumed using identity tokens (implementation depends on provider).<\/li>\n<li><strong>Example:<\/strong> GitHub Actions assumes an IAM role to deploy to S3\/CloudFront without storing AWS keys.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Multi-team access management using groups and managed policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Onboarding\/offboarding is messy if permissions are attached directly to users.<\/li>\n<li><strong>Why IAM fits:<\/strong> Groups + managed policies simplify user lifecycle and reduce mistakes.<\/li>\n<li><strong>Example:<\/strong> \u201cDevelopers\u201d group gets read-only CloudWatch + limited S3; \u201cDBA\u201d group gets RDS permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Enforce MFA for privileged operations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Password-only sign-in is too weak for sensitive actions.<\/li>\n<li><strong>Why IAM fits:<\/strong> Policy conditions can require MFA presence.<\/li>\n<li><strong>Example:<\/strong> Deny <code>iam:*<\/code> unless <code>aws:MultiFactorAuthPresent<\/code> is true.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Delegated administration for a platform team<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Central security wants guardrails, but platform teams need autonomy.<\/li>\n<li><strong>Why IAM fits:<\/strong> Permissions boundaries (plus SCPs via Organizations) can enforce maximum permissions while delegating day-to-day management.<\/li>\n<li><strong>Example:<\/strong> Platform team can create roles for apps but cannot create roles with admin-level permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Temporary elevated access (\u201cbreak-glass\u201d pattern)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Engineers occasionally need higher privileges for incident response.<\/li>\n<li><strong>Why IAM fits:<\/strong> Create an assumable role with strict conditions (MFA, time, approval process external) rather than giving permanent privileges.<\/li>\n<li><strong>Example:<\/strong> \u201cIncidentResponseRole\u201d assumable only with MFA and logged with CloudTrail; session duration limited.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Restrict access by network location<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Sensitive APIs should not be callable from anywhere on the internet.<\/li>\n<li><strong>Why IAM fits:<\/strong> Conditions can limit access by source IP or by VPC endpoint.<\/li>\n<li><strong>Example:<\/strong> Allow <code>s3:GetObject<\/code> only when requests come via a specific VPC endpoint.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Access reviews and compliance reporting<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You must demonstrate who has access and when it was used.<\/li>\n<li><strong>Why IAM fits:<\/strong> Credential reports, last accessed information, and CloudTrail provide evidence inputs.<\/li>\n<li><strong>Example:<\/strong> Quarterly review uses IAM Access Advisor data to remove unused permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Vendor\/third-party access with tight controls<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> External vendors need limited access without creating internal accounts.<\/li>\n<li><strong>Why IAM fits:<\/strong> Cross-account role assumption, external IDs, and scoped policies reduce exposure.<\/li>\n<li><strong>Example:<\/strong> A vendor assumes <code>VendorSupportRole<\/code> limited to a support S3 bucket and CloudWatch logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Control access by attributes (ABAC using tags)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> RBAC alone becomes unmanageable across many teams and resources.<\/li>\n<li><strong>Why IAM fits:<\/strong> Attribute-based access control (ABAC) using tags + policy variables can scale.<\/li>\n<li><strong>Example:<\/strong> Developers can manage resources tagged <code>Project=Alpha<\/code> only.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on current, widely used IAM capabilities. For exact feature availability and latest behavior, verify in official docs: https:\/\/docs.aws.amazon.com\/iam\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">IAM policies (JSON)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Defines permissions using <code>Effect<\/code>, <code>Action<\/code>, <code>Resource<\/code>, and optional <code>Condition<\/code>.<\/li>\n<li><strong>Why it matters:<\/strong> Policies are the enforcement mechanism for authorization.<\/li>\n<li><strong>Practical benefit:<\/strong> Precise, testable permissions you can version-control and review.<\/li>\n<li><strong>Caveats:<\/strong> Policy complexity can grow quickly; prefer managed policies and modular design. Deny overrides allow.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Users, groups, and roles<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides identity primitives for humans and workloads.<\/li>\n<li><strong>Why it matters:<\/strong> Choosing the right primitive reduces credential risk.<\/li>\n<li><strong>Practical benefit:<\/strong> Use groups for humans; roles for workloads; avoid long-lived keys where possible.<\/li>\n<li><strong>Caveats:<\/strong> IAM users are often legacy for humans; AWS commonly recommends federation\/SSO for workforce access (via IAM Identity Center).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Managed policies (AWS managed and customer managed)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Reusable permission sets attachable to many identities.<\/li>\n<li><strong>Why it matters:<\/strong> Central updates and consistent permissions.<\/li>\n<li><strong>Practical benefit:<\/strong> Easier governance and change control than inline policies.<\/li>\n<li><strong>Caveats:<\/strong> AWS managed policies may change over time; evaluate blast radius.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Inline policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Embeds a policy directly in a single principal (user\/group\/role).<\/li>\n<li><strong>Why it matters:<\/strong> Useful for one-off exceptions.<\/li>\n<li><strong>Practical benefit:<\/strong> Tight coupling can be convenient for isolated roles.<\/li>\n<li><strong>Caveats:<\/strong> Harder to audit and reuse; can increase drift.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM roles and trust policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Roles are assumed; trust policies define <strong>who can assume<\/strong>.<\/li>\n<li><strong>Why it matters:<\/strong> Enables secure temporary access, cross-account access, and service-to-service access.<\/li>\n<li><strong>Practical benefit:<\/strong> Avoids distributing keys; supports session tagging and constraints.<\/li>\n<li><strong>Caveats:<\/strong> Confusing separation: trust policy controls <strong>who can assume<\/strong>, permissions policy controls <strong>what the role can do<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Federation (SAML 2.0 and OIDC)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows external identities to obtain AWS credentials by assuming roles.<\/li>\n<li><strong>Why it matters:<\/strong> Central identity lifecycle in your IdP; reduces IAM users.<\/li>\n<li><strong>Practical benefit:<\/strong> Integrate with enterprise identity providers and CI\/CD identity tokens.<\/li>\n<li><strong>Caveats:<\/strong> Setup details depend on IdP; validate claims\/conditions to prevent token misuse.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Multi-Factor Authentication (MFA)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Adds a second factor for IAM user sign-in; can be required for actions through conditions.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents account takeover from password compromise.<\/li>\n<li><strong>Practical benefit:<\/strong> Strong baseline security for privileged users.<\/li>\n<li><strong>Caveats:<\/strong> MFA enforcement in policies requires thoughtful rollouts to avoid lockouts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Password policy (account-level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Enforces password complexity and rotation settings for IAM users.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces weak password risk for accounts that still use IAM user console passwords.<\/li>\n<li><strong>Practical benefit:<\/strong> Central enforcement without per-user management.<\/li>\n<li><strong>Caveats:<\/strong> Doesn\u2019t apply to federated users managed by an external IdP.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Access keys (for IAM users)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Long-term credentials used by CLI\/SDK.<\/li>\n<li><strong>Why it matters:<\/strong> Many breaches involve leaked keys.<\/li>\n<li><strong>Practical benefit:<\/strong> Still required for some legacy use cases.<\/li>\n<li><strong>Caveats:<\/strong> Prefer roles\/temporary credentials. If used, rotate and scope tightly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions boundaries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Sets the maximum permissions a role or user can receive, even if other policies allow more.<\/li>\n<li><strong>Why it matters:<\/strong> Enables delegation safely and prevents privilege escalation.<\/li>\n<li><strong>Practical benefit:<\/strong> Platform teams can allow app teams to create roles within guardrails.<\/li>\n<li><strong>Caveats:<\/strong> Boundaries don\u2019t grant permissions; they only limit the maximum.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Policy conditions and advanced controls<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Adds constraints (MFA present, source IP, time, VPC endpoint, tag conditions).<\/li>\n<li><strong>Why it matters:<\/strong> Reduces risk from credential theft and limits lateral movement.<\/li>\n<li><strong>Practical benefit:<\/strong> \u201cOnly from corporate IP range,\u201d \u201conly via VPC endpoint,\u201d \u201conly with MFA.\u201d<\/li>\n<li><strong>Caveats:<\/strong> Overly strict conditions can break automation; test carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service-linked roles<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Predefined roles linked to AWS services to perform actions on your behalf.<\/li>\n<li><strong>Why it matters:<\/strong> Many AWS services require them for normal operation.<\/li>\n<li><strong>Practical benefit:<\/strong> Simplifies setup and reduces misconfiguration.<\/li>\n<li><strong>Caveats:<\/strong> Managed by AWS service; you typically should not modify them.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Access Advisor and last accessed information<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Shows when services\/permissions were last used.<\/li>\n<li><strong>Why it matters:<\/strong> Helps remove unused permissions.<\/li>\n<li><strong>Practical benefit:<\/strong> Data-driven least-privilege refinement.<\/li>\n<li><strong>Caveats:<\/strong> Interpretation requires care; \u201cnot accessed\u201d doesn\u2019t always mean \u201cnever needed.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Credential report<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Generates a report of IAM users and credential status (password, access keys, rotation).<\/li>\n<li><strong>Why it matters:<\/strong> Supports audits and hygiene checks.<\/li>\n<li><strong>Practical benefit:<\/strong> Easy way to find old keys, missing MFA, unused users.<\/li>\n<li><strong>Caveats:<\/strong> Only covers IAM users, not federated identities.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM policy simulator<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Tests how policies evaluate for specific actions\/resources.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents outages caused by permission mistakes.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster debugging and safer policy changes.<\/li>\n<li><strong>Caveats:<\/strong> Simulations approximate evaluation; always validate with real calls where possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM Access Analyzer (IAM family feature)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Helps identify resources shared with external principals and validate policies.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents unintended public\/cross-account access.<\/li>\n<li><strong>Practical benefit:<\/strong> Findings for S3 buckets, IAM roles, KMS keys, etc. (supported resource types vary).<\/li>\n<li><strong>Caveats:<\/strong> Coverage varies; confirm supported resource types and regions in docs.<\/li>\n<\/ul>\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 architecture<\/h3>\n\n\n\n<p>IAM is part of AWS\u2019s control plane for access control:\n1. A principal (user\/role\/service\/federated identity) makes an AWS API request.\n2. The request is authenticated (signature, token, or federation).\n3. IAM authorization evaluates:\n   &#8211; Identity-based policies (attached to user\/role\/group)\n   &#8211; Resource-based policies (like S3 bucket policies), where applicable\n   &#8211; Session policies (for assumed roles), where applicable\n   &#8211; Permissions boundaries, where applicable\n   &#8211; AWS Organizations SCPs, if applicable\n4. If allowed, the target AWS service performs the action.\n5. Events can be logged in AWS CloudTrail for auditing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request, data, and control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control flow:<\/strong> IAM policies are defined and attached via IAM APIs\/console\/IaC.<\/li>\n<li><strong>Runtime flow:<\/strong> Every AWS API request checks permissions at request time.<\/li>\n<li><strong>No \u201cdata plane\u201d:<\/strong> IAM does not store your business data; it stores identity and policy metadata.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related AWS services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>AWS STS:<\/strong> Temporary credentials for assumed roles (IAM relies on STS mechanisms).\n&#8211; <strong>AWS CloudTrail:<\/strong> Logs IAM actions and most AWS API calls for auditing.\n&#8211; <strong>Amazon CloudWatch:<\/strong> Alarm\/metrics for suspicious activity typically come from CloudTrail\/CloudWatch Logs integrations.\n&#8211; <strong>AWS Organizations:<\/strong> SCPs for guardrails across accounts; central governance.\n&#8211; <strong>AWS IAM Identity Center:<\/strong> Workforce SSO (separate service) that uses IAM roles\/permission sets underneath.\n&#8211; <strong>AWS Config:<\/strong> Track and evaluate configuration changes (including some IAM-related resource configurations) depending on rules enabled.\n&#8211; <strong>AWS KMS:<\/strong> Often used with IAM policies to control encryption key usage.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM is foundational and does not require many dependencies, but real-world implementations usually depend on:<\/li>\n<li>CloudTrail for auditing<\/li>\n<li>Organizations for multi-account governance<\/li>\n<li>An IdP (SAML\/OIDC) for federation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM supports:<\/li>\n<li>Username\/password for IAM users (console sign-in)<\/li>\n<li>Access keys for programmatic access (discouraged for humans; prefer roles)<\/li>\n<li>Temporary credentials for assumed roles (recommended)<\/li>\n<li>Federation with SAML\/OIDC (recommended for workforce and CI\/CD patterns)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM is a control-plane service accessed via AWS APIs\/console.<\/li>\n<li>You typically don\u2019t \u201cplace IAM in a VPC.\u201d Access is over AWS public endpoints; some organizations use network controls plus policy conditions (for example, restricting actions via VPC endpoints where applicable to the target services).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring, logging, and governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CloudTrail<\/strong> is the baseline for auditing IAM changes and API usage.<\/li>\n<li>Establish governance for:<\/li>\n<li>Policy review and approvals<\/li>\n<li>Permission boundaries and role naming conventions<\/li>\n<li>Key rotation and credential hygiene<\/li>\n<li>Periodic access reviews using last accessed info and credential reports<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[Engineer \/ App] --&gt;|Authenticate| P[Principal&lt;br\/&gt;IAM User \/ Federated Identity \/ Role]\n  P --&gt;|API Request| IAM[IAM Authorization&lt;br\/&gt;Policy Evaluation]\n  IAM --&gt;|Allow\/Deny| S[AWS Service&lt;br\/&gt;e.g., S3, EC2, DynamoDB]\n  IAM --&gt; CT[CloudTrail Event History \/ Trails]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph IdP[External Identity Provider]\n    IDP[SAML \/ OIDC IdP]\n  end\n\n  subgraph Org[AWS Organizations]\n    SCP[SCP Guardrails]\n  end\n\n  subgraph SecAcct[Security Tooling Account]\n    SIEM[Security Monitoring \/ SIEM]\n    AUDITROLE[Central Audit Role]\n  end\n\n  subgraph WorkAcct[Workload Account]\n    APP[Workload: ECS\/Lambda\/EC2]\n    ROLEAPP[App IAM Role]\n    IAMCFG[IAM: Policies, Roles, Boundaries]\n    LOG[CloudTrail]\n    S3LOG[S3 Log Archive Bucket]\n  end\n\n  IDP --&gt;|Federate \/ Assume Role| IAMCFG\n  U[Admins\/Developers] --&gt;|SSO\/Federation| IDP\n\n  APP --&gt;|Assume Role \/ Use Role creds| ROLEAPP\n  ROLEAPP --&gt;|Call APIs| AWSRES[(AWS Resources)]\n\n  IAMCFG --&gt; SCP\n  IAMCFG --&gt; LOG\n  LOG --&gt; S3LOG\n  S3LOG --&gt; SIEM\n  AUDITROLE --&gt;|Assume cross-account| IAMCFG\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 requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An <strong>AWS account<\/strong> you can administer (personal sandbox preferred).<\/li>\n<li>If you\u2019re in an organization-managed environment, ensure you\u2019re allowed to create IAM users\/roles and S3 buckets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions needed (to follow the lab)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Permissions to manage IAM and S3 (an admin-style role is easiest for a lab).<\/li>\n<li>At minimum, you\u2019ll need permissions like:<\/li>\n<li><code>iam:CreateUser<\/code>, <code>iam:CreateRole<\/code>, <code>iam:CreatePolicy<\/code>, <code>iam:AttachRolePolicy<\/code>, <code>iam:PutRolePolicy<\/code>, <code>iam:PassRole<\/code>, <code>iam:CreateAccessKey<\/code>, <code>iam:DeleteAccessKey<\/code>, etc.<\/li>\n<li><code>s3:CreateBucket<\/code>, <code>s3:PutObject<\/code>, <code>s3:GetObject<\/code>, <code>s3:DeleteObject<\/code>, <code>s3:DeleteBucket<\/code><\/li>\n<li>If your environment uses SCPs, they may block some operations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM itself is generally <strong>no additional charge<\/strong> (verify on the official pricing page).<\/li>\n<li>The lab uses S3, which may incur small costs if you store data (usually minimal for a small test object).<\/li>\n<li>Avoid enabling paid logging destinations unless you intend to.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS CLI v2<\/strong> installed: https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/li>\n<li>A terminal\/shell environment.<\/li>\n<li>Optional: <code>jq<\/code> for JSON parsing (helpful but not required).<\/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>IAM is global, but the lab uses <strong>Amazon S3<\/strong>, which is regional. Choose a region you normally use.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM has quotas for number of users\/roles\/policies and policy document sizes.<\/li>\n<li>Always verify current IAM quotas in official docs: https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/reference_iam-quotas.html<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Amazon S3 (for the lab\u2019s \u201crestricted bucket access\u201d example)<\/li>\n<li>AWS STS (used behind the scenes for <code>assume-role<\/code>)<\/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\">IAM pricing model (current model overview)<\/h3>\n\n\n\n<p>AWS Identity and Access Management (IAM) is generally offered with <strong>no additional charge<\/strong> for using core IAM features (creating users, roles, groups, policies, and using policy evaluation). You pay for other AWS services you use alongside IAM.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page: https:\/\/aws.amazon.com\/iam\/pricing\/<\/li>\n<li>AWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/li>\n<\/ul>\n\n\n\n<p>Always verify details in the official pricing page because AWS occasionally updates pricing and because related features (logging, analysis, or external integrations) may have separate costs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions<\/h3>\n\n\n\n<p>For IAM itself, the \u201cdimension\u201d is typically:\n&#8211; <strong>$0 for IAM resources and policy evaluation<\/strong> (verify current terms)<\/p>\n\n\n\n<p>However, your <em>identity architecture<\/em> can influence costs indirectly via:\n&#8211; <strong>AWS CloudTrail<\/strong>: storing logs in S3, sending to CloudWatch Logs, CloudTrail Lake usage\n&#8211; <strong>Amazon S3<\/strong>: log archive storage, access logs, policy-driven data access patterns\n&#8211; <strong>AWS Config<\/strong>: configuration recording and rule evaluations\n&#8211; <strong>Security tooling<\/strong>: GuardDuty, Security Hub, SIEM ingestion costs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM is typically not billed separately; \u201cfree tier\u201d is less relevant than for metered services.<\/li>\n<li>CloudTrail has an <strong>Event history<\/strong> view at no additional charge (trail delivery\/storage is separate). Verify current CloudTrail pricing\/behavior: https:\/\/aws.amazon.com\/cloudtrail\/pricing\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (indirect)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Audit logging volume<\/strong>: more accounts\/regions\/services \u2192 more CloudTrail events \u2192 more storage\/ingestion.<\/li>\n<li><strong>Centralized logging retention<\/strong>: long retention in S3\/CloudTrail Lake increases cost.<\/li>\n<li><strong>High-churn CI\/CD<\/strong>: frequent role sessions can increase log volume (not IAM cost, but logging\/observability cost).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Turning on organization-wide trails that deliver to CloudWatch Logs can become costly.<\/li>\n<li>Storing logs in S3 with replication\/versioning can increase storage.<\/li>\n<li>SIEM ingestion billed per GB can dominate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM itself isn\u2019t a data-transfer-heavy service.<\/li>\n<li>Logging exports and SIEM ingestion can cause data transfer between regions\/accounts.<\/li>\n<\/ul>\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>Use CloudTrail Event history for quick investigations; use trails intentionally for compliance and retention needs.<\/li>\n<li>Centralize logs but apply lifecycle policies in S3 (transition to infrequent access\/archive where appropriate).<\/li>\n<li>Reduce noise: focus on management events and required data events (S3 data events can be high volume\u2014enable only when needed).<\/li>\n<li>Prefer role-based access to reduce credential sprawl and the operational cost of key rotation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM: $0 (verify).<\/li>\n<li>S3: store a few KB\/MB test objects \u2192 typically negligible cost.<\/li>\n<li>CloudTrail: rely on Event history only \u2192 no extra storage cost (verify current CloudTrail terms).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations (conceptual)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-account organization with centralized logging:<\/li>\n<li>S3 log archive storage for months\/years<\/li>\n<li>Potential CloudTrail Lake queries and retention<\/li>\n<li>Optional CloudWatch Logs streaming and metrics filters<\/li>\n<li>SIEM ingestion and long-term retention\nThese costs are not \u201cIAM costs,\u201d but they are often required to operate IAM securely at scale.<\/li>\n<\/ul>\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>Implement a practical IAM pattern:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create a <strong>private S3 bucket<\/strong> with a test object.<\/li>\n<li>Create an IAM <strong>role<\/strong> that has <strong>read-only access<\/strong> to only that bucket\/object.<\/li>\n<li>Create an IAM <strong>user<\/strong> that has <strong>no S3 permissions<\/strong> but is allowed to <strong>assume the role<\/strong>.<\/li>\n<li>Use AWS CLI to <strong>assume the role<\/strong> and access the object using <strong>temporary credentials<\/strong>.<\/li>\n<li>Validate access and review audit events.<\/li>\n<li>Clean up all resources.<\/li>\n<\/ol>\n\n\n\n<p>This lab teaches the core IAM building blocks: <strong>policies<\/strong>, <strong>roles<\/strong>, <strong>trust relationships<\/strong>, and <strong>temporary credentials<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You will use one AWS account.<\/li>\n<li>You will create:<\/li>\n<li>1 S3 bucket + 1 object<\/li>\n<li>1 IAM policy (customer managed) for S3 read-only to that bucket<\/li>\n<li>1 IAM role with that policy attached<\/li>\n<li>1 IAM user with a policy allowing <code>sts:AssumeRole<\/code> into the role<\/li>\n<li>1 access key for the IAM user (lab-only; delete during cleanup)<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Security note: For real production usage, avoid long-lived access keys for humans and prefer federation (for example, AWS IAM Identity Center). This lab uses an IAM user access key to demonstrate role assumption mechanics in a controlled environment.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Choose variables and confirm your AWS CLI identity<\/h3>\n\n\n\n<p>1) Pick a region for S3 operations (example: <code>us-east-1<\/code>).<br\/>\n2) Choose a globally unique bucket name (S3 bucket names are global).<\/p>\n\n\n\n<p>Set variables (edit as needed):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export AWS_REGION=\"us-east-1\"\nexport BUCKET_NAME=\"iam-lab-restricted-bucket-$(date +%s)\"\nexport OBJECT_KEY=\"hello.txt\"\nexport ROLE_NAME=\"IamLabReadOnlyRole\"\nexport USER_NAME=\"IamLabAssumerUser\"\nexport POLICY_NAME=\"IamLabS3ReadOnlyPolicy\"\n<\/code><\/pre>\n\n\n\n<p>Confirm who you are currently authenticated as (should be an admin or sufficiently privileged role):<\/p>\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 your AWS Account ID and ARN. Save the <code>Account<\/code> value for later:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export ACCOUNT_ID=\"$(aws sts get-caller-identity --query Account --output text)\"\necho \"$ACCOUNT_ID\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a private S3 bucket and upload a test object<\/h3>\n\n\n\n<p>Create the bucket.<\/p>\n\n\n\n<p>Notes:\n&#8211; In <code>us-east-1<\/code>, bucket creation syntax differs slightly. The following approach works across regions by conditionally setting <code>LocationConstraint<\/code>.<\/p>\n\n\n\n<pre><code class=\"language-bash\">if [ \"$AWS_REGION\" = \"us-east-1\" ]; then\n  aws s3api create-bucket --bucket \"$BUCKET_NAME\" --region \"$AWS_REGION\"\nelse\n  aws s3api create-bucket --bucket \"$BUCKET_NAME\" --region \"$AWS_REGION\" \\\n    --create-bucket-configuration LocationConstraint=\"$AWS_REGION\"\nfi\n<\/code><\/pre>\n\n\n\n<p>Block public access (recommended default; many accounts already enforce this):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api put-public-access-block \\\n  --bucket \"$BUCKET_NAME\" \\\n  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true\n<\/code><\/pre>\n\n\n\n<p>Upload a file:<\/p>\n\n\n\n<pre><code class=\"language-bash\">echo \"Hello from the IAM lab. Timestamp: $(date -Iseconds)\" &gt; \"$OBJECT_KEY\"\naws s3api put-object --bucket \"$BUCKET_NAME\" --key \"$OBJECT_KEY\" --body \"$OBJECT_KEY\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The object upload returns an ETag. You can verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api head-object --bucket \"$BUCKET_NAME\" --key \"$OBJECT_KEY\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a customer managed IAM policy for S3 read-only to just this bucket<\/h3>\n\n\n\n<p>Create a policy document that allows only:\n&#8211; <code>s3:ListBucket<\/code> on the bucket\n&#8211; <code>s3:GetObject<\/code> on objects within the bucket<\/p>\n\n\n\n<p>Create the JSON policy file:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; s3-readonly-single-bucket-policy.json &lt;&lt;EOF\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"ListOnlyThisBucket\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"s3:ListBucket\",\n      \"Resource\": \"arn:aws:s3:::${BUCKET_NAME}\"\n    },\n    {\n      \"Sid\": \"ReadOnlyObjectsInThisBucket\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"s3:GetObject\",\n      \"Resource\": \"arn:aws:s3:::${BUCKET_NAME}\/*\"\n    }\n  ]\n}\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create the IAM policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export POLICY_ARN=\"$(aws iam create-policy \\\n  --policy-name \"$POLICY_NAME\" \\\n  --policy-document file:\/\/s3-readonly-single-bucket-policy.json \\\n  --query Policy.Arn --output text)\"\n\necho \"$POLICY_ARN\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You get a policy ARN like <code>arn:aws:iam::&lt;account-id&gt;:policy\/IamLabS3ReadOnlyPolicy<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create an IAM role that can be assumed by principals in your account<\/h3>\n\n\n\n<p>Now define a <strong>trust policy<\/strong> (who can assume the role). For this lab, we\u2019ll allow principals in the same account to assume it, but we will later grant the specific user permission to assume it.<\/p>\n\n\n\n<p>Create the trust policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; trust-policy.json &lt;&lt;EOF\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowAssumeRoleFromThisAccount\",\n      \"Effect\": \"Allow\",\n      \"Principal\": { \"AWS\": \"arn:aws:iam::${ACCOUNT_ID}:root\" },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create the role:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam create-role \\\n  --role-name \"$ROLE_NAME\" \\\n  --assume-role-policy-document file:\/\/trust-policy.json\n<\/code><\/pre>\n\n\n\n<p>Attach the S3 read-only policy to the role:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam attach-role-policy \\\n  --role-name \"$ROLE_NAME\" \\\n  --policy-arn \"$POLICY_ARN\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Role exists and has the managed policy attached.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam list-attached-role-policies --role-name \"$ROLE_NAME\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create an IAM user with permission to assume the role (but no direct S3 access)<\/h3>\n\n\n\n<p>Create the user:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam create-user --user-name \"$USER_NAME\"\n<\/code><\/pre>\n\n\n\n<p>Create a policy that allows assuming only this role:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export ROLE_ARN=\"arn:aws:iam::${ACCOUNT_ID}:role\/${ROLE_NAME}\"\n\ncat &gt; assume-role-policy.json &lt;&lt;EOF\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowAssumeSpecificRole\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": \"${ROLE_ARN}\"\n    }\n  ]\n}\nEOF\n<\/code><\/pre>\n\n\n\n<p>Attach the inline policy to the user (fine for a lab; in production prefer customer managed policies when reusable):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam put-user-policy \\\n  --user-name \"$USER_NAME\" \\\n  --policy-name \"AllowAssumeRole-${ROLE_NAME}\" \\\n  --policy-document file:\/\/assume-role-policy.json\n<\/code><\/pre>\n\n\n\n<p>Create an access key for the user (lab-only):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam create-access-key --user-name \"$USER_NAME\" &gt; iam-lab-access-key.json\ncat iam-lab-access-key.json\n<\/code><\/pre>\n\n\n\n<p>Extract credentials (using AWS CLI query):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export LAB_ACCESS_KEY_ID=\"$(aws iam create-access-key --user-name \"$USER_NAME\" --query AccessKey.AccessKeyId --output text 2&gt;\/dev\/null || true)\"\n<\/code><\/pre>\n\n\n\n<p>The above command would create a second key if run; instead, parse the JSON you already created. If you have <code>jq<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export LAB_ACCESS_KEY_ID=\"$(jq -r '.AccessKey.AccessKeyId' iam-lab-access-key.json)\"\nexport LAB_SECRET_ACCESS_KEY=\"$(jq -r '.AccessKey.SecretAccessKey' iam-lab-access-key.json)\"\n<\/code><\/pre>\n\n\n\n<p>If you don\u2019t have <code>jq<\/code>, open <code>iam-lab-access-key.json<\/code> and copy the <code>AccessKeyId<\/code> and <code>SecretAccessKey<\/code> values manually, then export them:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export LAB_ACCESS_KEY_ID=\"PASTE_ACCESS_KEY_ID\"\nexport LAB_SECRET_ACCESS_KEY=\"PASTE_SECRET_ACCESS_KEY\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have an IAM user that can call <code>sts:AssumeRole<\/code> into your lab role.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Verify the IAM user cannot access S3 directly<\/h3>\n\n\n\n<p>Use environment variables to act as the IAM user:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export AWS_ACCESS_KEY_ID=\"$LAB_ACCESS_KEY_ID\"\nexport AWS_SECRET_ACCESS_KEY=\"$LAB_SECRET_ACCESS_KEY\"\nunset AWS_SESSION_TOKEN\n<\/code><\/pre>\n\n\n\n<p>Attempt to read the object directly (should fail because the user has no S3 permissions):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api get-object --bucket \"$BUCKET_NAME\" --key \"$OBJECT_KEY\" \/tmp\/\"$OBJECT_KEY\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Access denied (for example, <code>AccessDenied<\/code>). This is good\u2014it confirms least privilege.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Assume the role and access S3 using temporary credentials<\/h3>\n\n\n\n<p>Assume the role:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws sts assume-role \\\n  --role-arn \"$ROLE_ARN\" \\\n  --role-session-name \"iam-lab-session\" \\\n  &gt; assumed-role-creds.json\n\ncat assumed-role-creds.json\n<\/code><\/pre>\n\n\n\n<p>Export the temporary credentials (with <code>jq<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export AWS_ACCESS_KEY_ID=\"$(jq -r '.Credentials.AccessKeyId' assumed-role-creds.json)\"\nexport AWS_SECRET_ACCESS_KEY=\"$(jq -r '.Credentials.SecretAccessKey' assumed-role-creds.json)\"\nexport AWS_SESSION_TOKEN=\"$(jq -r '.Credentials.SessionToken' assumed-role-creds.json)\"\n<\/code><\/pre>\n\n\n\n<p>Verify your caller identity is now the role session:<\/p>\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> The ARN should show an assumed role session (contains <code>assumed-role\/IamLabReadOnlyRole\/iam-lab-session<\/code>).<\/p>\n\n\n\n<p>Now read the object:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api get-object --bucket \"$BUCKET_NAME\" --key \"$OBJECT_KEY\" \/tmp\/\"$OBJECT_KEY\"\ncat \/tmp\/\"$OBJECT_KEY\"\n<\/code><\/pre>\n\n\n\n<p>List the bucket (should succeed):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api list-objects-v2 --bucket \"$BUCKET_NAME\"\n<\/code><\/pre>\n\n\n\n<p>Try to write an object (should fail, because role is read-only):<\/p>\n\n\n\n<pre><code class=\"language-bash\">echo \"should fail\" &gt; \/tmp\/should-fail.txt\naws s3api put-object --bucket \"$BUCKET_NAME\" --key \"should-fail.txt\" --body \/tmp\/should-fail.txt\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>AccessDenied<\/code> for <code>PutObject<\/code>. This confirms the role policy is doing what you intended.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Review auditability (CloudTrail Event history)<\/h3>\n\n\n\n<p>Without creating any CloudTrail trail (which can add storage costs), you can check <strong>CloudTrail Event history<\/strong> in the AWS Console:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open <strong>AWS CloudTrail<\/strong> console.<\/li>\n<li>Go to <strong>Event history<\/strong>.<\/li>\n<li>Filter by <strong>Event name<\/strong>:\n   &#8211; <code>AssumeRole<\/code><\/li>\n<li>Filter by <strong>Username<\/strong> or <strong>Resource name<\/strong> (role name).<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> You should see an <code>AssumeRole<\/code> event from the IAM user.<\/p>\n\n\n\n<blockquote>\n<p>If you do not see events, verify CloudTrail Event history availability and retention in your account\/region, and confirm you\u2019re looking in the correct region for the console view. CloudTrail Event history behavior can vary; verify in official CloudTrail docs.<\/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>You have successfully implemented:\n&#8211; A <strong>scoped S3 policy<\/strong> tied to a specific bucket ARN\n&#8211; An IAM <strong>role<\/strong> with that permission policy\n&#8211; An IAM <strong>user<\/strong> that can assume the role but cannot access S3 directly\n&#8211; A working <strong>STS AssumeRole<\/strong> flow producing <strong>temporary credentials<\/strong>\n&#8211; Proof that <strong>read<\/strong> succeeds and <strong>write<\/strong> fails under the role<\/p>\n\n\n\n<p>Run these final validation commands while still using the assumed role credentials:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws sts get-caller-identity\naws s3api get-object --bucket \"$BUCKET_NAME\" --key \"$OBJECT_KEY\" \/tmp\/\"$OBJECT_KEY\"\n<\/code><\/pre>\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<p>1) <strong><code>AccessDenied<\/code> when calling <code>sts:AssumeRole<\/code><\/strong>\n&#8211; Cause: The IAM user lacks permission to assume the role, or the role trust policy doesn\u2019t trust the principal.\n&#8211; Fix:\n  &#8211; Confirm the user has <code>sts:AssumeRole<\/code> permission for that role ARN.\n  &#8211; Confirm the role trust policy allows your account (or the specific user\/role) as principal.\n  &#8211; Check for permission boundaries or SCPs blocking STS.<\/p>\n\n\n\n<p>2) <strong><code>AccessDenied<\/code> when reading the object after assuming the role<\/strong>\n&#8211; Cause: Role permissions policy does not include the correct bucket\/object ARNs.\n&#8211; Fix:\n  &#8211; Ensure <code>s3:GetObject<\/code> includes <code>arn:aws:s3:::bucket-name\/*<\/code>\n  &#8211; Ensure <code>s3:ListBucket<\/code> includes <code>arn:aws:s3:::bucket-name<\/code> (no trailing <code>\/*<\/code>)\n  &#8211; Verify you assumed the correct role (check <code>get-caller-identity<\/code>).<\/p>\n\n\n\n<p>3) <strong>S3 bucket creation fails<\/strong>\n&#8211; Cause: Bucket name not globally unique or blocked by SCP\/policy.\n&#8211; Fix: Change <code>BUCKET_NAME<\/code> and retry. Check org policies.<\/p>\n\n\n\n<p>4) <strong>CLI credential confusion<\/strong>\n&#8211; Cause: Environment variables override your usual CLI profile.\n&#8211; Fix:\n  &#8211; Print: <code>env | grep AWS_<\/code>\n  &#8211; Clear: <code>unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN<\/code>\n  &#8211; Use named profiles for clarity (recommended for real work).<\/p>\n\n\n\n<p>5) <strong>You accidentally created two access keys<\/strong>\n&#8211; Fix: List and delete extra keys:\n  &#8211; <code>aws iam list-access-keys --user-name \"$USER_NAME\"<\/code>\n  &#8211; <code>aws iam delete-access-key --user-name \"$USER_NAME\" --access-key-id &lt;key-id&gt;<\/code><\/p>\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>To avoid ongoing risk\/cost, delete everything you created.<\/p>\n\n\n\n<p>1) Clear your environment credentials so you don\u2019t continue using temporary credentials by accident:<\/p>\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<p>2) Delete the S3 object and bucket (use your admin credentials\/profile again):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api delete-object --bucket \"$BUCKET_NAME\" --key \"$OBJECT_KEY\"\naws s3api delete-bucket --bucket \"$BUCKET_NAME\"\n<\/code><\/pre>\n\n\n\n<p>3) Detach role policy and delete role:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam detach-role-policy --role-name \"$ROLE_NAME\" --policy-arn \"$POLICY_ARN\"\naws iam delete-role --role-name \"$ROLE_NAME\"\n<\/code><\/pre>\n\n\n\n<p>4) Delete the IAM user (delete keys and inline policy first):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Delete access keys\naws iam list-access-keys --user-name \"$USER_NAME\"\n\n# If you stored the key ID in the JSON:\n# Use jq to retrieve it (optional):\n# jq -r '.AccessKey.AccessKeyId' iam-lab-access-key.json\n\naws iam delete-access-key --user-name \"$USER_NAME\" --access-key-id \"$LAB_ACCESS_KEY_ID\"\n\n# Delete inline policy\naws iam delete-user-policy --user-name \"$USER_NAME\" --policy-name \"AllowAssumeRole-${ROLE_NAME}\"\n\n# Delete user\naws iam delete-user --user-name \"$USER_NAME\"\n<\/code><\/pre>\n\n\n\n<p>5) Delete the customer managed policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam delete-policy --policy-arn \"$POLICY_ARN\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> No lab IAM principals remain, and the S3 bucket is removed.<\/p>\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>Prefer roles over users<\/strong> for workloads and automation; use temporary credentials.<\/li>\n<li><strong>Use a multi-account strategy<\/strong> (often via AWS Organizations) to isolate environments (prod\/non-prod) and reduce blast radius.<\/li>\n<li><strong>Centralize sensitive operations<\/strong> (logging, security tooling) in dedicated accounts and use cross-account roles for access.<\/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 least privilege<\/strong>: start with minimal permissions, expand based on measured needs.<\/li>\n<li><strong>Avoid root usage<\/strong>:<\/li>\n<li>Enable MFA on the root user.<\/li>\n<li>Do not create root access keys.<\/li>\n<li>Use root only for tasks that require it (rare).<\/li>\n<li><strong>Use managed policies<\/strong> where possible for reuse and governance.<\/li>\n<li><strong>Use permission boundaries<\/strong> to prevent privilege escalation when delegating role creation.<\/li>\n<li><strong>Constrain access with conditions<\/strong>:<\/li>\n<li>MFA required for sensitive actions<\/li>\n<li><code>aws:PrincipalTag<\/code> \/ resource tags for ABAC<\/li>\n<li>Source IP \/ VPC endpoint conditions where appropriate<\/li>\n<li><strong>Protect role assumption<\/strong>:<\/li>\n<li>Restrict <code>sts:AssumeRole<\/code> to specific principals<\/li>\n<li>In cross-account setups, use <code>ExternalId<\/code> where appropriate (verify best practice guidance for your scenario)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices (indirect)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable CloudTrail trails intentionally; manage retention.<\/li>\n<li>Apply S3 lifecycle policies to logs.<\/li>\n<li>Avoid enabling high-volume data events unless required.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices (operational scalability)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep policies modular and readable; break up by domain (S3-read, KMS-use, DynamoDB-read).<\/li>\n<li>Use <strong>ABAC<\/strong> to reduce role explosion when you have many teams\/projects.<\/li>\n<li>Standardize naming conventions to avoid confusion and mis-assumption of roles.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Infrastructure as Code for IAM (CloudFormation\/CDK\/Terraform) to avoid drift.<\/li>\n<li>Use version control and peer review for policy changes.<\/li>\n<li>Have break-glass procedures and tested recovery paths.<\/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>Run periodic access reviews:<\/li>\n<li>Remove unused permissions using access advisor\/last accessed data.<\/li>\n<li>Identify stale access keys and disable\/delete them.<\/li>\n<li>Monitor for suspicious activity using CloudTrail + security tooling.<\/li>\n<li>Document role purpose, trust relationships, and allowed actions.<\/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>Naming:<\/li>\n<li><code>RoleAppOrderServiceProd<\/code><\/li>\n<li><code>RoleCICDDeployProd<\/code><\/li>\n<li><code>PolicyS3ReadArtifacts<\/code><\/li>\n<li>Tag IAM roles where supported and use tags for ABAC:<\/li>\n<li><code>Environment=Prod<\/code><\/li>\n<li><code>Team=Payments<\/code><\/li>\n<li><code>App=OrderService<\/code><\/li>\n<li>Define ownership:<\/li>\n<li>Every role\/policy should have an owner and review date (tracked in IaC repo and\/or tags where feasible).<\/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>IAM is the authorization backbone for AWS.<\/li>\n<li>Key security choices:<\/li>\n<li>Federation\/SSO for humans vs IAM users<\/li>\n<li>Roles for workloads<\/li>\n<li>Least privilege policies<\/li>\n<li>Separation of duties (IAM admin vs workload operator)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM stores identity metadata; encryption at rest and in transit is handled by AWS.<\/li>\n<li>Your responsibility: ensure that access to encryption services (like AWS KMS) is properly controlled via IAM policies and KMS key policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM APIs are accessed via AWS endpoints.<\/li>\n<li>Reduce risk by:<\/li>\n<li>Limiting who can call sensitive IAM APIs<\/li>\n<li>Using conditions (MFA, IP restrictions) where appropriate<\/li>\n<li>Using private access patterns for target services (for example, S3 via VPC endpoints) and coupling them with policy conditions<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid long-term access keys for humans.<\/li>\n<li>If access keys exist:<\/li>\n<li>Rotate regularly<\/li>\n<li>Store in a secrets manager (not in repos)<\/li>\n<li>Detect leakage using tooling and alerts<\/li>\n<li>Prefer:<\/li>\n<li>Role assumption<\/li>\n<li>Federation (SAML\/OIDC)<\/li>\n<li>Short session durations where feasible<\/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>Use <strong>AWS CloudTrail<\/strong> to log IAM actions and API activity.<\/li>\n<li>Protect logs:<\/li>\n<li>Centralize<\/li>\n<li>Restrict access<\/li>\n<li>Use retention policies<\/li>\n<li>Consider write-once\/read-many approaches (implementation depends on requirements)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>IAM supports compliance by enabling:\n&#8211; Access controls (least privilege)\n&#8211; Evidence (CloudTrail logs, credential reports, policy documents)\n&#8211; Separation of duties<\/p>\n\n\n\n<p>Compliance still requires process:\n&#8211; Access request approvals\n&#8211; Periodic reviews\n&#8211; Incident response procedures<\/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 root account for daily tasks<\/li>\n<li>Shared IAM users across multiple humans<\/li>\n<li>Broad policies (<code>Action: \"*\"<\/code>, <code>Resource: \"*\"<\/code>) without strong justification<\/li>\n<li>Wildcard role trust policies enabling unintended assumption<\/li>\n<li>Long-lived access keys for CI\/CD stored in plaintext<\/li>\n<li>Ignoring unused permissions and stale identities<\/li>\n<li>Lack of MFA for privileged access<\/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>Use IAM Identity Center (workforce) where appropriate and map users to roles with least privilege.<\/li>\n<li>Use permissions boundaries for delegated administration.<\/li>\n<li>Implement a standard: \u201cNo workload uses long-term keys; workloads use roles.\u201d<\/li>\n<li>Require MFA for sensitive operations and role assumption for privileged roles (carefully phased).<\/li>\n<li>Continuously validate policies using policy simulation and access analysis tooling.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ behavior gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Policy complexity and sprawl:<\/strong> Too many roles and one-off inline policies become unmanageable.<\/li>\n<li><strong>Eventual consistency:<\/strong> IAM changes can sometimes take time to propagate. This can cause transient <code>AccessDenied<\/code> or \u201cnot found\u201d behavior right after updates.<\/li>\n<li><strong>Trust vs permission confusion:<\/strong> Many outages come from mixing up:<\/li>\n<li>Trust policy (who can assume)<\/li>\n<li>Permission policy (what can be done after assumed)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM enforces quotas on:<\/li>\n<li>Number of users, groups, roles, policies per account<\/li>\n<li>Policy document sizes<\/li>\n<li>Attachments per principal<\/li>\n<li>Quotas can change; verify current values here: https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/reference_iam-quotas.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>IAM is global, but resources you control are regional (S3 buckets, KMS keys, etc.). Always test role permissions in the regions you operate.<\/li>\n<li>Some IAM-adjacent features and analyzers may have region-specific behavior\u2014verify in official docs.<\/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>CloudTrail trails delivered to S3\/CloudWatch Logs and CloudTrail Lake can become significant costs.<\/li>\n<li>S3 access logs and replication increase storage.<\/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 require specific IAM role patterns (service-linked roles).<\/li>\n<li>Some services use resource-based policies heavily (S3, SNS, SQS, KMS) and IAM alone is not the whole story.<\/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>Lockouts due to overly strict MFA conditions or removing your own admin access.<\/li>\n<li>CI\/CD failures from missing <code>iam:PassRole<\/code> or insufficient trust policy configuration.<\/li>\n<li>Misconfigured cross-account roles without external ID or overly broad principals.<\/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 IAM users to federation can require refactoring access patterns, tooling, and onboarding processes.<\/li>\n<li>Migrating from RBAC to ABAC requires consistent tagging discipline.<\/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>AWS authorization can involve multiple policy types (identity-based, resource-based, boundary, SCP). The final decision is the intersection of all applicable controls.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>IAM is foundational in AWS, but you often combine it with other services or choose different identity layers depending on the identity type.<\/p>\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 Identity and Access Management (IAM)<\/strong><\/td>\n<td>AWS resource authorization and workload\/service permissions<\/td>\n<td>Deep AWS integration, fine-grained permissions, roles + temporary credentials<\/td>\n<td>Policy complexity; IAM users not ideal for workforce SSO at scale<\/td>\n<td>Always for AWS authorization; especially for roles and permissions<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS IAM Identity Center<\/strong><\/td>\n<td>Workforce SSO to AWS accounts and apps<\/td>\n<td>Centralized user access, permission sets, SSO UX<\/td>\n<td>Separate service and setup; still relies on IAM roles underneath<\/td>\n<td>Humans logging into AWS at scale; prefer over IAM users<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Organizations (SCPs)<\/strong><\/td>\n<td>Multi-account guardrails<\/td>\n<td>Prevents unsafe actions even by admins in member accounts<\/td>\n<td>Not a replacement for IAM; can cause confusion if not documented<\/td>\n<td>Enterprises with multiple accounts and strong governance needs<\/td>\n<\/tr>\n<tr>\n<td><strong>Amazon Cognito<\/strong><\/td>\n<td>Application end-user identity (customers)<\/td>\n<td>Sign-up\/sign-in, tokens, federation for apps<\/td>\n<td>Not a direct replacement for IAM authorization to AWS APIs<\/td>\n<td>Consumer identity for apps, mobile\/web sign-in<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure RBAC \/ Microsoft Entra ID<\/strong><\/td>\n<td>Azure-native authorization and workforce identity<\/td>\n<td>Strong enterprise identity ecosystem<\/td>\n<td>Not AWS-native; cross-cloud complexity<\/td>\n<td>Azure-centric organizations; for Azure resources<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud IAM<\/strong><\/td>\n<td>GCP authorization<\/td>\n<td>Tight GCP integration<\/td>\n<td>Not AWS-native<\/td>\n<td>GCP-centric workloads<\/td>\n<\/tr>\n<tr>\n<td><strong>Okta \/ Ping \/ Auth0 (IdPs)<\/strong><\/td>\n<td>Central identity across many apps\/clouds<\/td>\n<td>Mature identity lifecycle, MFA, conditional access<\/td>\n<td>Requires integration effort; still map to IAM roles<\/td>\n<td>Federated enterprise access into AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Keycloak (self-managed)<\/strong><\/td>\n<td>Self-hosted IdP and federation<\/td>\n<td>Open-source flexibility<\/td>\n<td>Operational overhead, security patching burden<\/td>\n<td>When you must self-host identity for policy or cost reasons<\/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: Multi-account financial services organization<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\n&#8211; Dozens\/hundreds of AWS accounts across business units.\n&#8211; Strict separation between production and non-production.\n&#8211; Central security team needs audit access; app teams need autonomy without privilege escalation.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; AWS Organizations with separate OUs for prod\/non-prod\/shared services.\n&#8211; SCPs to block unsafe actions (for example, disabling CloudTrail, making S3 public) based on security policy (exact SCPs depend on org requirements).\n&#8211; IAM roles in each account:\n  &#8211; <code>SecurityAuditRole<\/code> (read-only security visibility)\n  &#8211; <code>DeploymentRole<\/code> (CI\/CD deploy permissions)\n  &#8211; <code>OperationsRole<\/code> (limited ops permissions)\n&#8211; Federation through enterprise IdP (SAML\/OIDC) into IAM roles (often via IAM Identity Center).\n&#8211; Permission boundaries on app-team-created roles.<\/p>\n\n\n\n<p><strong>Why AWS Identity and Access Management (IAM) was chosen<\/strong>\n&#8211; IAM roles are the AWS-native mechanism for cross-account access and service-to-service permissions.\n&#8211; Fine-grained policies enable least privilege and strong auditability.\n&#8211; IAM integrates with CloudTrail and Organizations for governance.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Reduced credential sprawl (fewer long-term keys).\n&#8211; Strong audit trail for access and changes.\n&#8211; Faster onboarding\/offboarding through federation and role mapping.\n&#8211; Better blast-radius control via boundaries and SCPs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS startup with a lean engineering team<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\n&#8211; Need secure CI\/CD deployments without storing AWS keys in the repo.\n&#8211; Need simple, understandable permissions without a dedicated security team.<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; Use IAM roles for:\n  &#8211; <code>CICDDeployRole<\/code> (deploy to S3\/ECR\/ECS\/Lambda as needed)\n  &#8211; Service execution roles for runtime services\n&#8211; CI\/CD assumes roles using OIDC federation (provider-specific), removing long-lived secrets.\n&#8211; Minimal policies per service; separate dev\/prod accounts as they grow.<\/p>\n\n\n\n<p><strong>Why AWS Identity and Access Management (IAM) was chosen<\/strong>\n&#8211; Roles and policies provide straightforward least privilege.\n&#8211; Avoids access keys and reduces risk of secret leakage.\n&#8211; Scales as the startup grows without re-platforming identity.<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Cleaner security posture early (fewer secrets).\n&#8211; Faster audits and customer security questionnaires.\n&#8211; Safer deployments with limited blast radius.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) Is AWS Identity and Access Management (IAM) free?<\/h3>\n\n\n\n<p>IAM is generally offered at <strong>no additional charge<\/strong>. You typically pay for related services you use (CloudTrail, S3 log storage, etc.). Verify current details: https:\/\/aws.amazon.com\/iam\/pricing\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Is IAM global or regional?<\/h3>\n\n\n\n<p>IAM is generally treated as a <strong>global service<\/strong> at the account level, controlling access across regions. Some related features can have regional considerations\u2014verify specifics in the official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Should I create IAM users for every engineer?<\/h3>\n\n\n\n<p>Often no. For workforce access, AWS commonly recommends using federation (for example, IAM Identity Center with an IdP). IAM users are still used in some cases, but shared or long-lived credentials increase risk.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) What is the difference between a role and a user?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>User:<\/strong> Long-term identity with credentials (password\/access keys).<\/li>\n<li><strong>Role:<\/strong> Assumed identity with <strong>temporary credentials<\/strong>; no long-term credentials stored in IAM for the role.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) What is the difference between a trust policy and a permissions policy?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Trust policy:<\/strong> Who can assume the role (<code>sts:AssumeRole<\/code>).<\/li>\n<li><strong>Permissions policy:<\/strong> What actions the role can perform after it is assumed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) What is least privilege and why is it hard?<\/h3>\n\n\n\n<p>Least privilege means granting only the permissions needed. It\u2019s hard because applications evolve and AWS permissions are granular. Use logs, access advisor\/last accessed info, and iterative refinement.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) What happens if multiple policies apply?<\/h3>\n\n\n\n<p>AWS evaluates all applicable policies. An <strong>explicit deny<\/strong> overrides allows. The final decision is based on the combined evaluation of identity policies, resource policies, boundaries, and SCPs (when applicable).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) How do I enforce MFA for sensitive actions?<\/h3>\n\n\n\n<p>Use IAM policy <code>Condition<\/code> keys such as <code>aws:MultiFactorAuthPresent<\/code> and enforce MFA on privileged roles\/users. Roll out carefully to avoid lockouts.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) What is <code>iam:PassRole<\/code> and why does it matter?<\/h3>\n\n\n\n<p><code>iam:PassRole<\/code> allows a principal to pass an IAM role to an AWS service (for example, letting Lambda\/EC2 assume it). Mis-scoped <code>PassRole<\/code> can lead to privilege escalation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) How do I grant access to a single S3 bucket?<\/h3>\n\n\n\n<p>Use an IAM policy that scopes:\n&#8211; <code>s3:ListBucket<\/code> to <code>arn:aws:s3:::bucket<\/code>\n&#8211; <code>s3:GetObject<\/code> to <code>arn:aws:s3:::bucket\/*<\/code>\nOptionally combine with an S3 bucket policy for tighter control.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) How do I do cross-account access securely?<\/h3>\n\n\n\n<p>Use an IAM role in the target account with:\n&#8211; A trust policy that allows the source account principal(s)\n&#8211; A permissions policy with least privilege\nOften add conditions (MFA, external ID when appropriate) and log via CloudTrail.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) Can IAM control access to everything in AWS?<\/h3>\n\n\n\n<p>IAM is the core authorization system, but many services also have <strong>resource-based policies<\/strong> (S3, SQS, SNS, KMS) and organization-wide guardrails (SCPs). Effective access control is usually a combination.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) What is ABAC in AWS IAM?<\/h3>\n\n\n\n<p>ABAC (attribute-based access control) uses attributes like tags (principal tags and resource tags) to grant permissions dynamically. It reduces the number of roles\/policies needed in large environments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) How do I audit who has access?<\/h3>\n\n\n\n<p>Use:\n&#8211; IAM credential reports (for IAM users)\n&#8211; Access advisor\/last accessed info\n&#8211; CloudTrail logs for actions taken\n&#8211; IAM Access Analyzer for external access findings (where applicable)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) What\u2019s the best way to manage IAM changes?<\/h3>\n\n\n\n<p>Use Infrastructure as Code + peer review, plus:\n&#8211; Policy simulation testing\n&#8211; Staged rollouts\n&#8211; Continuous logging and alerting<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">16) Can I recover if I lock myself out?<\/h3>\n\n\n\n<p>This depends on what access remains (break-glass role, root access with MFA, organization admins). Plan recovery before enforcing strict restrictions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">17) Are inline policies bad?<\/h3>\n\n\n\n<p>Not inherently, but they are harder to reuse and audit at scale. Prefer managed policies unless there\u2019s a specific reason to keep permissions tightly coupled to one identity.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn AWS Identity and Access Management (IAM)<\/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 IAM User Guide \u2014 https:\/\/docs.aws.amazon.com\/iam\/<\/td>\n<td>Primary reference for IAM concepts, policies, users\/roles, and best practices<\/td>\n<\/tr>\n<tr>\n<td>Official Documentation<\/td>\n<td>IAM JSON Policy Reference \u2014 https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/reference_policies.html<\/td>\n<td>Detailed policy language reference, condition keys, evaluation logic<\/td>\n<\/tr>\n<tr>\n<td>Official Tooling<\/td>\n<td>IAM Policy Simulator \u2014 https:\/\/policysim.aws.amazon.com\/<\/td>\n<td>Safely test policy outcomes before deploying changes<\/td>\n<\/tr>\n<tr>\n<td>Official Pricing<\/td>\n<td>IAM Pricing \u2014 https:\/\/aws.amazon.com\/iam\/pricing\/<\/td>\n<td>Confirms current pricing model (IAM generally no additional charge)<\/td>\n<\/tr>\n<tr>\n<td>Official Pricing Tool<\/td>\n<td>AWS Pricing Calculator \u2014 https:\/\/calculator.aws\/#\/<\/td>\n<td>Estimate indirect costs (CloudTrail, S3, monitoring) around IAM governance<\/td>\n<\/tr>\n<tr>\n<td>Official Documentation<\/td>\n<td>IAM Quotas \u2014 https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/reference_iam-quotas.html<\/td>\n<td>Current limits for roles\/users\/policies and policy sizes<\/td>\n<\/tr>\n<tr>\n<td>Official Documentation<\/td>\n<td>AWS Security Token Service (STS) \u2014 https:\/\/docs.aws.amazon.com\/STS\/latest\/APIReference\/welcome.html<\/td>\n<td>Understand temporary credentials and <code>AssumeRole<\/code> patterns<\/td>\n<\/tr>\n<tr>\n<td>Official Documentation<\/td>\n<td>AWS CloudTrail \u2014 https:\/\/docs.aws.amazon.com\/awscloudtrail\/latest\/userguide\/cloudtrail-user-guide.html<\/td>\n<td>Audit IAM changes and API activity; critical for security operations<\/td>\n<\/tr>\n<tr>\n<td>Official Service Page<\/td>\n<td>IAM Access Analyzer \u2014 https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/what-is-access-analyzer.html<\/td>\n<td>Identify unintended external access; validate policies (capabilities vary)<\/td>\n<\/tr>\n<tr>\n<td>Official Best Practices<\/td>\n<td>IAM Best Practices \u2014 https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/best-practices.html<\/td>\n<td>AWS\u2019s guidance on securing identities and permissions<\/td>\n<\/tr>\n<tr>\n<td>Official Videos<\/td>\n<td>AWS IAM videos (AWS YouTube) \u2014 https:\/\/www.youtube.com\/@amazonwebservices\/search?query=IAM<\/td>\n<td>Practical walkthroughs and updates from AWS<\/td>\n<\/tr>\n<tr>\n<td>Community (Reputable)<\/td>\n<td>AWS Workshops (search IAM-related workshops) \u2014 https:\/\/workshops.aws\/<\/td>\n<td>Hands-on labs; verify workshop freshness and scope<\/td>\n<\/tr>\n<tr>\n<td>Community (Reputable)<\/td>\n<td>AWS Samples on GitHub \u2014 https:\/\/github.com\/aws-samples<\/td>\n<td>Reference implementations; validate any IAM policies before production use<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following training providers are listed as external learning options. Confirm course availability, modes, and schedules on their websites.<\/p>\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>Beginners to experienced DevOps\/SRE\/platform engineers<\/td>\n<td>AWS, DevOps tooling, cloud security fundamentals including IAM patterns<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Students and early-career engineers<\/td>\n<td>DevOps and SCM concepts; may include cloud and IAM 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 and platform teams<\/td>\n<td>Cloud ops practices; may include AWS governance\/IAM operationalization<\/td>\n<td>Check website<\/td>\n<td>https:\/\/cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs and reliability-focused engineers<\/td>\n<td>Reliability + operations; access control and auditability concepts for cloud ops<\/td>\n<td>Check website<\/td>\n<td>https:\/\/sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops and engineering teams exploring AIOps<\/td>\n<td>Monitoring\/operations automation; may touch IAM for secure integrations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/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<p>These sites are listed as training resources\/platforms. Verify specific trainer profiles, course outlines, and credentials directly on each site.<\/p>\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 (verify current offerings)<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps and cloud training (verify IAM coverage)<\/td>\n<td>DevOps engineers, sysadmins<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>DevOps consulting\/training style resources (verify current offerings)<\/td>\n<td>Teams needing practical DevOps implementations<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resources (verify current offerings)<\/td>\n<td>Ops teams and DevOps practitioners<\/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<p>These organizations are listed as potential consulting providers. Confirm service catalogs, references, and engagement models directly with each company.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/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 engineering services (verify offerings)<\/td>\n<td>IAM governance, cloud foundations, automation<\/td>\n<td>Multi-account IAM role design; least-privilege policy refactoring; CI\/CD role hardening<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training (verify offerings)<\/td>\n<td>Cloud enablement, DevOps processes, IAM operational practices<\/td>\n<td>Implement role-based access model; integrate CI\/CD with OIDC; set up auditing and reviews<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services (verify offerings)<\/td>\n<td>DevOps pipelines, cloud operations, access control patterns<\/td>\n<td>Replace static keys with roles; implement permission boundaries; build audit-ready IAM change processes<\/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 IAM<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Basic AWS concepts: accounts, regions, ARNs<\/li>\n<li>Core services you\u2019ll secure: S3, EC2, Lambda, VPC basics<\/li>\n<li>Security basics: authentication vs authorization, MFA, least privilege<\/li>\n<li>CLI basics: profiles, environment variables, shared config\/credentials files<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after IAM<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Organizations<\/strong>: SCPs, multi-account structure<\/li>\n<li><strong>AWS IAM Identity Center<\/strong>: workforce SSO and permission sets<\/li>\n<li><strong>AWS CloudTrail<\/strong> and log security: centralized logging, retention<\/li>\n<li><strong>AWS Config<\/strong> for compliance drift detection<\/li>\n<li>Service-specific access models:<\/li>\n<li>S3 bucket policies<\/li>\n<li>KMS key policies<\/li>\n<li>EKS IAM roles for service accounts (IRSA)<\/li>\n<li>Infrastructure as Code for IAM:<\/li>\n<li>CloudFormation \/ AWS CDK \/ Terraform<\/li>\n<li>Threat detection and response:<\/li>\n<li>GuardDuty, Security Hub, incident response playbooks<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use IAM<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineer \/ cloud administrator<\/li>\n<li>DevOps engineer \/ platform engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Security engineer \/ cloud security engineer<\/li>\n<li>Solutions architect<\/li>\n<li>Compliance\/audit-focused cloud roles<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>AWS certifications change over time; verify the latest AWS certification list: https:\/\/aws.amazon.com\/certification\/\nCommonly relevant paths include:\n&#8211; AWS Certified Cloud Practitioner (foundational)\n&#8211; AWS Certified Solutions Architect (Associate\/Professional)\n&#8211; AWS Certified SysOps Administrator (Associate)\n&#8211; AWS Certified DevOps Engineer (Professional)\n&#8211; AWS Certified Security \u2013 Specialty (if currently available; verify with AWS)<\/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 \u201cleast privilege\u201d policy for a Lambda that reads one DynamoDB table and writes to one S3 prefix.<\/li>\n<li>Implement CI\/CD role assumption using OIDC (GitHub Actions or another provider) and remove static AWS keys.<\/li>\n<li>Create an ABAC model using tags for a multi-team S3 environment.<\/li>\n<li>Build a cross-account audit role pattern across dev\/stage\/prod accounts.<\/li>\n<li>Write a policy linter\/reviewer workflow (manual + policy simulator checks) in CI.<\/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>ARN (Amazon Resource Name):<\/strong> Unique identifier for AWS resources, used in policies.<\/li>\n<li><strong>Authentication:<\/strong> Proving identity (password, access key signature, federated token).<\/li>\n<li><strong>Authorization:<\/strong> Determining what an authenticated identity is allowed to do.<\/li>\n<li><strong>IAM User:<\/strong> Long-term identity in an AWS account with credentials (password\/access keys).<\/li>\n<li><strong>IAM Group:<\/strong> Collection of IAM users to simplify permissions management.<\/li>\n<li><strong>IAM Role:<\/strong> Assumable identity that provides temporary credentials; no long-term credentials.<\/li>\n<li><strong>Policy (IAM Policy):<\/strong> JSON document defining allowed\/denied actions on resources with optional conditions.<\/li>\n<li><strong>Managed Policy:<\/strong> Reusable policy attached to multiple identities (AWS managed or customer managed).<\/li>\n<li><strong>Inline Policy:<\/strong> Policy embedded directly into a single user\/group\/role.<\/li>\n<li><strong>Trust Policy:<\/strong> Policy on a role defining who can assume it.<\/li>\n<li><strong>STS (Security Token Service):<\/strong> AWS service that issues temporary security credentials (used by role assumption).<\/li>\n<li><strong>Temporary Credentials:<\/strong> Short-lived credentials from STS; reduce risk compared to long-lived keys.<\/li>\n<li><strong>Least Privilege:<\/strong> Security principle of granting only necessary permissions.<\/li>\n<li><strong>Explicit Deny:<\/strong> A policy statement that denies access; overrides any allows.<\/li>\n<li><strong>Resource-based Policy:<\/strong> Policy attached to a resource (for example, S3 bucket policy) controlling who can access it.<\/li>\n<li><strong>Permissions Boundary:<\/strong> A maximum-permissions guardrail for an IAM user\/role.<\/li>\n<li><strong>SCP (Service Control Policy):<\/strong> Organization-wide policy that sets maximum permissions for accounts\/OUs (AWS Organizations feature).<\/li>\n<li><strong>ABAC (Attribute-Based Access Control):<\/strong> Authorization based on attributes like tags, rather than only roles\/groups.<\/li>\n<li><strong>MFA (Multi-Factor Authentication):<\/strong> Additional factor beyond password to reduce account takeover risk.<\/li>\n<li><strong>Instance Profile:<\/strong> Container for an IAM role that EC2 instances use to obtain role credentials.<\/li>\n<li><strong>Session Name:<\/strong> Identifier for an assumed-role session, visible in logs.<\/li>\n<li><strong><code>iam:PassRole<\/code>:<\/strong> Permission required to pass a role to AWS services (critical for preventing privilege escalation).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>AWS Identity and Access Management (IAM) is AWS\u2019s foundational service in <strong>Security, identity, and compliance<\/strong> for controlling access to AWS resources. It provides identities (users, groups, roles) and a powerful policy engine for fine-grained authorization across AWS.<\/p>\n\n\n\n<p>IAM matters because it enables <strong>least privilege<\/strong>, <strong>temporary credentials<\/strong>, <strong>cross-account access<\/strong>, and <strong>audit-ready governance<\/strong>\u2014all essential for running secure production workloads. IAM itself is generally <strong>no additional charge<\/strong>, but secure operation often requires paid supporting services like CloudTrail trails, S3 log storage, and security monitoring.<\/p>\n\n\n\n<p>Use AWS Identity and Access Management (IAM) whenever you need AWS-native authorization\u2014especially for roles used by services and automation. Prefer roles and federation to reduce long-lived credential risk, and invest early in policy hygiene, logging, and access review processes.<\/p>\n\n\n\n<p>Next learning step: deepen your practical skills by combining IAM with <strong>CloudTrail auditing<\/strong>, <strong>AWS Organizations guardrails<\/strong>, and <strong>federated access (IAM Identity Center or OIDC\/SAML)<\/strong>\u2014then codify everything with Infrastructure as Code.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security, identity, and compliance<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,39],"tags":[],"class_list":["post-319","post","type-post","status-publish","format-standard","hentry","category-aws","category-security-identity-and-compliance"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/319","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=319"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/319\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=319"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=319"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=319"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}