Getting Started with an AWS Account

The AWS Certified Developer – Associate is designed for developers who have hands-on experience working with AWS services. To help you prepare, this book has recommended exercises at the end of each chapter.

To work with AWS, you’ll need an account. While you must provide contact and payment information to sign up for an account, you can test many of these services through the AWS Free Tier. The AWS Free Tier limits allow you to become familiar with the APIs for the included services without incurring charges.

The AWS Free Tier automatically provides usage alerts to help you stay in control of usage and identify possible charges. You can define additional alerts with AWS Budgets. To best take advantage of the AWS Free Tier and reduce costs, take some time to review the AWS Free Tier limits, and make sure to shut down or delete resources when you are done using them.

To create an account, sign up at https://aws.amazon.com/free.

AWS Management Console

After you have created an account, you will be prompted to sign in to the AWS Management Console. As part of the sign-up process, you define an email address and password to sign in to the console as the root user for the account.

The console is a web interface where you can create, configure, and monitor AWS resources in your account. You can quickly identify the AWS services that are available to you and explore the functionality of those services. Links are also provided to learning materials to help you get started.

Sign in to the console, as shown in Figure 1.1, at https://signin.aws.amazon.com/console.

Because all the functionality of AWS is exposed through APIs, AWS provides more than only the web interface for managing resources. For example, the console is also available as a mobile app for iOS and for Android.

After you become familiar with a service, you can manage AWS resources programmatically through either the AWS Command Line Interface (AWS CLI) or the AWS software development kits (AWS SDKs), as shown in Figure 1.2.

AWS Software Development Kits

AWS SDKs are available in many popular programming languages such as Java, .NET, JavaScript, PHP, Python, Ruby, Go, and C++. AWS also provides specialty SDKs such as the AWS Mobile SDK and AWS Internet of Things (IoT) Device SDK.

Although the instructions for installing and using an AWS SDK vary depending on the operating system and programming language, they share many similarities. In this chapter, the examples are provided in Python.

The Python SDK for AWS is called AWS SDK for Python (Boto). If Python 2 or Python 3 is already installed on your machine, install boto3 using pip, the Python package manager.

To install boto3, open a terminal and run the following command:

pip install boto3 --upgrade –user

For documentation on the Python SDK, see http://boto3.readthedocs.io/.

For more information on SDKs for other programming languages or platforms, see https://aws.amazon.com/tools/#sdk.

AWS CLI Tools

In addition to the AWS Management Console and SDKs, AWS provides tools to manage AWS resources from the command line. One such tool is the AWS CLI, which is available on Windows, Linux/Unix, and macOS.

The AWS CLI allows you to perform actions similar to those from the SDKs but in an interactive scripting environment. Because the AWS CLI is interactive, it is a good environment for experimenting with AWS features. Also, the AWS CLI and the SDK on the same server can share configuration settings.

If you prefer to manage your resources using PowerShell, use the AWS Tools for PowerShell instead of the AWS CLI. Other specialty command line tools are also provided, such as the Elastic Beanstalk command line interface and AWS SAM Local. For more information about these tools and installation, see https://aws.amazon.com/tools/#cli.

API Example: Hello World

In the following example, you will make a request to Amazon Polly. Amazon Polly provides text-to-speech service with natural-sounding speech, and it is able to provide speech in multiple languages with a variety of male and female voices. Furthermore, you can modify attributes, such as pronunciation, volume, pitch, or speed, by defining lexicons or supplying Speech Synthesis Markup Language (SSML).

This Python code example uses the AWS SDK for Python (Boto) and Amazon Polly to generate an audio clip that says, “Hello World.”

import boto3
 
#Explicit Client Configuration
polly = boto3.client('polly',
        region_name='us-west-2',
        aws_access_key_id='AKIAIO5FODNN7EXAMPLE',
        aws_secret_access_key='ABCDEF+c2L7yXeGvUyrPgYsDnWRRC1AYEXAMPLE'
        )
 
result = polly.synthesize_speech(Text='Hello World!',
                                 OutputFormat='mp3',
                                 VoiceId='Aditi')
 
# Save the Audio from the response
audio = result['AudioStream'].read()
with open("helloworld.mp3","wb") as file:
    file.write(audio)

The AWS SDK maps the function call to an HTTPS request to an Amazon Polly API endpoint that is determined by the region name (region_name) parameter.

The SDK also adds authorization information to your request by signing the request using a key derived from the AWS secret access key.

