Building IAM Policies and Securing AWS Resources: My Cloud Security Project

As part of my cloud security engineering journey, I completed an AWS project from the AWS Beginners Challenge (Day #3) series. This project focused on Identity and Access Management (IAM), EC2 instance security, and policy simulation. The goal was to create least-privilege IAM users, apply custom policies, and validate access restrictions with real-world scenarios.

Phase 1: Launching EC2 Instances

Phase 2: Creating a User Group

To manage permissions centrally, I created a dedicated IAM user group. This allowed me to assign policies once to the group and then add users to it, rather than managing individual permissions repeatedly.

Phase 3: Creating IAM Policies

I then wrote a custom JSON policy with three main rules: Allow EC2 actions, but only on resources tagged with development. Allow Describe* actions across all resources for visibility. Deny the ability to create or delete tags, preventing privilege escalation.

Phase 4: Creating an IAM User

Next, I created an IAM user called geminel-dev-nat and added them to the user group. This ensured the custom policies would apply to the user. The user was granted console access with an autogenerated password.

Phase 5: Creating an Account Alias

To make sign-in easier, I set up a custom account alias (geminel) so I could log in using a human-readable URL instead of the numeric AWS account ID.

Phase 6: Testing Access with EC2 Instances

After logging in as the IAM user, I attempted to stop both instances. The policy correctly denied access to the production instance, while allowing the stop action on the development instance.

Phase 7: Testing General Access Restrictions

Outside of EC2, the IAM user encountered Access Denied errors when trying to view restricted services. This confirmed that least privilege was enforced consistently across the account.

Phase 8: Validating with IAM Policy Simulator

Finally, I validated my custom policy using the IAM Policy Simulator. The results confirmed that EC2 actions were allowed only on development resources, while actions like tag deletion remained denied.

Conclusion & Lessons Learned

This project gave me hands-on experience with IAM policies, user groups, EC2 security testing, and policy simulation. Key takeaways include:

• Start with real resources (like EC2 instances) so you can validate IAM policies against them

• User Groups simplify policy management for multiple users

• Tag based access control is powerful for environment separation

• Always use the Policy Simulator before deploying policies in production

• Follow the principle of Least Privilege to protect against misconfigurations and mistakes.

This was a significant step in my journey toward becoming a Cloud Security Engineer.