AWS Cloud Security Foundation
Exploring AWS IAM fundamentals, authentication, authorization, roles, policies, MFA, identity federation, and how hands-on practice helped me understand secure access management in AWS.
In the cloud, giving someone access isn't the same as giving them the right access.
This week, I went deeper into AWS Identity and Access Management (IAM) and learned how AWS controls access to resources through authentication and authorization.
Now, I’m understanding that cloud security starts with a simple but important question:
Who should have access to what, and what should they be allowed to do?
IAM Fundamentals
AWS IAM helps securely manage access to AWS resources for individuals, applications, and services. Here are some of the key concepts of IAM:
- Authentication and authorization
- Granular permissions
- Multi-factor authentication (MFA)
- Integration with other AWS services
- Federated identity management
- Identity information for assurance
There are four IAM identities, which includes;
User: An identity representing a person or application that can authenticate to an AWS account.
Group: A collection of IAM users that can share common permissions.
Role: An identity that provides temporary permissions that can be assumed by a person, application, or AWS service.
Policy: A document that defines what actions can be performed on which resources.
One best practice is to attach policies to groups and assign users to those groups, rather than managing permissions individually for every user.
For example, I learned how a role can be used to allow developers in one account to access resources in another account without giving them permanent credentials.
Scenario:
- the admin create a role that grant the development account read/write access to the production app bucket
- the admin grants permission to the members of the developers group to assume the updateApp role
- a user requests access to the role
- asw sts returns the role credentials
- the user update the bucket by using the role credentials
IAM Roles Characteristics
- A role isn't uniquely associated with one person.
- People, applications, and AWS services can assume roles.
- Roles are commonly used to delegate access.
- They can be useful for applications running on EC2 and for cross-account access.
The basic flow was:
User → Requests role → AWS STS provides temporary credentials → User accesses the resource using those credentials
This helped me understand why temporary credentials are an important part of secure AWS access management.
I also learned about the three common authentication factors:
- Something you know — such as a password
- Something you have — such as a security key or authenticator device
- Something you are — such as a biometric characteristic
MFA adds another layer of protection by requiring more than one factor to authenticate.
Another important part of the session was understanding the different types of IAM policies.
Identity-based policies answer: What can this identity access?
Resource-based policies answer: Who can access this resource?
I also learned the difference between: managed policies and inline polices
Managed policies: Standalone policies that can be attached to multiple users, groups, or roles.
Inline policies: Policies embedded directly into a single user, group, or role, creating a one-to-one relationship.
Understanding these differences helped me see how permissions can be structured and managed in different ways.
Identity Federation
I was also introduced to identity federation — a system of trust that allows users to authenticate through an external identity provider and receive the information needed to access AWS resources.
We also explored AWS IAM Identity Center and AWS Directory Service as part of understanding how identities can be managed across environments.
After the learning session, we had a practical lab that allowed me to apply the IAM concepts I had learned.
The lab helped me better understand how users, groups, roles, policies, authentication, authorization, and temporary credentials work together in a real AWS environment.
This practical session was especially useful because the concepts became much easier to understand once I could see them in action.
My Key Takeaway
My biggest takeaway from this week is that IAM is about designing controlled, appropriate, and temporary access to cloud resources while ensuring that identities only have the permissions they actually need.
This connects directly to one of the security principles I learned in Week 1: Least privilege.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article