When your request is received at the Amazon Polly API endpoint, AWS authenticates the signature and evaluates AWS Identity and Access Management (IAM) policies to authorize the API action.

If authorization succeeds, Amazon Polly processes the request, generates an MP3 audio file, and then returns it to the SDK client as part of the response to the HTTPS request, as shown in Figure 1.3.

POST /v1/speech HTTP/1.1 host: polly.us-west-2.amazonaws.com
content-Type: application/json
x-amz-date: 20180411T051402Z
authorization: AWS4-HMAC-SHA256 Credential=AKIAIO5FODNN7EXAMPLE/20180411/us-west-2/polly/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-date, Signature=d968197e88a6a8de69d1a7bcab414669eecd5f841e13dc90e4a7852c2c428038
 
{
       "OutputFormat": "mp3",
       "Text" : "Hello World!",
       "VoiceId": "Aditi"
}

HTTP/1.1 200
status: 200
content-type: audio/mpeg
date: Wed, 11 Apr 2018 05:14:02 GMT
x-amzn-requestcharacters: 12
x-amzn-requestid: 924141bb-b0a6-11e8-b565-b1fabccdcbd9
transfer-encoding: chunked
connection: keep-alive

SDK Configuration

In the previous example, the AWS Region and AWS credentials are provided explicitly in the code. The SDK client initialization code from the earlier example is shown again here:

# Explicit Client Configuration
polly = boto3.client('polly',
       region_name='us-west-2',
       aws_access_key_id='AKIAIO5FODNN7EXAMPLE',
       aws_secret_access_key='ABCDEF+c2L7yXeGvUyrPgYsDnWRRC1AYEXAMPLE'
       )

This explicit approach of hardcoding credentials into the code is not recommended, because it carries the risk of checking the credentials into a source-control repository. This would expose the keys to everyone who has access to the repository and could even result in public disclosure. To prevent this, configure the SDK credentials separately from the application source code.

The SDK and AWS CLI automatically check several locations for credentials, and for the region if they are not explicitly provided in the code. These locations include environment variables, programming language–specific parameter stores, and local files.

To configure an AWS access key on your local machine in a local file, create a credentials file in the .aws folder in the home folder for the current user. Within this file, specify credentials for the default profile. You may optionally include additional named profiles beyond the default as needed.

[default]
aws_access_key id=AKIAIO5FODNN7EXAMPLE
aws_secret_access_key=ABCDEF+c2L7yXeGvUyrPgYsDnWRRC1AYEXAMPLE
 
From File: ~/.aws/credentials

Furthermore, hardcoding the AWS Region into the code makes it difficult to deploy your application in different AWS Regions. Instead, create a config file also within the .aws folder within your current user’s home directory. Within this file, specify a region to use with the default profile.

[default]
region = us-west-2
 
From File: ~/.aws/config

As an alternative to creating the credentials and config files manually, you can use the AWS CLI to generate the credentials and config files for the default profile as follows:

aws configure

This command prompts for credentials and region settings. When the command completes, the config and credentials files are generated, as shown in Figure 1.4.

When the configuration is complete, replace this snippet of code:

# Explicit Client Configuration
polly = boto3.client('polly',
       region_name='us-west-2',
       aws_access_key_id='AKIAIO5FODNN7EXAMPLE',
       aws_secret_access_key='ABCDEF+c2L7yXeGvUyrPgYsDnWRRC1AYEXAMPLE'
       )

with this line of code:

# Implicit Client Configuration
polly = boto3.client('polly')

By separating your code from the credentials, you make it easier to collaborate with other developers while making sure that your credentials are not inadvertently disclosed to others.

Regions Are Highly Available

Each AWS Region contains multiple data centers, grouped together to form Availability Zones. Regions are composed of multiple Availability Zones, which allows AWS to provide highly available services in a way that differentiates them from traditional architectures with single or multiple data centers.

Availability Zones are physically separated from each other and are designed to operate independently from each other in the case of a fault or natural disaster, as shown in Figure 1.6. Even though they are physically separated, Availability Zones are connected via low-latency, high-throughput redundant networking.

AWS customers can improve the resilience of their applications by deploying a copy of each application to a second Availability Zone within the same region. This allows the application to remain available to customers even in the face of events that could disrupt an entire data center. Similarly, many of the AWS services automatically replicate data across multiple Availability Zones within an AWS Region to provide high availability and durability of the data.

