AWS Certified Solutions Architect Professional – Study Guide – Domain 3.0: Deployment Management (10%)

3.1 Ability to manage the lifecycle of an application on AWS

• CloudFormation is a way of scripting the deployment of infrastructure and can automatically take care of dependencies and introduce version management
• CloudFormation supports the following services:-
  • Auto Scaling
  • CloudFront
  • CloudTrail
  • CloudWatch
  • DynamoDB
  • EC2
  • ElastiCache
  • Elastic Beanstalk
  • Elastic Load Balancer
  • Kinesis
  • IAM
  • OpsWorks
  • RDS
  • RedShift
  • Route53
  • S3
  • SimpleDB
  • SNS
  • SQS
  • VPC
  • CloudFormation is made up of a template and a stack
    • A template is an architectural “diagram” of what the deployment will look like
    • A stack is the actual deployment itself (and its constituent services)
    • You can create, update and delete stacks using templates
  • Templates are in JSON format
  • You don’t need to delete a stack in order to update individual components
  • Template has the following characteristics:-
    • File format and version number (mandatory)
    • List of AWS resources and their configuration values (mandatory)
    • Everything else is optional
      • Template parameters (applied at stack creation time, limit of 60)
      • Output values (public IP address, ELB address, limit of 60)
      • List of data tables (AMI types etc.)
      • Use Fn:GetAtt to output data. Fn uses an intrinsic function and also has Fn:GetInMap, Fn:GetAZs to return a value from a lookup
  • In order to successfully deploy/delete/update a stack, the user must have appropriate IAM permissions to all objects the stack contains (e.g. EC2 instances, S3 buckets etc.). If not, deployment will fail
  • Chef and Puppet are supported to provide a configuration down to the application layer
  • Bootstrap scripts also supported to allow installation of packages, files and applications by adding them to the template
  • Automatic rollback on error is automatically enabled
  • You are still charged for provisioned resources, even if the deployment fails
  • CloudFormation is free
  • CloudFormation has a WaitCondition resource that can wait for an application or deployment response before continuing on
  • You can specify deletion policies:-
    • Take a snapshot of an EC2 instance, EBS volume or RDS instance before deletion
    • Preserve a resource when deleting a stack, such as an S3 bucket
  • CloudFormation can be used to create roles in IAM
    • Also grant EC2 instances access to roles
  • CloudFormation can create VPCs and their components:-
    • Subnets
    • Gateways
    • Route Tables
    • Network ACLs
    • Elastic IPs
    • EC2 instances
    • Auto Scaling Groups
    • Elastic Load Balancers
    • RDS Instances
    • RDS Security Groups
  • You can specify IP addresses as either specific individual addresses or CIDR ranges. You can also specify pre-existing elastic IP addresses
  • Can create multiple VPCs inside one template

• Can enable VPC peering from CloudFormation but only within the same AWS account

• Route 53 zones can be created or updated from a template
  • A Records, CNAME, Alias etc
• Remember what is mandatory for a template (Format, version and resources)
• Chef, Puppet and Bootstrap are the supported deployment tools
• Cfn-init can be used when the instances are created to install packages, start services, define service states, etc
• Elastic Beanstalk is a pre-built web application environment that developers can upload applications to for a quick deployment time
• Elastic Beanstalk takes care of capacity, provisioning, auto scaling and monitoring
• Provides a “portal” based access method for developers to upload their application
• CloudFormation supports Elastic Beanstalk, but not vice versa
• Elastic Beanstalk supports the following:-
  • Apache Tomcat for Java applications
  • Apache HTTP for PHP applications
  • Apache HTTP for Python applications
  • Nginx or Apache HTTP for Node.js applications
  • Passenger for Ruby applications
  • IIS 7.5 for .NET applications
