🚨 I Used My Access Keys to Connect to EC2 — Here's Why That Was a Bad Idea

When I first started exploring AWS, I faced a situation where I needed to connect to an EC2 instance using EC2 Instance Connect. In my confusion, I ended up doing something that seemed to work at the time but turned out to be a big security risk:

I used my AWS Access Key ID and Secret Access Key to connect.
Sounds harmless, right? But here's why it wasn’t.

😬 The Mistake: Sharing Permanent Credentials

I was working on a shared AWS account with a few teammates. To make things easier, I used my personal AWS credentials (Access Key ID and Secret Key) while testing EC2 Connect access.

What I didn’t realize was:

• These keys give full or scoped programmatic access to my AWS account.

• Anyone else with access to the EC2 instance could potentially see or misuse those credentials.

• There’s no built-in timeout like with session-based roles — once the keys are out, they’re out.

🔐 The Better Way: Use IAM Roles with Controlled Policies

Instead of embedding or entering access keys, AWS provides a more secure, scalable method — IAM Roles attached to the EC2 instance.

✅ I fixed the issue by attaching the IAMReadOnlyAccess policy through an instance profile.

This way:

• My EC2 instance can safely read IAM credentials or AWS resources without storing any keys.

• The access is temporary and scoped by the role.

• It’s secure, auditable, and avoids credential leakage.

🛠️ How I Fixed It

1. Went to IAM > Roles, created a new role with:

   • Use case: EC2

   • Policy: IAMReadOnlyAccess

2. Attached this role to my EC2 instance:

   • Go to EC2 > Instances > Actions > Security > Modify IAM role

   • Select the newly created role.

3. Restarted the instance to let it assume the new role.

Now, the instance has all the access it needs — without exposing my personal credentials.

🚫 Why Never Share Access Keys (Even With Teammates)

• They don’t expire unless manually revoked.

• You can’t limit them by time like roles.

• They can be stored, leaked, or even pushed accidentally to GitHub (happens way too often).

• They can be misused to spin up expensive resources or delete important ones.

✅ Key Takeaways

• Never use personal Access Keys on EC2 instances, especially in shared environments.

• Use IAM Roles and attach only necessary policies to your EC2 instances.

• For most read-only purposes, IAMReadOnlyAccess is perfect.

• If you ever suspect your keys were exposed, immediately rotate or delete them.

💡 Final Thoughts

Security in the cloud isn’t just about firewalls and encryption — it's also about knowing when to use what. I learned that the hard way when I risked exposing my AWS credentials just to make a connection work.

Thankfully, AWS gives us tools like IAM Roles to avoid these mistakes — we just need to use them wisely.