The Amazon EC2 cloud and Juju

doc
1

List of supported clouds > Amazon EC2

This document describes details specific to using your existing Amazon EC2 cloud with Juju.

See more: Amazon EC2

When using the Amazon EC2 cloud with Juju, it is important to keep in mind that it is a (1) machine cloud and (2) not some other cloud.

See more: Cloud differences in Juju

As the differences related to (1) are already documented generically in our Tutorial, How-to guides, and Reference docs, here we record just those that follow from (2).

Juju points of variation Notes for the Amazon EC2 cloud
setup (chronological order):
CLOUD
requirements: TBA
definition: :information_source: Juju automatically defines a cloud of this type.
- name: aws or user-defined
- type: ec2
- authentication types: [access-key, secret-key]
- regions: [TO BE ADDED]
- cloud-specific model configuration keys: vpc-id (string)
Sets a specific AWS VPC ID. Optional. When not specified, Juju requires a default VPC or EC2-Classic features to be available for the account/region. :warning: If your AWS account was created before 04-12-2013: Your account does not have a default VPC. As a result, Juju may select a much larger instance type than what is required. To remedy this, create a default VPC.

vpc-id-force (boolean)
Forces Juju to use the AWS VPC ID specified with vpc-id, when it fails the minimum validation criteria. :warning: Not accepted without vpc-id.
CREDENTIAL
definition: auth-type: access-key, which requires you to provide your access key and your secret key. See more: Amazon | AWS security credentials

If you want to use a YAML file:

credentials:
 aws:
  <user-defined credential name>:
   auth-type: access-key
   access-key: <key>
   secret-key: <key>

If you want to use environment variables:

AWS_ACCESS_KEY_ID="<id>"

AWS_SECRET_KEY_ID="<id>"
CONTROLLER
notes on bootstrap: You can authenticate the controller with the cloud using instance profiles: Use the cloud CLI to create an instance profile, then pass the instance profile to the controller during bootstrap via the instance-role constraint: juju bootstrap --bootstrap-constraints="instance-role=<my instance profile>". See more: instance-role below or Discourse | Using AWS instance profiles with Juju.
other (alphabetical order:)
CONSTRAINT
conflicting: [instance-type] vs. [cores, cpu-power, mem]
supported?
- allocate-public-ip :white_check_mark:
- arch :white_check_mark:
- container :white_check_mark:
- cores :white_check_mark:
- cpu-power :white_check_mark:
- image-id :white_check_mark: (Starting with Juju 3.3)
Type: String.
Valid values: An AMI.
- instance-role :white_check_mark:
Value: auto or an instance profile name.
- instance-type :white_check_mark:
Valid values: See cloud provider.
Default value: m3.medium.
- mem :white_check_mark:
- root-disk :white_check_mark:
- root-disk-source :white_check_mark:
- spaces :white_check_mark:
- tags :x:
- virt-type :x:
- zones :white_check_mark:
PLACEMENT DIRECTIVE
<machine> :white_check_mark:
subnet=... :white_check_mark:
system-id=... :negative_squared_cross_mark:
zone=... :white_check_mark:
If the query looks like a CIDR, then this will match subnets with the same CIDR. If it follows the syntax of a “subnet-XXXX”, this will match the Subnet ID. Everything else is just matched as a Name.
RESOURCE (cloud)

Consistent naming, tagging, and the ability to add user-controlled tags to created instances.

 :white_check_mark:
2

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.

3

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.

4

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

5

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

Thanks

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?

6

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
7

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

8

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

9
10