Objective:
This section looks into IAM and security fundamentals in AWS. We cover the role of IAM in controlling user access to AWS resources and monitoring AWS activity with services including CloudWatch and CloudTrail.
IAM: Identity & Access Management 👤
IAM is AWS’s security layer for managing who can access what in our cloud account, and how they can do it. It fundamentally looks at Authentication (who are you?) and Authorisation (what can you do?).
Principals
(1) Root User
When we first create an AWS account, we get a Root User - the account owner with full access to everything. This account should only be used for tasks including: setting up billing, emergency access, or creating initial IAM users or Identity Center setup.
(2) IAM Users
IAM Users are identities with permanent credentials (username/password or access keys) that can be grouped into IAM Groups for permission inheritance. We commonly use it for programmatic access (e.g., an application needing AWS SDK credentials).
💡 IAM Identity Center (formerly AWS SSO) is the preferred way to create and manage human access across multiple accounts using federated login.
(3) IAM Roles
IAM Roles provide temporary credentials and are assumed by users or services that need specific, time-limited access.
Roles are used for:
- AWS Services (e.g. EC2 instance accessing S3)
- Cross-account access
- Temporary user access (e.g., external contractors or federated identities)
IAM: Authentication 👤
If we have an IAM user account, there are three primary ways to connect and interact with AWS services and resources:
IAM: Authorisation 👤
Once a principal (user, role, etc.) has been authenticated, we control what they can do using policies and permission boundaries. These define what AWS actions and resources the principal can access.
Here are the main types of authorisation mechanisms:
- Inline Policies
They are attached directly to a specific user, group, or role, and are best used for one-off or tightly scoped permissions.
- Resource-Based Policies
They are attached to AWS resources like S3 buckets, SNS topics, or Lambda functions to define which principals can access the resource and what actions they can take.
- Managed Policies (AWS or Customer-Managed)
Reusable policies created and maintained either by us or AWS. They make it easier to apply policies consistently across multiple users or roles.
- Permissions Boundaries
They set the maximum permissions a user or role can have, even if other policy types grant more.
- Service Control Policies (SCPs)
They only apply within AWS Organisations. SCPs define the maximum allowed permissions across all accounts in an organisation or organisational unit (OU)
Image sourced from: https://www.tecracer.com/blog/2022/03/using-permission-boundaries-to-balance-security-and-developer-productivity.html
CloudWatch (Monitoring) 🔎
Many AWS services automatically send metrics to CloudWatch at regular intervals (typically every 1 or 5 minutes, depending on the service and plan).
It's essentially a system that tracks, collects, and responds to resource performance and operational data.
-
CloudWatch Metrics→ Performance numbers that appear on a dashboard (CPU usage, storage space, request count, etc.) -
CloudWatch Logs→ Detailed text records that document every message from a resource, e.g. timestamp, log group, etc -
CloudWatch Alarms→ Notifications when thresholds are breached (email me when CPU > 80%) -
CloudWatch Events(EventBridge) → Automating responses (e.g. restarting a server when an alarm triggers)
Each resource type typically sends its own specific set of metrics, for example:
- EC2 specifically sends CPU utilisation, network traffic
- S3 sends request counts, storage usage
- Custom applications will send their own metrics manually via a CLI or SDK (for apps or on-prem monitoring).
Metric Structure Example:
- Metric Name → CPUUtilisation
- Namespaces → Categories (like "AWS/EC2", "AWS/S3")
- Dimensions (Key-Value) → Specific resource identifiers (InstanceId=i-1234567, BucketName=my-bucket)
- Metric Value → 50%
- Timestamp → 2024-11-01
CloudTrail (Auditing) 🔎
CloudTrail captures all control plane API activity (e.g., resource creation, deletion, etc.). It records what action was taken, by whom, when, on what resource, from what IP, and using what method (Console, CLI, SDK).
It can also be configured to capture data events, such as S3 GetObject, PutObject (but this is not enabled by default).
💡 Multi-region logging is enabled by default in CloudTrail, but we can customise its regional scope in the console. The actual audit logs are collected and stored in an S3 bucket (optionally forwarded to CloudWatch Logs)!
🎯 TL;DR
- IAM controls who can do what.
- CloudWatch monitors how resources are performing.
- CloudTrail audits what actions were actually taken.
✨ This is part of a mini-series where I delve into everything cloud-related. Check out my other posts for further learning! ✨