An example of an AWS service that replicates data across Availability Zones within a region is Amazon Simple Storage Service (Amazon S3). Amazon S3 enable you to upload files and store those files as objects within a bucket. By default, Amazon S3 automatically replicates objects across a minimum of three Availability Zones within the region hosting the bucket. This design protects data even against the loss of one entire Availability Zone.

Working with Regional API Endpoints

Many AWS services expose regional API endpoints. When making web service calls to regional endpoints, the region can typically be identified in the URL that you invoke. API calls to a regional endpoint usually affect only the resources within the specific AWS Region that corresponds to that endpoint.

To explore this concept, revisit the previous example of making a request to Amazon Polly to synthesize speech from text.

# Initializing SDK Client with Explicit Region Configuration
polly = boto3.client('polly', region_name='us-west-2')
result = polly.synthesize_speech(Text='Hello World!',
                                 OutputFormat='mp3',
                                 VoiceId='Aditi')

To explicitly configure the AWS SDK to use the US West (Oregon) Region, set the region_name parameter to us-west-2 when initializing the SDK client, as in the previous example.

This configuration results in the SDK computing the following URL for the API request, as shown in Figure 1.7.

You can see regional isolation in practice by uploading a lexicon to Amazon Polly. A lexicon stores custom pronunciation information that can be used when synthesizing speech from text. For example, you can require Amazon Polly to expand the acronym AWS to “Amazon Web Services” in the generated audio file by providing the following XML lexicon. The file tells Amazon Polly to speak the alias “Amazon Web Services” when it encounters the grapheme “AWS” in text.

<?xml version="1.0" encoding="UTF-8"?>
<lexicon version="1.0"
      xmlns="http://www.w3.org/2005/01/pronunciation-lexicon"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.w3.org/2005/01/pronunciation-lexicon
        http://www.w3.org/TR/2007/CR-pronunciation-lexicon-20071212/pls.xsd"
      alphabet="ipa"
      xml:lang="en-US">
  <lexeme>
    <grapheme>AWS</grapheme>
    <alias>Amazon Web Services</alias>
  </lexeme>
</lexicon>
File: aws-lexicon.xml

To use this lexicon when you synthesize speech, you must first upload it to Amazon Polly. The following shell snippet uses the AWS CLI to upload to the lexicon to the specified region:

aws polly put-lexicon --name awsLexicon --content file://aws-lexicon.xml --region us-west-2

You can use the awsLexicon after it is uploaded. The following example generates a speech request that will be customized by the lexicon. This request is also being made to the us-west-2 API endpoint.

# Synthesizing speech with custom lexicon in the same region
aws polly synthesize-speech --text 'Hello AWS World!' --voice-id Joanna --output-format mp3 hello.mp3 --lexicon-names="awsLexicon" --region us-west-2

{
    "ContentType": "audio/mpeg",
    "RequestCharacters": "15"
}

Assuming that the CLI is configured correctly with an appropriate access key, this request succeeds. In the downloaded audio file, you will hear Joanna say “Hello Amazon Web Services World,” confirming that the lexicon is in effect.

However, if you run the same API request again, but change the region to the US East (N. Virginia) Region, as in the following example, you will get a different result:

# Trying again against a different Regional API endpoint
aws polly synthesize-speech --text 'Hello AWS World' --voice-id Joanna --output-format mp3 hello-custom.mp3 --lexicon-names="awsLexicon" --region us-east-1

 
An error occurred (LexiconNotFoundException) when calling the SynthesizeSpeech operation: Lexicon not found

In this case, an error occurs because the awsLexicon resides only in the US West (Oregon) Region where you placed it. When working with AWS services that are regional in scope, you are in control over where the data resides—AWS does not automatically copy your data for these services to other regions without an explicit action on your part. If you must use the lexicon in regions other than US West (Oregon), you could upload the lexicon to each region in which you plan to use it.

Users

IAM users can be assigned long-term security credentials. You might create an IAM user when you have a new team member or application that needs to make AWS API calls. Manage the API permissions of the user by associating permissions policies with the user or adding the user to a group that has permissions policies associated with it.

After you create an IAM user, you can assign credentials to allow AWS Management Console access, programmatic access, or both, as shown in Figure 1.8.

aws_access_key_id = AKIAJXR7IOGGTEIVNX7Q
aws_secret_access_key: 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

Groups

