Skip to content
7 min read·Lesson 7 of 10

AWS IAM and Security

Control access to AWS resources using IAM users, groups, roles, and policies — and understand the key security services.

Identity and Access Management (IAM) is the access control backbone of AWS. Every API call to AWS is authenticated and authorised through IAM. Getting IAM right is not optional — it's the foundation of a secure AWS environment.

IAM Core Concepts

Root Account

The root account is created when you sign up for AWS. It has unrestricted access to everything. Best practice: secure it with MFA, create administrative IAM users, and never use the root account for daily work.

IAM Users

IAM users represent human identities (or applications) that need long-term credentials. Each user has:

  • A username and password (for console access)
  • Access key ID + secret access key (for programmatic/CLI access)

Best practice: Use IAM roles (not access keys) for applications and AWS services. Rotate access keys regularly. Enable MFA for all users.

IAM Groups

Groups are collections of IAM users. Attach policies to groups, not individual users, for easier management. Example groups: Developers, ReadOnly, Admins.

IAM Roles

Roles are the preferred way to grant permissions to AWS services, applications, and cross-account access. Unlike users, roles have no permanent credentials — they issue temporary security credentials when assumed.

Common role use cases:

  • EC2 instance role — allows the instance to call AWS APIs (e.g., read from S3)
  • Lambda execution role — grants Lambda permission to log to CloudWatch, read DynamoDB, etc.
  • Cross-account role — allows an identity in Account A to access resources in Account B
  • AWS service role — grants an AWS service (ECS, CodeDeploy) permission to act on your behalf

IAM Policies

Policies are JSON documents that define permissions. They specify:

  • Effect: Allow or Deny
  • Action: Which API calls (e.g., s3:GetObject, ec2:StartInstances)
  • Resource: Which resources (ARN)
  • Condition: (Optional) When the policy applies
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Policy Types

  • AWS Managed Policies: Pre-built by AWS (e.g., AmazonS3ReadOnlyAccess)
  • Customer Managed Policies: Your own reusable policies
  • Inline Policies: Embedded directly in a user/group/role; not reusable
  • Resource-based Policies: Attached to a resource (e.g., S3 bucket policy)
  • SCPs (Service Control Policies): Applied at AWS Organization level — set maximum permissions for accounts

IAM Policy Evaluation Logic

When a request is made: explicit Deny wins over any Allow. If no policy allows the action, it is implicitly denied. The evaluation order:

  1. Deny evaluation — if any policy explicitly denies, access denied.
  2. Allow evaluation — if any policy allows, access granted.
  3. Implicit deny — if nothing explicitly allows, denied.

Key Security Services

  • AWS MFA (Multi-Factor Authentication): Adds a second factor to AWS sign-in. Always enable on root and admin accounts.
  • AWS KMS (Key Management Service): Create and manage encryption keys used by S3, EBS, RDS, Lambda, and more.
  • AWS Secrets Manager: Store, rotate, and retrieve database credentials, API keys, and other secrets programmatically.
  • AWS Systems Manager Parameter Store: Lightweight secrets and config storage, integrated with IAM.
  • AWS CloudTrail: Logs every API call made in your account — who did what, when, from where. Essential for audits and incident response.
  • AWS GuardDuty: Threat detection service that analyses CloudTrail, VPC Flow Logs, and DNS logs for malicious activity.
  • AWS IAM Access Analyzer: Identifies resources shared externally that you may not have intended.
  • AWS Shield: DDoS protection. Shield Standard (free) is automatic; Shield Advanced (paid) provides additional protection for ELB, CloudFront, Route 53.
  • AWS WAF (Web Application Firewall): Filters HTTP/HTTPS traffic based on rules to block common web attacks (SQL injection, XSS).

Security Best Practices

  • Enable MFA on root account and all IAM users immediately
  • Never share access keys; rotate them regularly
  • Grant least-privilege permissions; review with IAM Access Analyzer
  • Use IAM roles for applications — never embed access keys in code
  • Enable CloudTrail in all regions
  • Enable GuardDuty for continuous threat detection
  • Use AWS Organizations with SCPs to enforce guardrails across accounts

Next: monitoring and management tools — CloudWatch, CloudTrail, Config, and Trusted Advisor.

Key Takeaways

  • IAM controls authentication (who you are) and authorisation (what you can do) in AWS.
  • Use IAM roles instead of long-lived access keys for applications and AWS services.
  • Follow the principle of least privilege: grant only the permissions actually needed.
  • Enable MFA on the root account and all admin users immediately.
  • AWS Organizations, SCPs, and AWS SSO manage security at scale across multiple accounts.

Test your knowledge

Try exam-style practice questions to reinforce what you've learned.

Practice Questions →