How to use Amazon AWS with Juju

This guide shows you how to manage workloads on Amazon AWS.


Add cloud

Juju already has knowledge of the AWS cloud, which means you don’t need to add it explicitly. You should be able to see it already when you run:

juju clouds --all

Add credentials

There are multiple methods for adding security credentials to Juju. Each process will require two fields from the CSV file that you downloaded from the AWS user account (Hyphens indicate that the field is unnecessary).


Alternately, you can use your credentials with Juju as a Service, where charms can be deployed within a graphical environment that comes equipped with a ready-made controller.

Use the interactive method

Credentials can be added with the juju add-credential command:

juju add-credential aws

An example session:

Enter credential name: jlaurin

Using auth-type "access-key".

Enter access-key: AKIAIFII5EH5FOCYZJMA

Enter secret-key: ******************************

Credential "jlaurin" added locally for cloud "aws".

Use a YAML file

A YAML-formatted file, say mycreds.yaml, can be used to store credential information for any cloud. This information is then added to Juju by pointing the add-credential command to the file:

juju add-credential aws -f mycreds.yaml

See How to add a credential > Use a YAML file for guidance on what such a file looks like.

Use environment variables

With AWS you have the option of adding credentials using the following environment variables that may already be present (and set) on your client system:


Add this credential information to Juju in this way:

juju autoload-credentials

For any found credentials you will be asked which ones to use and what name to store them under.

On Linux systems, files $HOME/.aws/credentials and $HOME/.aws/config may be used to define these variables and are parsed by the above command as part of the scanning process.

For background information on this method read section Adding credentials from environment variables.

Create a controller

You are now ready to create a Juju controller for cloud ‘aws’:

juju bootstrap aws aws-controller

Above, the name given to the new controller is ‘aws-controller’. AWS will provision an instance to run the controller on.

For a detailed explanation and examples of the bootstrap command see the Creating a controller page.

AWS-specific features

Awareness of regions and instance types

Juju contains built-in knowledge of AWS regions, instance types and their capabilities.

juju show-cloud --local aws

Replacing the --local option with --controller to report regions known to a controller.

Use juju update-public-clouds to update Juju’s knowledge of new AWS regions as they are available.

Custom tags

Consistent naming, tagging, and the ability to add user-controlled tags to created instances. See Instance naming and tagging for more information.

Instance type selection

Juju’s default AWS instance type is m3.medium. A different type can be selected via a constraint: juju add-machine --constraints 'instance-type=t2.medium'. For more information see Constraints. You can also view the list of Amazon EC2 instance types.

Support for Virtual Private Cloud (VPC) functionality

A controller can be placed in a specific virtual private cloud (VPC). See Passing a cloud-specific setting for instructions.

Important note for AWS accounts created before 2013-12-04: These accounts do not have a default VPC. Juju may select a much larger instance type than what is required. To remedy this, create a default VPC for your AWS account.

Next steps

A controller is created with two models - the ‘controller’ model, which should be reserved for Juju’s internal operations, and a model named ‘default’, which can be used for deploying user workloads.

See these pages for ideas on what to do next:

What is the least privileged policy that would still give Juju the permissions it needs to perform all of its functions? I want to create an IAM account for Juju to use, and I don’t want to give it AdministratorAccess.

At this stage, I’m afraid that we don’t have a definitive answer for this. AdministratorAccess is far too broad, you’re correct.

One issue to reckon with is the juju trust model. We don’t know in advance what charms will want to do with the provider’s API.

Update: AmazonEC2FullAccess is sufficient for deploying Charmed Kubernetes, so I’ve updated the text to indicate that it’s the recommended policy.

any guidance on how to use Juju in conjunction with aws reserved instances?

We’ve setup and run in a VPC , used spaces… this is the final question about Juju we’ve had though … if we’re going to use it in AWS to manage a webapp


Edit: seems after reading some similar questions around other tools… I merely need to call out for a certain instance type… and if none is taken yet… whatever instance I create with Juju will count towards my quota… is this correct ? I don’t do anything in juju other than constraint on instance type?

As long as your VPC is set up to provision instances and you provide the correct credentials to Juju then Juju will spawn those instances upon request. I don’t think you need to specify any special constraint.

1 Like

Not sure if something has changed, but I don’t think AmazonEC2FullAccess is sufficient. I just tried to install without any changes to the bundle, etc, and cannot get a charmed kubernetes deployed without a permission error for CreateRole. AdministratorAccess of course still works

on non-k8s I’ve only used AmazonEC2FullAccess… would be curious what more is needed for the k8s charms