Creating Stacks

In a CloudFormation template, you define your resources in the Resources section of the template. You give each resource an identifier called a logical ID. For example, the following snippet of the network‐stack.json template defines a VPC with the logical ID of PublicVPC:

"Resources": {
        "PublicVPC": {
            "Type": "AWS::EC2::VPC",
            "Properties": {
                "EnableDnsSupport": "true",
                "EnableDnsHostnames": "true",
                "CidrBlock": "10.0.0.0/16"
            }
        }
    }

The logical ID, also sometimes called the logical name, must be unique within a template. The VPC created by CloudFormation will have a VPC ID, such as vpc‐0380494054677f4b8, also known as the physical ID.

To create a stack named Network using a template stored locally, you can issue the following AWS command‐line interface (CLI) command:

aws cloudformation create-stack --stack-name Network --template-body
file://network-stack.json

CloudFormation can also read templates from an S3 bucket. To create a stack named using a template stored in an S3 bucket, you can issue the AWS command‐line interface (CLI) command in the following format:

aws cloudformation create-stack --stack-name Network --template-url
https://s3.amazonaws.com/cf-templates-c23z8b2vpmbb-us-east-1/network-stack.json

You can optionally define parameters in a template. A parameter lets you pass custom values to your stack when you create it, as opposed to hard‐coding values into the template. For instance, instead of hard‐coding the Classless Interdomain Routing (CIDR) block into a template that creates a VPC, you can define a parameter that will prompt for a CIDR when creating the stack.

Deleting Stacks

You can delete a stack from the web console or the AWS command‐line interface (CLI). For instance, to delete the stack named Network, issue the following command:

aws cloudformation delete-stack --stack-name Network

If termination protection is not enabled on the stack, CloudFormation will immediately delete the stack and all resources that were created by it.

Using Multiple Stacks

You don't have to define all of your AWS infrastructure in a single stack. Instead, you can break your infrastructure across different stacks. A best practice is to organize stacks by lifecycle and ownership. For example, the network team may create a stack named Network to define the networking infrastructure for a web‐based application. The network infrastructure would include a virtual private cloud (VPC), subnets, Internet gateway, and a route table. The development team may create a stack named Web to define the runtime environment, including a launch template, Auto Scaling group, application load balancer, IAM roles, instance profile, and a security group. Each of these teams can maintain their own stack.

When using multiple stacks with related resources, it's common to need to pass values from one stack to another. For example, an application load balancer in the Web stack needs the logical ID of the VPC in the Network stack. You therefore need a way to pass the VPC's logical ID from the Network stack to the Web stack. There are two ways to accomplish this: using nested stacks and exporting stack output values.

