DEV Community

Haripriya Veluchamy
Haripriya Veluchamy

Posted on

Understanding AWS IAM: My Learning Journey as a Cloud Engineer πŸš€

As I've been working with AWS for the past year, one of the most important services I've come to understand is IAM (Identity and Access Management). While it seemed complicated at first, I want to share what I've learned about IAM and why it's crucial for anyone working with AWS. πŸ”

What Made Me Take IAM Seriously ⚑

When I first started with AWS, I used to just click "full access" for permissions because I was more focused on getting things working. But after accidentally giving a test application too many permissions and seeing it rack up costs, I realized I needed to understand IAM properly. πŸ’Έ

The Basics of IAM That Actually Matter πŸ“

From what I've learned, IAM is basically about controlling who can access what in your AWS account. There are four main things you need to know about:

  1. Users πŸ‘₯: These are the people or applications that need to access your AWS account. I create separate users for each person on my team instead of sharing credentials (learned this the hard way).

  2. Groups πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦: This is how I organize users. For example, I have a "Developers" group where I put all the developers, and they automatically get the permissions they need. It's much easier than managing permissions for each user separately.

  3. Roles 🎭: I use these when I need to give permissions to AWS services. For example, when I need my EC2 instance to access files in S3, I use a role instead of putting access keys in the code.

  4. Policies πŸ“œ: These are the actual permissions. They're written in JSON, which looks intimidating at first, but once you understand the basic structure, it's not too bad.

Some Simple Examples That Helped Me πŸ’‘

Here's a basic policy I use for developers who need to work with S3:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::my-project-bucket/dev/*"
        }
    ]
}
Enter fullscreen mode Exit fullscreen mode

This policy only lets them access files in the 'dev' folder of our bucket. It took me some time to understand, but breaking it down:

  • "Effect": "Allow" means we're giving permission βœ…
  • The "Action" list shows what they can do 🎯
  • "Resource" specifies where they can do it πŸŽͺ

Important Security Step I Follow πŸ”’

These are the basic security practice I've implemented:

  1. Access Keys: I make sure to create and using access keys. πŸ”‘

Common Problems I've Run Into ⚠️

  1. Access Denied Errors: Usually happens when I forget to add a necessary permission to a policy. I check logs to see what permission is missing. ❌
  2. Policy Size: Sometimes my policies get too big and hit the size limit. I learned to combine similar permissions to keep policies smaller. πŸ“
  3. Role Trust Relationships: It took me a while to understand that roles need both a policy and a trust relationship to work properly. 🀝
  4. Custom creation: Based on the requirement i will create custom role and policies βš™οΈ

What I'm Still Learning πŸ“š

IAM is pretty deep, and I'm still learning about:

  • Permission boundaries πŸ”
  • AWS Organizations 🏒
  • Service control policies πŸ“‹

Tips for Others Learning IAM πŸ’‘

  1. Start with minimal permissions and add more as needed 🎯
  2. Use the visual policy editor in the AWS console when learning πŸ–₯️
  3. Always test permissions in a non-production environment first βœ…

Conclusion 🎯

IAM isn't the most exciting part of AWS, but it's essential for keeping your resources secure. I hope sharing my experience helps others who are learning about AWS security. Feel free to share your own experiences or ask questions in the comments. 🀝


Written by an AWS learner documenting her cloud journey. Still learning, still making mistakes, but getting better every day. 🌱

Top comments (0)