To help you manage the permissions of collections of IAM users, IAM provides IAM groups. IAM groups do not have their own credentials, but when an IAM user makes an API call with their access key, AWS looks up that user’s group memberships and finds the relevant permissions policies. Associate users who need the same permissions with a group and then assign policies to the group instead of associating the permissions directly to each user.

For example, all developers working on a specific project could each have their own IAM user. Each of these users can be added to a group, named developers, to manage their permissions collectively. In this way, each team member has unique credentials while they are also given the same permissions.

You may create additional groups. For example, you may create a second group for the team members responsible for changing the build and deployment pipeline to which you can assign a name such as devtools.

The relationship between IAM users and IAM groups is many-to-many. An individual IAM user can be a member of many IAM groups, and each IAM group can have many IAM users associated with the group. IAM users within an IAM group inherit permissions from the policies attached to their group, plus any permissions from policies that are associated directly with that IAM user.

In the example shown in Figure 1.9, carla inherits permissions from the IAM user carla and from the group developers, and takumi inherits the union of all of the policies from developers and from devtools, in addition to any policies directly associated with takumi.

In the case that multiple permissions policies apply to the same API action, any policy that has the effect deny will take precedence over any policy that has the effect allow. This order of precedence is applied regardless of whether the policies are associated with the user, group, or resource.

Roles

There are situations in which you might not want to create and manage new sets of long-term credentials for team members or applications.

In a large company with many employees, you can use your existing corporate identity store instead of creating new identities and credentials for each team member who manages AWS.

Alternatively, you may delegate permissions to an AWS service to perform actions on your behalf. One common example of this is when application code running on an AWS compute service, such as Amazon EC2, needs permissions to make AWS API calls. In this case, AWS recommends allowing Amazon EC2 to manage the credentials for each instance.

In both situations, rather than creating new IAM users, create an IAM role to assign permissions. IAM roles can be assumed for short-term sessions, as shown in Figure 1.10.

To control access to an IAM role, define a trust policy that specifies which principals can assume a role. Potential principals include AWS services and also users who have authenticated using identity federation. Principals could also include users who authenticate with web identity federation, IAM users, IAM groups, or IAM roles from other accounts.

This example trust policy allows Amazon EC2 to request short-term credentials associated with an IAM role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"

      },
      "Action": "sts:AssumeRole"

    }
  ]
}

When a principal assumes a role, AWS provides new short-term security credentials that are valid for a time-limited session through the AWS Security Token Service (AWS STS). These credentials are composed of an access key ID, secret access key, and, additionally, a session token with a known expiration date.

This example displays the credentials that are generated when the role is assumed:

{
       "AccessKeyId": "ASIAJHP2KG65VIKQU2XQ",
       "SecretAccessKey": "zkvPEbYxCLVVD0seWdRnesc8krNDPHEX1cFMyI5W",
       "SessionToken":
"FQoDYXdzEMf//////////wEaDL1b0Wd7VTA3J25cNyL4ARzNSRczH4U3f8gJwi1W8XiDLWJIE9EdX
4l4KXTiST40gPoWc9Do9QkcN2xRHk6/qVT6W23d0u6+5YFY9C2wnoEeTTmiQBT5SMjqku5MYlhrCDy
FQAVbo6RKUeOZXXSG8REshuFGBtaCNmv95lFF6srCT1b4FZtTtULE7WV3LMcDs6Z2XuN+6aGTawhY5
0RMnlKRL1w6yHq++RysQWbBHkuNeK/VqjueDINFODPOje9ZnYePVjR5uLmL8ZARWYVBFrB2tpxG07/
dseUS9O2q1hMP8DJuEfsbaiK2ASsmXSRA8vOZnuu4AsBq6ERasBw5EcpICP/Ne8zdKO/93tYF",
        "Expiration": "2018-04-18T22:55:59Z"
}

When these short-term credentials are used, AWS looks up the permissions policies associated with the IAM role that was assumed. This is true even if the principal that assumed the role was an IAM user—policies that were associated with the IAM user or their groups are not evaluated when the role credentials are used to make a request. The IAM role is a distinct identity with its own permissions. Furthermore, you cannot nest IAM roles or add IAM roles to IAM groups, as shown in Figure 1.11.

Choosing IAM Identities

Consider the following to determine how to define authorization and authentication.

Managing Authorization with Policies

