Stop Hardcoding AWS Credentials: How to Manage Secrets Securely

It is a cloud engineer's worst nightmare.

You finish a long coding session, type git push origin main, and go to sleep. You wake up the next morning to hundreds of automated emails from AWS and a billing dashboard showing a $5,000 charge.

What happened? You accidentally pushed your AWS Access Key and Secret Key to a public GitHub repository. Within seconds, automated bots scraped your keys and spun up dozens of expensive EC2 instances across the globe to mine cryptocurrency.

Today, we are going to make sure this never happens to you. Here is how to stop hardcoding your AWS credentials and manage your secrets securely.

The Bad Way: Hardcoding in Your App

When you are just learning how to use the AWS SDK (like boto3 for Python or the AWS SDK for Node.js), it is incredibly tempting to just paste your keys directly into your code so it works:

// ❌ NEVER DO THIS!
const AWS = require('aws-sdk');

const s3 = new AWS.S3({
    accessKeyId: "AKIAIOSFODNN7EXAMPLE",
    secretAccessKey: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
});

If this code gets pushed to GitHub, your AWS account is completely compromised. We need to separate our code from our configuration.

The Good Way (Local Development): AWS CLI Profiles

Instead of putting credentials in your code, you should store them securely on your local machine using the AWS Command Line Interface (CLI).

If you have the AWS CLI installed, open your terminal and run:

aws configure

It will prompt you to enter your Access Key, Secret Key, default region (e.g., us-east-1), and output format.

Once you do this, AWS creates a hidden file on your machine. If you are developing on a Linux system (like Fedora) or macOS, this file lives at ~/.aws/credentials. On Windows, it is at C:\Users\YOUR_USERNAME\.aws\credentials.

Now, when you run your code, the AWS SDK will automatically look for this hidden file and use the credentials inside it. Your code becomes completely clean:

// ✅ THE SAFE WAY
const AWS = require('aws-sdk');

// The SDK automatically pulls from your ~/.aws/credentials file!
const s3 = new AWS.S3(); 

The Good Way (Pipelines & CI/CD): Environment Variables

If you are running your code inside a Docker container or a GitHub Actions pipeline, you can't manually run aws configure. Instead, you use Environment Variables.

AWS SDKs are programmed to automatically look for these specific variables:

• AWS_ACCESS_KEY_ID

• AWS_SECRET_ACCESS_KEY

• AWS_DEFAULT_REGION

If you are working locally with a .env file, it should look like this:

AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
AWS_DEFAULT_REGION=us-east-1

Crucial Step: You must add .env to your .gitignore file. If you track your .env file in Git, you are right back to the nightmare scenario we talked about at the beginning!

The Ultimate Fix (Production): AWS Secrets Manager

The methods above are perfect for personal projects, local development, and simple CI/CD pipelines.

However, when you are dealing with production microservices at scale, managing dozens of .env files becomes a massive security liability. In a true production environment, the best practice is to migrate credential management to AWS Secrets Manager.

By using Secrets Manager, you eliminate hardcoded secrets entirely, automate key rotation, and establish SOC2-aligned auditability so you know exactly which microservice accessed which secret and when.

The Takeaway

Security in the cloud isn't just an afterthought; it is step zero. By utilizing aws configure locally and environment variables in your pipelines, you can push your code to GitHub with complete peace of mind.

(If you are using these secured credentials to write infrastructure code, be sure to bookmark my Ultimate Terraform Cheatsheet to speed up your workflow!)

---

If this security tip helped you out today, you can ☕ buy me a coffee here to support my work!