• Elastic Beanstalk provides access to CloudWatch for application status and monitoring
• You can adjust application settings (such as JVM settings) and pass environment variables
• Elastic Beanstalk has three components within applications:-
  • Environments (EC2, ELB, ASGs)
  • Application versions (stored in S3, highly available, roll back code, can also push from git)
  • Saved configurations (define how objects behave including auto scaling groups, e-mail notifications, instances, managed update settings, software configurations, update configuration etc. App can have many saved configurations)
• Two types of Elastic Beanstalk deployments:-
  • Single instance
  • Load balancing, auto scaling
• Two tiers of Elastic Beanstalk
  • Web server
  • Worker server (no web components, just runs binaries, listens to SQS queues for work)
• Application environments can be set for test/dev, staging, production etc for blue/green deployments
• Use RDS for test and dev as this is removed when EB has the application removed. Production requires more permanent data store, so use already provisioned RDS instance
• You can deploy Docker containers to EB in one of three ways:-
  • Dockerfile (image built on instance)
  • Dockerfile.json.aws (manifest that describes how to use Docker image – name of the image, port mappings and is unique to EB)
  • Application archive (should include Dockerfile or Dockerfile.json.aws)
• Benefits of using Docker images include you can use any runtime, even ones not supported by EB (Scala, for example)
• Dockerfile is basically a manifest file that defines how the docker application is setup. There are several command used within the file to determine such settings as maintainer name, commands to run, ADD (downloads content from a local store or git URL, ENV for environment variables, FROM (defines base image and must be declared first in the Dockerfile), VOLUME (mount host local directory inside the container), RUN (get updates for packages etc)
• .ebextensions file lists all the resources created by EB (IAM roles, instances, RDS etc)
• Use Swap URLs feature for a quick cut over between prod and staging, with zero downtime – however this is all or nothing, if the app is broken it will break all instances
• eb deploy command reads the .git folder for commits, if not present it uses the current folder for deploying to EB
• When deploying apps in EB, note the following policies for deployment policies:-
• Deployment policy – Choose from the following deployment options:
  • All at once – Deploy the new version to all instances simultaneously. All instances in your environment are out of service for a short time while the deployment occurs.
  • Rolling – Deploy the new version in batches. Each batch is taken out of service during the deployment phase, reducing your environment’s capacity by the number of instances in a batch.
  • Rolling with additional batch – Deploy the new version in batches, but first launch a new batch of instances to ensure full capacity during the deployment process.
  • Immutable – Deploy the new version to a fresh group of instances by performing an immutable update (alternative to rolling updates that ensure that configuration changes that require replacing instances are applied efficiently and safely. If an immutable environment update fails, the rollback process requires only terminating an Auto Scaling group. A failed rolling update, on the other hand, requires performing an additional rolling update to roll back the changes).
• Batch type – Whether you want to allocate a percentage of the total number of EC2 instances in the Auto Scaling group or a fixed number to a batch of instances.
• Batch size – The number or percentage of instances to deploy in each batch, up to 100 percent or the maximum instance count in your environment’s Auto Scaling configuration.
• EB logs can be sent to an S3 bucket
• Can run other components (such as ElastiCache) side by side in EC2 instances
• Access log files without logging into application servers
• Push an application file (such as a WAR file) or Github repo to Elastic Beanstalk
• AWS Toolkit for Visual Studio also available
• Only modified git files are uploaded to Elastic Beanstalk
• Elastic Beanstalk is designed to support multiple environments such as test/dev, staging and production
• Each environment is configured separately and runs on it’s own AWS resources
• Elastic Beanstalk stores and tracks application versions so apps can be rolled back to a prior state
• Application files and optionally log files are stored in S3
• If you are using the management console, git, AWS Toolkit for Visual Studio, an S3 bucket is created automatically and files are uploaded to this bucket
• You can configure EB to upload log files to S3 every hour
• S3 can also be used for application storage for items such as images, etc. Include the SDK as part of your application deployment
• Elastic Beanstalk can automatically configure an RDS instance, environment variables are used to expose DB instance connection information to your application
• Elastic Beanstalk is not fault tolerant amongst regions but can be configured to be multi AZ in a region for resilience
• Your application is publicly available via app.elasticbeanstalk.com. As EB integrates with VPCs, you can configure security groups or NACLs to restrict access
• Elastic Beanstalk supports IAM
• You can SSH into EB instances if required
• Amazon Linux AMI and Windows 2008/2012 are supported
• OpsWorks is a service based on Chef that provides scripted and automated management of applications and their dependencies
• Chef turns infrastructure into code
• Chef provides scripting and automation for the building out of infrastructure
• Infrastructure then becomes scriptable, testable and versionable like your applications
• Chef has a client/server infrastructure
• The Chef server stores all recipes and also configuration data
• The Chef client is installed on all pieces of infrastructure you manage, such as servers and network devices
• The client periodically polls the server for policy updates. If the client policy is out of date, remediation takes place
• OpsWorks consists of two elements, stacks and layers
• A stack is is a group of EC2 instances and related objects such as ELBs that are grouped together for a common purpose
• A layer exists within a stack and is represented by such things as database or application layers
• When you create a layer, instead of configuring everything manually, OpsWorks does this for you
• There are 1 or more layers in a stack
• An instance must be assigned to at least one layer
• Preconfigured layers include database layers, applications, load balancing and caching
• Instances are always Linux in Chef 11, Windows as well with Chef 12
• ELBs can either be pre-existing or you can create a new one from the EC2 console
• Add an EC2 instance to your layer (so the resource that runs your layer), select the appropriate instance type
• Choose storage type – depending on the type of instance, it may only be possible to choose EBS backed rather than Instance Store
• OpsWorks security groups are not deleted by default

3.2 Demonstrate ability to implement the right architecture for development, testing, and staging environments

• CloudFormation can be used to provision an entire infrastructure such as VPCs, ELBs, EC2 instances, S3 buckets, Route53
• Elastic Beanstalk provides a pre-built web application deployment environment so a developer can upload a web app and deploy it quickly without needing console access to the instances. Examples include Apache, PHP, .NET
• Elastic Beanstalk is designed to support multiple concurrent environments such as test/dev, staging and production
• Elastic Beanstalk is multi-AZ fault tolerant but not multi-region fault tolerant
• Elastic Beanstalk can provision RDS instances, VPCs and also uses IAM
• Elastic Beanstalk code is stored in S3, so can be replicated across regions and encrypted at rest. 11 9’s reliability
• EB changes can be rolled back using version management
• OpsWorks uses Chef to provision stacks and layers – provisions EC2 instances
• Opsworks uses layers and stacks, layers go inside stacks and represent each dependency in the stack, such as ELB and application or RDS layer
• OpsWorks can re-use existing EC2 instances, ELBs, VPCs
• OpsWorks can perform auto-scaling on time of day or average CPU load

3.3 Position and select most appropriate AWS deployment mechanism based on scenario

• Use case for CloudFormation is an entire infrastructure with many AWS components
• CloudFormation itself is free, you just pay for EC2 instances, elastic IP addresses etc
• Elastic Beanstalk provides quick pre-built application environments for developers to upload their code and can support concurrent test/dev, staging and production
• Elastic Beanstalk is free, you pay for EC2 instances, S3 buckets etc
• OpsWorks can leverage Chef to provision an application environment using EC2 instances and then pull updates from code repositories. It can auto scale and is free, you only pay for instances used
• Chef, Puppet and bootstrap are supported deployment methods for CloudFormation, whereas OpsWorks uses only Chef
• AWS Config is used to take a JSON snapshot of current services configuration and apply it as a configuration baseline (think of PowerShell DSC on Azure). Helps notify admins on configuration drift
  • Configure which resource types you want to record (not all are supported)
  • Select an S3 bucket in which to store the configuration snapshots (can be current account or linked account)
  • IAM is used to get read only access to resources and then output to S3
  • SNS can be used to send event notifications
  • Can see relationships with other resources such as EC2 instance, EBS volume, S3 bucket, etc.
  • Takes regular config snapshots that can be used for compliance, auditing and troubleshooting purposes