Manage the permissions for each user, group, or role by assigning IAM policies that either allow or deny permissions to specific API actions, as shown in Figure 1.12. Any API action is implicitly denied unless there is a policy that explicitly allows it. If there is a policy that explicitly denies an action, that policy always takes precedence. In this way, AWS defaults to secure operation and errs on the side of protecting the resources in cases where there are conflicting policies.

One method of granting permissions is to use AWS managed policies. AWS provides these policies to support common tasks and are automatically updated as new services and API operations are added.

When choosing permissions policies, AWS recommends that you adopt the principle of least privilege and grant someone the minimum permissions they need to complete a task. If they need more access later, they can ask for it, and you can update the permissions then.

Take the example of an application that uses Amazon Polly. If the application uses only Amazon Polly to synthesize speech, use the AmazonPollyReadOnlyAccess policy, which grants permissions to Amazon Polly actions that do not store any data or modify data stored in AWS. The policy is represented as a JSON document and shown here:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "polly:DescribeVoices",
                "polly:GetLexicon",
                "polly:ListLexicons",
                "polly:SynthesizeSpeech"
            ],
            "Resource": [
                "*"
            ]
        }
    ]

If the application needs permission to upload (or delete) a custom lexicon, this operation modifies a state in Amazon Polly. To grant permissions to these actions, use the AmazonPollyFullAccess policy. The policy is shown here. Notice that the actions granted by the policy shown here are represented as "polly:*", where the * provides access to all Amazon Polly API actions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "polly:*"

            ],
            "Resource": [
                "*"

            ]
        }i
    ]
}

Custom Policies

AWS recommends that you use the AWS managed policies whenever possible. However, when you need more control, you can define custom policies.

As shown in the earlier examples, an IAM policy is a JSON-style document composed of one or more statements. Each statement has an effect that will either allow or deny access to specific API actions on AWS resources. A deny statement takes precedence over any allow statements. Use an Amazon Resource Name (ARN) to specify precisely the resource or resources to which a custom policy applies.

For example, the following policy authorizes access to the DeleteLexicon action in Amazon Polly on the resource specified by the ARN. In this case, the resource is a particular lexicon within a specific account and within a specific region.

{
  "Version": "2012-10-17",
  "Statement": [{
      "Sid": "AllowDeleteForSpecifiedLexicon",
      "Effect": "Allow",
      "Action": [
         "polly:DeleteLexicon"],
      "Resource": "arn:aws:polly:us-west-2:123456789012:lexicon/awsLexicon"
      }
   ]
}

To allow slightly broader permissions in a similar policy, use wildcards in the ARN. For example, to allow a user to delete any lexicon within the specified region and account, replace awsLexicon with an * in the ARN, as shown here:

{
  "Version": "2012-10-17",
  "Statement": [{
      "Sid": "AllowDeleteSpecifiedRegion",
      "Effect": "Allow",
      "Action": [
         "polly:DeleteLexicon"],
      "Resource": "arn:aws:polly:us-east-2:123456789012:lexicon/*"
      }
   ]
}

An ARN always starts with arn: and can include the following components to identify a particular AWS resource uniquely:

Partition Usually aws. For some regions, such as in China, this can have a different value.

Service Namespace of the AWS service.

Region The region in which the resource is located. Some resources do not require a region to be specified.

Account ID The account in which the resource resides. Some resources do not require an account ID to be specified.

Resource The specific resource within the namespace of the AWS service. For services that have multiple types of resources, there may also be a resource type.

These are example formats for an ARN:

arn:partition:service:region:account-id:resource
arn:partition:service:region:account-id:resourcetype/resource
arn:partition:service:region:account-id:resourcetype:resource

Here are some examples of ARNs for various AWS resources:

<!-- Amazon Polly Lexicon -->
arn:aws:polly:us-west-2:123456789012:lexicon/awsLexicon
 
<!-- IAM user name -->
arn:aws:iam::123456789012:user/carla
 
 
<!-- Object in an Amazon S3 bucket -->
arn:aws:s3:::bucket-name/exampleobject.png

A single policy document can have multiple statements. Additional components to a statement may include an optional statement ID (Sid) and condition blocks to restrict when the policy applies. If the policy is attached to a resource rather than to an IAM identity, then the policy must also specify a principal (to whom the policy applies), as shown in Figure 1.13.

Write custom policies manually or use tools like the Visual Policy Editor in the AWS Management Console to generate policies more easily. To help you test the effects of policies, you can also use the IAM policy simulator at https://policysim.aws.amazon.com.