Why NOT to use aws configure command inside ec2 instances

I recently learned something important while working with AWS CLI on an EC2 instance, and I think it’s worth sharing—especially if you're starting out in DevOps or cloud engineering. Many of us are used to configuring the AWS CLI using the aws configure command. This works fine on local machines, but it's considered a bad practice inside an EC2 instance. Why? Because aws configure stores your access keys in plain text under ~/.aws/credentials. These credentials are long-term and can be exposed if someone gains shell access, creates an AMI, or accidentally leaks them. Instead, the right approach is to use IAM roles. When you attach an IAM role to an EC2 instance, it gets temporary, automatically rotated credentials through the instance metadata service. These credentials are used seamlessly by the AWS CLI and SDKs without any manual setup. This not only improves security but also reduces the headache of managing and rotating secrets. So if you're running automation, scripts, or apps inside EC2 and need to interact with AWS services like S3, DynamoDB, or CloudWatch—just attach a properly scoped IAM role to the instance. It's cleaner, safer, and aligns with AWS best practices.