AWS Builder Center

Builder Center

Stop Hardcoding AWS Access Keys: A Better Approach with IAM Roles

Topics: AWS IAM | Cloud Security | DevOps | AWS Best Practices

Rahul N R

Introduction

One of the most important lessons in cloud security is simple: Never hardcode AWS access keys in your application.
When applications need to access AWS services like Amazon S3, DynamoDB, or CloudWatch, developers sometimes configure IAM access keys directly in their code or environment files.
Although this approach might work, it introduces unnecessary security risks.
Fortunately, AWS provides a better alternative: IAM Roles and Temporary Security Credentials.
Let's understand how they work and why they should be part of every cloud engineer's toolkit.

1. The Problem with Long-Term Access Keys

Imagine deploying a Python application on an EC2 instance that needs to read files from an S3 bucket.
A developer might configure credentials like this:
1
2
3
4
5
6
7
import boto3

s3 = boto3.client(
"s3",
aws_access_key_id="YOUR_ACCESS_KEY",
aws_secret_access_key="YOUR_SECRET_KEY"
)
This approach has several disadvantages:
  • Credentials can accidentally get committed to GitHub.
  • Exposed keys may be exploited by unauthorized users.
  • Long-term keys require additional management and rotation.
  • Managing credentials across multiple environments becomes difficult.
Even when credentials are stored in environment variables, they still need to be securely distributed and managed.

2. The Solution: IAM Roles

An IAM role is an AWS identity with permissions that trusted entities can assume.
Instead of storing permanent credentials, applications can obtain temporary credentials through AWS Security Token Service (STS).
For example:
EC2 Instance → IAM Role → Temporary Credentials → Amazon S3
AWS automatically provides temporary credentials to applications running on EC2 instances with an attached IAM role.
Applications using supported AWS SDK credential providers can retrieve these credentials without developers manually configuring access keys.

3. A Practical Example Using Python

Once an IAM role with the appropriate S3 permissions is attached to an EC2 instance, the application can use:
1
2
3
4
5
6
7
8
9
10
import boto3

s3 = boto3.client("s3")

response = s3.list_objects_v2(
Bucket="my-example-bucket"
)

for obj in response.get("Contents", []):
print(obj["Key"])
Notice something important?
No AWS access keys are included in the code.
Boto3's credential provider chain can automatically discover the temporary credentials associated with the EC2 instance role.
The IAM role still needs permission to list objects in the specified bucket.

4. Where Else Can We Use IAM Roles?

IAM roles aren't limited to EC2.
They are useful across several AWS and DevOps scenarios:
  • AWS Lambda: Execution roles provide permissions for Lambda functions.
  • Amazon ECS: Task roles enable containers to access AWS services.
  • Amazon EKS: Pod-level IAM integrations allow workloads to obtain AWS credentials.
  • GitHub Actions: OpenID Connect (OIDC) federation can enable deployments to AWS without storing permanent AWS access keys as GitHub secrets.
  • Cross-account access: IAM roles can securely delegate access between different AWS accounts.

5. Security Best Practices

IAM roles are powerful, but proper configuration is equally important.
Follow these recommendations:
  1. Apply the principle of least privilege.
  2. Avoid granting wildcard permissions such as s3:* unless genuinely required.
  3. Review IAM role trust policies regularly.
  4. Use temporary credentials wherever possible.
  5. Enable MFA for human access and use IAM Identity Center where appropriate.
  6. Use IAM Access Analyzer to help identify excessive permissions.

Conclusion

Cloud security is not just about protecting infrastructure from external threats. It is also about designing applications that minimize unnecessary exposure.
By replacing long-term access keys with IAM roles, developers can improve security, simplify credential management, and make applications easier to operate across AWS environments.
My key takeaway: If an application runs on AWS, check whether an IAM role can provide the access it needs before creating long-term access keys.
What approach do you currently use to manage AWS credentials in your projects?

References

Tags: #AWS #IAM #CloudSecurity #DevOps #CloudComputing #AWSSecurity #Python
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article