How to Setup AWS Credentials for Coding in 3 Easy Steps

Let’s assume you’re starting a new app with mobile and web clients talking to an API that’s deployed in Amazon Web Services. For the purposes of this guide, it’ll be an inventory of space cat images.

so how do I setup my AWS credentials?

Step 1: Obtaining AWS Credentials

For interacting with the AWS Management Console, you’ll use an IAM user (or role) with associated credentials. However for most software development (e.g. via the command line or via code), you’ll be using your AWS API Credentials.

Access Key location in AWS Management Console

Step 2: Store your AWS API Credentials

Choice A: Directly in your code

This is the gimme “obviously wrong” test answer. This is extremely common when you’re starting out but a terrible idea. Please use any of the other choices as much better options.

Choice B: Use AWS CLI + ~/.aws/credentials file

Most examples you find online will use the AWS Command Line Interface (CLI) to interact and configure the various AWS resources you’ll use in your project. See AWS Configuration and Credential Files documentation.

Choice C: Use environment variables

You can directly configure AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables (see AWS Environment Variables docs) .

Choice D: Assume a role to obtain temporary credentials

Basically the same option as using environment variables, with an added session token that will time out after a while. See Using Temporary Security Credentials with the AWS CLI documentation.

My Answer is C. Why?

  • I’ve gone with the “stick everything in the credentials file” route and ended up with juggling too many profiles. It gets annoying to have the AWS_ACCESS_KEY_ID and the AWS_SECRET_ACCESS_KEY right and then forget to specifiy the correct profile on the CLI.
  • I like using direnv so I don’t have to remember the above.

Step 3: Set your environment variables per project

I highly recommend using direnv! direnv will setup environment variables for you based on your current working directory (or its parent). For example, if we put

and then put our AWS_ACCESS_KEY_ID and ACCESS_SECRET_KEY in that .envrc file, after we run ‘direnv allow’, we’ll have access to those environment variables in space_cat_inventory and any of its subdirectories.

The way this example is setup, I don’t have ~/code/space_cat_inventory checked into git (just the subdirectories).

Step 4: Don’t check this into git

Given the information stored in your .envrc, you really don’t want to expose this by checking it into git.

Reference: How does the AWS CLI look for credentials?

The AWS CLI looks for credentials and configuration settings in the following order:
Command Line Options — region, output format and profile can be specified as command options to override default settings.
Environment Variables — AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, etc.
The AWS credentials file — located at ~/.aws/credentials on Linux, macOS, or Unix, or at C:\Users\USERNAME \.aws\credentials on Windows. This file can contain multiple named profiles in addition to a default profile.
The CLI configuration file — typically located at ~/.aws/config on Linux, macOS, or Unix, or at C:\Users\USERNAME \.aws\config on Windows. This file can contain a default profile, named profiles, and CLI specific configuration parameters for each.
Instance profile credentials — these credentials can be used on EC2 instances with an assigned instance role, and are delivered through the Amazon EC2 metadata service.

Photo Credits

Show your support

Clapping shows how much you appreciated Frank Blecha’s story.