"Resources": {
        "NetworkStack" : {
            "Type" : "AWS::CloudFormation::Stack",
            "Properties" : {
               "TemplateURL" : "https://s3.amazonaws.com/cf-templates-c23z8b2vpmbb-us-east-1/network-stack.json"
            }
         },

"Outputs": {
        "VPCID": {
            "Description": "VPC ID",
            "Value": {
                "Ref": "PublicVPC"
            }
        },

"ALBTargetGroup": {
  "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
  "Properties": {
    "VpcId": { "Fn::GetAtt" : [ "NetworkStack", "Outputs.VPCID" ] },

"Outputs": {
        "VPCID": {
            "Description": "VPC ID",
            "Value": {
                "Ref": "PublicVPC"
            },
            "Export": {
                "Name": {
                    "Fn::Sub": "${AWS::StackName}-VPCID"
                }
            }
        },

"ALBTargetGroup": {
  "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",

  "Properties": {
    "VpcId": { "Fn::ImportValue" : {"Fn::Sub": "${NetworkStackName}-VPCID"} },

Stack Updates

If you need to reconfigure a resource in a stack, the best way is to modify the resource configuration in the source template and then either perform a direct update or create a change set.

Preventing Updates to Specific Resources

To prevent specific resources in a stack from being modified by a stack update, you can create a stack policy when you create the stack. If you want to modify a stack policy or apply one to an existing stack, you can do so using the AWS CLI. You can't remove a stack policy.

A stack policy follows the same format as other resource policies and consists of the same Effect, Action, Principal, Resource, and Condition elements. The Effect element functions the same as in other resource policies, but the Action, Principal, Resource, and Condition elements differ as follows:

• Action     The action must be one of the following:
  • Update:Modify    Allows updates to the specific resource only if the update will modify and not replace or delete the resource
  • Update:Replace    Allows updates to the specific resource only if the update will replace the resource
  • Update:Delete    Allows updates to the specific resource only if the update will delete the resource
  • Update:*    Allows all update actions
• Principal  The principal must always be the wildcard (*). You can't specify any other principal.
• Resource  This element specifies the logical ID of the resource to which the policy applies. You must prefix it with the text LogicalResourceId/.
• Condition  This element specifies the resource types, such as AWS::EC2::VPC. You can use wildcards to specify multiple resource types within a service, such as AWS::EC2::* to match all EC2 resources. If you use a wildcard, you must use the StringLike condition. Otherwise, you can use the StringEquals condition.

The following stack policy document named stackpolicy.json allows all stack updates except for those that would replace the PublicVPC resource. Such an update would include changing the VPC CIDR.

{
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "*"
    },

    {
      "Effect" : "Deny",
      "Action" : "Update:Replace",
      "Principal": "*",
      "Resource" : "LogicalResourceId/PublicVPC",
      "Condition" : {
        "StringLike" : {
            "ResourceType" : ["AWS::EC2::VPC"]
        }
      }
    }
  ]
}

CloudFormation doesn't preemptively check whether an update will violate a stack policy. If you attempt to update a stack in such a way that's prevented by the stack policy, CloudFormation will still attempt to update the stack. The update will fail only when CloudFormation attempts to perform an update prohibited by the stack policy. Therefore, when updating a stack, you must verify that the update succeeded; don't just start the update and walk away.

Overriding Stack Policies

You can temporarily override a stack policy when doing a direct update. When you perform a direct update, you can specify a stack policy that overrides the existing one. CloudFormation will apply the updated policy during the update. After the update is complete, CloudFormation will revert to the original policy.

Creating a Repository

You create a repository in CodeCommit using the AWS Management Console or the AWS CLI. When you create a new repository in CodeCommit, it is always empty. You can add files to the repository in three ways:

• Upload files using the CodeCommit management console.
• Use Git to clone the empty repository locally, add files to it, commit those changes, and then push those changes to CodeCommit.
• Use Git to push an existing local repository to CodeCommit.

Repository Security

CodeCommit uses IAM policies to control access to repositories. To help you control access to your repositories, AWS provides three managed policies. Each of the following policies allows access to all CodeCommit repositories using both the AWS Management Console and Git.

• AWSCodeCommitFullAccess   This policy provides unrestricted access to CodeCommit. This is the policy you'd generally assign to repository administrators.
• AWSCodeCommitPowerUser  This policy provides near full access to CodeCommit repositories but doesn't allow the principal to delete repositories. This is the policy you'd assign to users who need both read and write access to repositories.
• AWSCodeCommitReadOnly  This policy grants read‐only access to CodeCommit repositories.

If you want to restrict access to a specific repository, you can copy one of these policies to your own customer‐managed policy and specify the ARN of the repository.

Interacting with a Repository Using Git

Most users will interact with a CodeCommit repository via the Git command‐line interface, which you can download from git-scm.com. Many integrated development environments (IDEs) such as Eclipse, IntelliJ, Visual Studio, and Xcode provide their own user‐friendly Git‐based tools.

Only IAM principals can interact with a CodeCommit repository. AWS recommends generating a Git username and password for each IAM user from the IAM Management Console. You can generate up to two Git credentials per user. Since CodeCommit doesn't use resource‐based policies, it doesn't allow anonymous access to repositories.

If you don't want to configure IAM users or if you need to grant repository access to a federated user or application, you can grant repository access to a role. You can't assign Git credentials to a role, so instead you must configure Git to use the AWS CLI Credential Helper to obtain temporary credentials that Git can use.

Git‐based connections to CodeCommit must be encrypted in transit using either HTTPS or SSH. The easiest option is HTTPS, since it requires inputting only your Git credentials. However, if you can't use Git credentials—perhaps because of security requirements—you can use SSH. If you go this route, you must generate public and private SSH keys for each IAM user and upload the public key to AWS. The user must also have permissions granted by the IAMUserSSHKeys AWS‐managed policy. Follow the steps in Exercise 14.2 to create your own CodeCommit repository.

The CodeDeploy Agent

The CodeDeploy agent is a service that runs on your Linux or Windows instances and performs the hands‐on work of deploying the application onto an instance. You can install the CodeDeploy agent on an EC2 instance at launch using a user data script or you can bake it into an AMI. You can also use AWS Systems Manager to install it automatically. You'll learn about Systems Manager later in this chapter.

Deployments

To deploy an application using CodeDeploy, you must create a deployment that defines the compute platform, which can be EC2/on‐premises or Lambda, and the location of the application source files. CodeDeploy currently supports only deployments from S3 or GitHub. CodeDeploy doesn't automatically perform deployments. If you want to automate deployments, you can use CodePipeline, which we'll cover later in this chapter.

Deployment Groups

Prior to creating a deployment, you must create a deployment group to define which instances CodeDeploy will deploy your application to. A deployment group can be based on an EC2 Auto Scaling group, EC2 instance tags, or on‐premises instance tags.

Deployment Types

When creating a deployment group for EC2 or on‐premises instances, you must specify a deployment type. CodeDeploy gives you the following two deployment types to give you control over how you deploy your applications.

Deployment Configurations

When creating your deployment group, you must also select a deployment configuration. The deployment configuration defines the number of instances CodeDeploy simultaneously deploys to, as well as how many instances the deployment must succeed on for the entire deployment to be considered successful. The effect of a deployment configuration differs based on the deployment type. There are three preconfigured deployment configurations you can choose from: OneAtATime, HalfAtATime, and AllAtOnce.

Lifecycle Events

An instance deployment is divided into lifecycle events, which include stopping the application (if applicable), installing prerequisites, installing the application, and validating the application. During some of these lifecycle events, you can have the agent execute a lifecycle event hook, which is a script of your choosing. The following are all the lifecycle events during which you can have the agent automatically run a script:

• ApplicationStop   You can use this hook to stop an application gracefully prior to an in‐place deployment. You can also use it to perform cleanup tasks. This event occurs prior to the agent copying any application files from your repository. This event doesn't occur on original instances in a blue/green deployment, nor does it occur the first time you deploy to an instance.
• BeforeInstall   This hook occurs after the agent copies the application files to a temporary location on the instance but before it copies them to their final location. If your application files require some manipulation, such as decryption or the insertion of a unique identifier, this would be the hook to use.
• AfterInstall   After the agent copies your application files to their final destination, this hook performs further needed tasks, such as setting file permissions.
• ApplicationStart   You use this hook to start your application. For example, on a Linux instance running an Apache web server, this may be as simple as running a script that executes the systemctl httpd start command.
• ValidateService   With this event, you can check that the application is working as expected. For instance, you may check that it's generating log files or that it's established a connection to a backend database. This is the final hook for in‐place deployments that don't use an elastic load balancer.
• BeforeBlockTraffic   With an in‐place deployment using an elastic load balancer, this hook occurs first, before the instance is unregistered.
• AfterBlockTraffic   This hook occurs after the instance is unregistered from an elastic load balancer. You can use this hook to wait for user sessions or in‐process transfers to complete.
• BeforeAllowTraffic   For deployments using an elastic load balancer, this event occurs after the application is installed and validated. You can use this hook to perform any tasks needed to warm up the application or otherwise prepare it to accept traffic.
• AfterAllowTraffic   This is the final event for deployments using an elastic load balancer.

Notice that not all of these lifecycle events can occur on all instances in a blue/green deployment. The BeforeBlockTraffic event, for example, wouldn't occur on a replacement instance since it makes no sense for CodeDeploy to unregister a replacement instance from a load balancer during a deployment.

Each script run during a lifecycle event must complete successfully before CodeDeploy will allow the deployment to advance to the next event. By default, the agent will wait one hour for the script to complete before it considers the instance deployment failed. You can optionally set the timeout to a lower value, as shown in the following section.

The Application Specification File

The application specification (AppSpec) file defines where the agent should copy the application files onto your instance and what scripts it should run during the deployment process. You must place the file in the root of your application repository and name it appspec.yml. It consists of the following five sections:

• Version   Currently the only allowed version of the AppSpec file is 0.0.
• OS   Because the CodeDeploy agent works only on Linux and Windows, you must specify one of these as the operating system.
• Files   This section specifies one or more source and destination pairs identifying the files or directories to copy from your repository to the instance.
• Permissions   This section optionally sets ownership, group membership, file permissions, and Security‐Enhanced Linux (SELinux) context labels for the files after they're copied to the instance. This applies to Amazon Linux, Ubuntu, and RedHat Enterprise Linux instances only.
• Hooks   This section is where you define the scripts the agent should run at each lifecycle event. You must specify the name of the lifecycle event followed by a tuple containing the following:
  • Location  This must be a full path to an executable.
  • Timeout  You can optionally set the time in seconds that the agent will wait for the script to execute before it considers the instance deployment failed.
  • Run As  For Amazon Linux and Ubuntu instances, this lets you specify the user the script should run as.

Note that you can specify multiple locations, timeouts, and script tuples under a single lifecycle event. Keep in mind that the total timeouts for a single lifecycle event can't exceed one hour. The following is a sample appspec.yml file:

version: 0.0
os: linux
files:
  - source: /index.html
    destination: /var/www/html/
hooks:
  BeforeInstall:
    - location: scripts/install_dependencies
      timeout: 300
      runas: root

Triggers and Alarms

You can optionally set up triggers to generate an SNS notification for certain deployment and instance events, such as when a deployment succeeds or fails. You can also configure your deployment group to monitor up to 10 CloudWatch alarms. If an alarm exceeds or falls below a threshold you define, the deployment will stop.

Rollbacks

You can optionally have CodeDeploy roll back, or revert, to the last successful revision of an application if the deployment fails or if a CloudWatch alarm is triggered during deployment. Despite the name, rollbacks are actually new deployments.

Continuous Integration

Continuous integration is a method whereby developers use a version control system such as Git to regularly submit or check in their changes to a common repository. This first stage of the pipeline is called the source stage.

Depending on the application, a build system may compile the code or build it into a binary file, such as an executable, AMI, or container image. This is called the build stage. One goal of CI is to ensure that the code developers are adding to the repository works as expected and meets the requirements of the application. Thus, the build stage may also include unit tests, such as verifying that a function given a certain input returns the correct output. This way, if a change to an application causes something to break, the developer can learn of the error and fix it early. Not all applications require a build stage. For example, a web‐based application using an interpreted language like PHP doesn't need to be compiled.

Continuous Delivery

Continuous delivery incorporates elements of the CI process but also deploys the application to production. A goal of CD is to allow frequent updates to an application while minimizing the risk of failure. To do this, CD pipelines usually include a test stage. As with the build stage, the actions performed in the test stage depend on the application. For example, testing a web application may include deploying it to a test web server and verifying that the web pages display the correct content. On the other hand, testing a Linux executable that you plan to release publicly may involve deploying it to test servers running a variety of Linux distributions and versions. Of course, you always want to run such tests in a separate, nonproduction VPC.

The final stage is deployment, in which the application is deployed to production. Although CD can be fully automated without requiring human intervention, it's common to require manual approval before releasing an application to production. You can also schedule releases to occur regularly or during opportune times such as maintenance windows.

Because continuous integration and continuous delivery pipelines overlap, you'll often see them combined as the term CI/CD pipeline. Keep in mind that even though a CI/CD pipeline includes every stage from source to deployment, that doesn't mean you have to deploy to production every time you make a change. You can add logic to require a manual approval before deployment. Or you can disable transitions from one stage to the next. For instance, you may disable the transition from the test stage to the deployment stage until you're actually ready to deploy.

Creating the Pipeline

Every CodeDeploy pipeline must include at least two stages and can have up to 10. Within each stage, you must define at least one task or action to occur during the stage. An action can be one of the following types:

• Source
• Build
• Test
• Approval
• Deploy
• Invoke

CodePipeline integrates with other AWS and third‐party providers to perform the actions. You can have up to 20 actions in the same stage, and they can run sequentially or in parallel. For example, during your testing stage you can have two separate test actions that execute concurrently. Note that different action types can occur in the same stage. For instance, you can perform build and test actions in the same stage.

Artifacts

When you create a pipeline, you must specify an S3 bucket to store the files used during different stages of the pipeline. CodePipeline compresses these files into a zip file called an artifact. Different actions in the pipeline can take an artifact as an input, generate it as an output, or both.

The first stage in your pipeline must include a source action specifying the location of your application files. When your pipeline runs, CodePipeline compresses the files to create a source artifact.

If the second stage of your pipeline is a build stage, CodePipeline then unzips the source artifact and passes the contents along to the build provider. The build provider uses this as an input artifact. The build provider yields its output; let's say it's a binary file. CodePipeline takes that file and compresses it into another zip file, called an output artifact.

This process continues throughout the pipeline. When creating a pipeline, you must specify an IAM service role for CodePipeline to assume. It uses this role to obtain permissions to the S3 bucket. The bucket must exist in the same region as the pipeline. You can use the same bucket for multiple pipelines, but each pipeline can use only one bucket for artifact storage.

Actions

Actions let you automatically or manually perform actions against your AWS resources, either individually or in bulk. These actions must be defined in documents, which are divided into three types:

• Automation—Actions you can run against your AWS resources
• Command—Actions you run against your Linux or Windows instances
• Policy—Defines metadata to collect, such as software inventory and network configurations

Insights

Insights aggregate health, compliance, and operational details about your AWS resources into a single area of AWS Systems Manager. Some insights are categorized according to AWS resource groups, which are collections of resources in an AWS region. You define a resource group based on one or more tag keys and optionally tag values. For example, you can apply the same tag key to all resources related to a particular application—EC2 instances, S3 buckets, EBS volumes, security groups, and so on. Insights are categorized, as we'll cover next.

Review Questions

1. When using CloudFormation to provision multiple stacks of related resources, by which of the following should you organize your resources into different stacks? (Choose two.)
   1. Cost
   2. S3 bucket
   3. Lifecycle
   4. Ownership
2. Which of the following resource properties are good candidates for definition as parameters in a CloudFormation template? (Choose two.)
   1. AMI ID
   2. EC2 key pair name
   3. Stack name
   4. Logical ID
3. You want to use nested stacks to create an EC2 Auto Scaling group and the supporting VPC infrastructure. These stacks do not need to pass any information to stacks outside of the nested stack hierarchy. Which of the following must you add to the template that creates the Auto Scaling group?
   1. An Export field to the Output section
   2. A resource of the type AWS::EC2::VPC
   3. A resource of the type AWS::CloudFormation::Stack
   4. Fn::ImportValue
4. You need to update a stack that has a stack policy applied. What must you do to verify the specific resources CloudFormation will change before updating the stack?
   1. Create a change set.
   2. Perform a direct update.
   3. Update the stack policy.
   4. Override the stack policy.
5. You've granted a developer's IAM user permissions to read and write to a CodeCommit repository using Git. What information should you give the developer to access the repository as an IAM user?
   1. IAM username and password
   2. Access key and secret key
   3. Git username and password
   4. SSH public key
6. You need grant access to a specific CodeCommit repository to only one IAM user. How can you do this?
   1. Specify the repository's clone URL in an IAM policy.
   2. Generate Git credentials only for the user.
   3. Specify the user's ARN in a repository policy.
   4. Specify the repository's ARN in an IAM policy.
7. You need to store text‐based documentation for your data center infrastructure. This documentation changes frequently, and auditors need to be able to see how the documents change over time. The documents must also be encrypted at rest. Which service should you use to store the documents and why?
   1. CodeCommit, because it offers differencing
   2. S3, because it offers versioning
   3. S3, because it works with customer‐managed KMS keys
   4. CodeCommit, because it works with customer‐managed KMS keys
8. Which command will download a CodeCommit repository?
   1. aws codecommit get‐repository
   2. git clone
   3. git push
   4. git add
9. You need to deploy an application using CodeDeploy. Where must you place your application files so that CodeDeploy can deploy them?
   1. An EBS snapshot
   2. A CodeCommit repository
   3. A self‐hosted Git repository
   4. An S3 bucket
10. Which deployment type requires an elastic load balancer?
    1. In‐place instance deployment
    2. Blue/green instance deployment
    3. Blue/green Lambda deployment
    4. In‐place Lambda deployment
11. You want to use CodeDeploy to perform an in‐place upgrade of an application running on five instances. You consider the entire deployment successful if the deployment succeeds even on only one instance. Which preconfigured deployment configuration should you use?
    1. OneAtATime
    2. HalfAtATime
    3. AllAtOnce
    4. OnlyOne
12. You want CodeDeploy to run a shell script that performs final checks against your application after allowing traffic to it and before declaring the deployment successful. Which lifecycle event hook should you use?
    1. ValidateService
    2. AfterAllowTraffic
    3. BeforeAllowTraffic
    4. AllowTraffic
13. The build stage of your software development pipeline compiles Java source code into a binary JAR file that can be deployed to a web server. CodePipeline compresses this file and puts it in an S3 bucket. What's the term for this compressed file?
    1. An artifact
    2. A provider
    3. An asset
    4. A snapshot
14. You're designing an automated continuous integration pipeline and want to ensure developers don't accidentally trigger a release to production when checking in code. What are two ways to accomplish this? (Choose two).
    1. Create a separate bucket in S3 to store artifacts for deployment.
    2. Implement an approval action before the deploy stage.
    3. Disable the transition to the deploy stage.
    4. Don't allow developers access to the deployment artifact bucket.
15. You have CloudFormation templates stored in a CodeCommit repository. Whenever someone updates a template, you want a new CloudFormation stack automatically deployed. How should you design a CodePipeline pipeline to achieve this? (Choose all that apply).
    1. Use a source action with the CodeCommit provider.
    2. Use a build action with the CloudFormation provider.
    3. Use a deploy action with the CodeCommit provider.
    4. Use a deploy action with the CloudFormation provider.
    5. Create a two‐stage pipeline.
    6. Create a three‐stage pipeline.
    7. Create a single‐stage pipeline.
16. How many stages can you have in a pipeline?
    1. 1
    2. 10
    3. 20
    4. 21
17. You need to manually take EBS snapshots of several hundred volumes. Which type of Systems Manager document enables you to do this?
    1. Command
    2. Automation
    3. Policy
    4. Manual
18. You want to use Systems Manager to perform routine administration tasks and collect software inventory on your EC2 instances running Amazon Linux. You already have an instance profile attached to these instances. Which of the following should you do to enable you to use Systems Manager for these tasks?
    1. Add the permissions from the AmazonEC2RoleforSSM managed policy to the role you're using for the instance profile.
    2. Manually install the Systems Manager agent.
    3. Use Session Manager to install the Systems Manager agent.
    4. Modify the instance security groups to allow access from Systems Manager.
19. You've configured Patch Manager to patch your Windows instances every Saturday. The custom patch baseline you're using has a seven‐day auto‐approval delay for security‐related patches. On this Monday, a critical security patch was released, and you want to push it to your instances as soon as possible. You also want to take the opportunity to install all other available security‐related packages. How can you accomplish this? (Choose two).
    1. Execute the AWS‐RunPatchBaseline document.
    2. Add the patch to the list of approved patches in the patch baseline.
    3. Change the maintenance window to occur every Monday at midnight.
    4. Set the patch baseline's auto‐approval delay to zero days.
20. You've installed the Systems Manager agent on an Ubuntu instance and ensured the correct instance profile is applied. But Systems Manager Insights don't display the current network configuration. Which of the following must you do to be able to automatically collect and view the network configuration for this and future instances in the same region?
    1. Make sure the instance is running.
    2. Create a global inventory association.
    3. Execute the AWS‐GatherSoftwareInventory policy document against the instance.
    4. Execute the AWS‐SetupManagedInstance automation document against the instance.