Terraform CLI AWS Authentication


Terraform Introduction
Terraform CLI
Terraform Language
Wrap Up
Start course
1h 41m

Terraform is an open source "Infrastructure as Code" tool, used by DevOps and SysOps engineers to codify their cloud infrastructure requirements.

In this course you'll learn about Terraform from the ground up, and how it can be used to codify infrastructure. Terraform can be used to provision infrastructure across multiple cloud providers including AWS which this course will focus on.

resource "aws_instance" " cloudacademy " {
ami =
instance_type = var.instance_type
key_name = var.key_name 
subnet_id =
security_groups = []
user_data =<<EOFF
read -r -d '' META <<- EOF
CloudAcademy ♥ Terraform!
For any feedback, queries, or suggestions relating to this course
please contact us at:
echo "$META"

tags = {
Org = "CloudAcademy"
Course = "Terraform 1.0"
Author = "Jeremy Cook"

Learning Objectives

  • Learn about Terraform and how to use it to provision AWS infrastructure
  • Learn how to build and create Terraform configurations and modules
    Learn how to use the Terraform CLI to launch and manage infrastructure on AWS

Intended Audience

  • Anyone interested in learning about Terraform, and the benefits of using it to codify infrastructure
  • Anyone interested in building and launching AWS infrastructure using Terraform
  • Anyone interested in deploying cloud native applications on AWS


Prerequisites which would be considered useful for this course are:

  • Knowledge of the AWS cloud platform and the various services within it – particularly VPC, EC2, and IAM
  • Basic System administration experience
  • Basic Infrastructure and Networking Knowledge
  • Basic SysOps and/or DevOps Knowledge


All Terraform configuration as used within the provided demonstrations is located in GitHub here:


Welcome back. In this lesson, I'll review the credential configuration options that you can use to allow Terraform to correctly and successfully authenticate into your own AWS accounts. If your authentication set up is broke, Terraform is not going to be able to authenticate, and this will mean no infrastructure gets provisioned. So, understanding how to do this successfully is essential to moving on. Let's begin.

There are basically three different approaches to configuring your AWS account credentials to allow Terraform to connect and authenticate successfully. The first approach is to wire the credentials directly into the Terraform template file. In the example given here, the AWS provider is configured with both an access key and a secret key.

Now, although this approach is probably the quickest and easiest approach, it should be done so with care since it is considered bad practise or, at least, not good practice if you were to version control this file containing the credentials. The last thing you want is AWS account credentials floating around in your version control system, particularly ones that can perform infrastructure changes.

As you will see in the following two slides there are better alternatives that allow you to extract out the credentials and store them elsewhere. Pausing briefly here, regardless of the AWS credential management approach you end up using, within the AWS account you should create a dedicated IM user with programmatic access enabled.

For this user account, make sure to grant at least privileged based permissions, as this limits the potential blast radius that Terraform will have within the AWS account. Granting the Terraform AWS IM user full admin access within the AWS account might be convenient at first but it will likely be overkill, not to mention dangerous as Terraform effectively has granted permissions to do any and everything within the AWS account.

If, for example, you need it to only build a VPC, Subnets, Route Tables, and deploy EC2 instances of, say, a particular instance type, then create a custom IM policy and assign it to the IM Terraform user that allows just that and nothing else. The second approach is to leverage environment variables. The Terraform CLI Executable is designed to scan for and detect the presence of these environment variables. If detected, they will be used.

Clearly, this approach is better from the perspective of version control. With this approach, the file, as previously configured, could now safely be committed into version control, since, the AWS credentials have been extracted out and away from it. The third approach is to store them, as you may have already done so if you're a user of the AWS CLI, on the local file system, in a credentials file.

The AWS Terraform provider, for example, can be configured via the shared credentials file attribute having it pointed at an existing credentials file, such as the one used in this example. For those who may be unfamiliar with the AWS CLI, the file path used within this example is actually a pointer to the same creds file as used by the AWS CLI. Note; the AWS CLI is not a prerequisite for the Terraform CLI. Regardless, the Terraform CLI can be configured, as seen here, to reuse and share the same creds file created and managed and used by the AWS CLI.

Note; if all three types of credentials are used, then the 3.X version of the AWS provider preferences static credentials first followed by environment variables and then, lastly, shared credentials. The same order is just given in the three explanations. The next example is really just a derivative of the previous example. Here, when we use and set the profile, together with the absence of the shared credentials file attribute, implies that the files will be sourced from the current users home/.aws/credentials file. Again, the same one that is used and managed by the AWS CLI.

About the Author
Learning Paths

Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.

Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).