Skip to main content

AWS

Installing the AWS SAM CLI on LINUX​

There is no NEED to install homebrew as outlined in the official docs.

sudo apt install pip3
sudo pip3 install aws-sam-cli

Tips and Tricks​

When working with multiple AWS accounts using the AWC CLI it is convenient to be able to easily switch between various users each of which may be able to access different accounts.

It is possible to specify multiple credentials by creating a file named ".credentials" inside of the ".aws" directory which should be located inside your home directory. Within this file create one section per "profile" (user).

~/.aws/credentials
[default]
aws_access_key_id = YOUR_ACCESS_KEY_USED_BY_DEFAULT
aws_secret_access_key = YOUR_SECRET_ACCESS_KEY_FOR_DEFAULT

[anotherone]
aws_access_key_id = YOUR_ACCESS_KEY_USED_BY_anotherone
aws_secret_access_key = YOUR_SECRET_ACCESS_KEY_FOR_anotherone

After the ".configure" file has been generated it is possible to issue an AWS CLI command with the credential specified inside of the configuration file by adding the --profile argument to subsequent AWS commands.

aws s3 ls --profile anotherone

Alternatively, if you will be working for an extended period with the credentials of a specific profile you can switch profiles for the extent of the session by setting an environment variable.

Linux / Mac OS
export AWS_PROFILE=anotherone
Windows Powershell
$env:AWS_PROFILE='anotherone'

AWS Cloudformation​

Gotcha's​

Be careful when renaming resource identifiers within deployed templates.​

When updating Cloudformation stacks the resource keys inside of the Cloudformation template can be important in AWS deciding if a resource will be updated or replaced.

For example, assuming that an S3 bucket was created based on a resourced identifier of MyBucketS3. Then, changing the name of the resource identifier to MyNewBucket will cause AWS to try to replace the MyBucketS3 when applying the changed template.

Even if the bucket name has not been changed the fact that the resource identifier was changed causes AWS to replace the resource. The replacement of the resource in turn cause execution to fail because the bucket is not empty and has been assigned a name.

Cloudformation console may cache S3 templates.​

After updating a Cloudformation template stored in an S3 bucket the AWS console may continue to pull in the old version even if the newer version is already available in S3.

To avoid caching append a cache buster to the URL that is pasted into the console. https://1234567.s3-ap-southeast-2.amazonaws.com/templates/my-ec2.yaml?busttheawsconsolecache=dsfasfasdf

Special formatting conventions in YAML​

Specifying a YAML attribute value in JSON​

Note the syntax used to provide a property value in JSON format and the (almost) equivalent definition defined using YAML.

The YAML alternative is different in that it also demonstrated the ability to use the usual YAM functions to interpolate parameter values and functions.

Below is a bucket definition demonstrating the usage of JSON inside of a YAML cloudformation template.

CloudFormationBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
    Bucket: !Ref S3CloudFormationBucket
    PolicyDocument: | {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "111",
                "Effect": "Allow",
                "Principal": {
                    "Service": "cloudformation.amazonaws.com"
                },
                "Action": "s3:GetObject",
                "Resource": "arn:aws:s3:::velo-devops-cloudformation-repo/*"
            }
        ]
    }

Converting the JSON value to YAML​

Note the usage of YAML to specify the PolicyDocument instead of the JSON string as shown on the left.

This format also enables the usage of parameters inside of the policy definition. In this case instead of hard coding:"arn:aws:s3:::velo-devops-cloudformation-repo/" we can use a !Ref instead to make the template more robust / useful.

Below is the previous bucket definition which should usage of JSON with the JSON converted into YAML.

CloudFormationBucketPolicy:
  Type: AWS::S3::BucketPolicy
  Properties:
    Bucket: !Ref S3CloudFormationBucket
    PolicyDocument:
      Id: MyPolicy
      Version: 2012-10-17
      Statement:
        - Sid: PublicReadForGetBucketObjects
          Effect: Allow
          Principal:
            Service: cloudformation.amazonaws.com
          Action: "s3:GetObject"
          Resource: !Join
            - ""
            - - "arn:aws:s3:::"
            - !Ref S3CloudFormationBucket
            - /*

AWS Identity Access Management​

Assuming a Role with the SDK​

Create a Role in the Target account and create a Trust to the Source Account (The account from which users will assume the role.)

For extra protection add an externalId to the trust. (User must specify this externalId in order to be allowed to assume the role. NOTE: It is not possible to specify an externalId when switching roles in the console.

Therefore it is not possible to assume a role for which a trust has defined an externalId through the web console.

Within the source account, the user must be granted permission to assume the role. To grant permission to a group explicitly the group ARN which is to be assumed must be known.