AWS RDS Aurora – Certification

AWS Aurora

  • AWS Aurora is a relational database engine that combines the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases.
  • Amazon Aurora (Aurora) is a fully managed, MySQL- and PostgreSQL-compatible, relational database engine i.e. applications developed with MySQL can switch to Aurora with little or no changes
  • Aurora delivers up to 5x performance of MySQL without requiring any changes to most MySQL applications
  • Aurora PostgreSQL delivers up to 3x performance of PostgreSQL.
  • RDS manages the Aurora databases, handling time-consuming tasks such as provisioning, patching, backup, recovery, failure detection and repair.
  • Based on the database usage, Aurora storage will automatically grow, from 10GB to 64TB in 10GB increments with no impact to database performance

NOTE – AWS Aurora is covered in the latest Solution Architect – Associate Feb 2018 extensively, so be sure to cover the same.

AWS Aurora Architecture

High Availability and Replication

  • Aurora provides data durability and reliability by replicating the database volume six ways across three Availability Zones in a single region
    • Aurora automatically divides the database volume into 10GB segments spread across many disks.
    • Each 10GB chunk of your database volume is replicated six ways, across three Availability Zones
  • RDS databases for e.g. MySQL, Oracle etc. have the data in a single AZ
  • Aurora is designed to transparently handle the loss of up to two copies of data without affecting database write availability and up to three copies without affecting read availability.
  • Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically.
  • Aurora Replicas share the same underlying volume as the primary instance. Updates made by the primary are visible to all Aurora Replicas
  • As Aurora Replicas share the same data volume as the primary instance, there is virtually no replication lag
  • Any Aurora Replica can be promoted to become primary without any data loss and therefore can be used for enhancing fault tolerance in the event of a primary DB Instance failure.
  • To increase database availability, 1 to 15 replicas can be created in any of 3 AZs, and RDS will automatically include them in failover primary selection in the event of a database outage.


  • Aurora uses SSL (AES-256) to secure the connection between the database instance and the application
  • Aurora allows database encryption using keys managed through AWS Key Management Service (KMS).
  • Encryption and decryption are handled seamlessly.
  • With Aurora encryption, data stored at rest in the underlying storage is encrypted, as are its automated backups, snapshots, and replicas in the same cluster.
  • Encryption of existing unencrypted Aurora instance is not supported. Create a new encrypted Aurora instance and migrate the data

Backup and Restore

  • Automated backups are always enabled on Aurora DB Instances.
  • Backups do not impact database performance.
  • Aurora also allows creation of manual snapshots
  • Aurora automatically maintains 6 copies of your data across 3 AZs and will automatically attempt to recover your database in a healthy AZ with no data loss.
  • If in any case the data is unavailable within Aurora storage,
    • DB Snapshot can be restored or
    • point-in-time restore operation can be performed to a new instance. Latest restorable time for a point-in-time restore operation can be up to 5 minutes in the past.
  • Restoring a snapshot creates a new Aurora DB instance
  • Deleting Aurora database deletes all the automated backups (with an option to create a final snapshot), but would not remove the manual snapshots.
  • Snapshots (including encrypted ones) can be shared with another AWS accounts

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Company wants to use MySQL compatible relational database with greater performance. Which AWS service can be used?
    1. Aurora
    2. RDS
    3. SimpleDB
    4. DynamoDB
  2. An application requires a highly available relational database with an initial storage capacity of 8 TB. The database will grow by 8 GB every day. To support expected traffic, at least eight read replicas will be required to handle database reads. Which option will meet these requirements?
    1. DynamoDB
    2. Amazon S3
    3. Amazon Aurora
    4. Amazon Redshift
  3. A company is migrating their on-premise 10TB MySQL database to AWS. As a compliance requirement, the company wants to have the data replicated across three availability zones. Which Amazon RDS engine meets the above business requirement?
    1. Use Multi-AZ RDS
    2. Use RDS
    3. Use Aurora
    4. Use DynamoDB

AWS X-Ray – Certification


  • AWS X-Ray helps developers analyze and debug production, distributed applications for e.g. built using a microservices lambda architecture
  • X-Ray provides an end-to-end view of requests as they travel through the application, and shows a map of the application’s underlying components.
  • X-Ray helps to understand how the application and its underlying services are performing to identify and troubleshoot the root cause of performance issues and errors.
  • X-Ray to analyze both applications in development and in production, from simple three-tier applications to complex microservices applications consisting of thousands of services.
  • X-Ray can be used with distributed applications of any size to trace and debug both synchronous requests and asynchronous events.
  • X-Ray can be used to track requests flowing through applications or services across multiple regions. X-Ray data is stored locally to the processed region and customers can build a solution over it to combined the data
  • Trace data sent to X-Ray is generally available for retrieval and filtering within 30 seconds of it being received by the service.
  • X-Ray stores trace data for the last 30 days. This enables you to query trace data going back 30 days.
  • Integration
    • X-Ray integrates with applications running on EC2, ECS, Lambda, and Elastic Beanstalk.
    • X-Ray SDK automatically captures metadata for API calls made to AWS services using the AWS SDK
    • X-Ray SDK provides add-ons for MySQL and PostgreSQL drivers.
    • For Elastic Beanstalk, include the language-specific X-Ray libraries in your application code.
    • Applications running on other AWS services, such as EC2 or ECS, install the X-Ray agent and instrument the application code

X-Ray Core Concepts

  • Trace
    • An X-Ray trace is a set of data points that share the same trace ID.
    • Trace helps track the request, which is assigned a unique trace id, while it navigates through services
    • Piece of information relayed by each service in the application to X-Ray is a segment, and a trace is a collection of segments.
  • Segment
    • An X-Ray segment encapsulates all the data points for a single component of the distributed application for e.g. authorization component
    • Segments include system-defined and user-defined data in the form of annotations and are composed of one or more sub-segments that represent remote calls made from the service.  for e.g. database call and its result within the overall request/response
  • Annotation
    • An X-Ray annotation is system-defined or user-defined data
    • Annotation is associated with a segment and a segment can contain multiple annotations.
    • System-defined annotations include data added to the segment by AWS services
    • User-defined annotations are metadata added to a segment by a developer
  • Errors
    • X-Ray errors are system annotations associated with a segment for a call that results in an error response.
    • Error includes the error message, stack trace, and any additional information for e.g, version to associate the error with a source file.
  • Sampling
    • X-Ray collects data for significant number of requests, instead of each request sent to an application, for performant and cost-effectiveness
    • X-Ray should not be used as an audit or compliance tool because it does not guarantee data completeness.
  • X-Ray agent
    • X-Ray agent helps collect data from log files and sends them to the X-Ray service for aggregation, analysis, and storage.
    • Agent makes it easier for you to send data to the X-Ray service, instead of using the APIs directly, and is
    • Agent is available for Amazon Linux AMI, Red Hat Enterprise Linux (RHEL), and Windows Server 2012 R2 or later operating systems.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company is facing performance issues with their microservices architecture deployed on AWS. Which service can help them debug and analyze the issue? [CCP]
    1. AWS Inspector
    2. CodeDeploy
    3. X-Ray
    4. AWS Config

AWS DynamoDB Advanced – Certification

AWS DynamoDB Advanced Features

This post covers DynamoDB advanced features

DynamoDB Secondary Indexes

DynamoDB supports Local and Global Secondary Indexes.

Refer to My Blog Post about AWS DynamoDB Secondary Indexes

DynamoDB Cross-region Replication

  • DynamoDB cross-region replication allows identical copies (called replicas) of a DynamoDB table (called master table) to be maintained in one or more AWS regions
  • Writes to the table will be automatically propagated to all replicas
  • Cross-region replication currently supports single master mode. A single master has one master table and one or more replica tables
  • Read replicas are updated asynchronously as DynamoDB acknowledges a write operation as successful once it has been accepted by the master table. The write will then be propagated to each replica with a slight delay.
  • Cross-region replication can be helpful in scenarios
    • Efficient disaster recovery, in case a data center failure occurs.
    • Faster reads, for customers in multiple regions by delivering data faster by reading a DynamoDB table from the closest AWS data center.
    • Easier traffic management, to distribute the read workload across tables and thereby consume less read capacity in the master table.
    • Easy regional migration, by promoting a read replica to master
    • Live data migration, to replicate data and when the tables are in sync, switch the application to write to the destination region
  • Cross-region replication costing depends on
    • Provisioned throughput (Writes and Reads)
    • Storage for the replica tables.
    • Data Transfer across regions
    • Reading data from DynamoDB Streams to keep the tables in sync.
    • Cost of EC2 instances provisioned, depending upon the instance types and region, to host the replication process.
  • NOTE : Cross Region replication on DynamoDB was performed defining AWS Data Pipeline job which used EMR internally to transfer data before the DynamoDB streams and out of box cross region replication support

DynamoDB Global Tables

  • DynamoDB Global Tables is a new multi-master, cross-region replication capability of DynamoDB to support data access locality and regional fault tolerance for database workloads.
  • Applications can now perform reads and writes to DynamoDB in AWS regions around the world, with changes in any region propagated to every region where a table is replicated.
  • Global Tables help in building applications to advantage of data locality to reduce overall latency.
  • Global Tables ensures eventual consistency
  • Global Tables replicates data among regions within a single AWS account, and currently does not support cross account access

DynamoDB Streams

  • DynamoDB Streams provides a time-ordered sequence of item-level changes made to data in a table in the last 24 hours, after which they are erased
  • DynamoDB Streams maintains ordered sequence of the events per item however across item are not maintained
  • Example
    • For e.g., suppose that you have a DynamoDB table tracking high scores for a game and that each item in the table represents an individual player. If you make the following three updates in this order:
      • Update 1: Change Player 1’s high score to 100 points
      • Update 2: Change Player 2’s high score to 50 points
      • Update 3: Change Player 1’s high score to 125 points
    • DynamoDB Streams will maintain the order for Player 1 score events. However, it would not maintain the order across the players. So Player 2 score event is not guaranteed between the 2 Player 1 events
  • DynamoDB streams can be used for multi-region replication to keep other data stores up-to-date with the latest changes to DynamoDB or to take actions based on the changes made to the table
  • DynamoDB Streams APIs helps developers consume updates and receive the item-level data before and after items are changed
  • DynamoDB Streams allows read at up to twice the rate of the provisioned write capacity of the DynamoDB table
  • DynamoDB Streams have to be enabled on a per-table basis
  • DynamoDB Streams is designed so that every update made to the table will be represented exactly once in the stream
  • DynamoDB Streams is designed so that every update made to the table will be represented exactly once in the stream. No Duplicates

DynamoDB Triggers

  • DynamoDB Triggers (just like database triggers) is a feature which allows execution of custom actions based on item-level updates on a table
  • DynamoDB triggers can be used in scenarios like sending notifications, updating an aggregate table, and connecting DynamoDB tables to other data sources
  • DynamoDB Trigger flow
    • Custom logic for a DynamoDB trigger is stored in an AWS Lambda function as code.
    • A trigger for a given table can be created by associating an AWS Lambda function to the stream (via DynamoDB Streams) on a table.
    • When the table is updated, the updates are published to DynamoDB Streams.
    • In turn, AWS Lambda reads the updates from the associated stream and executes the code in the function.

DynamoDB Accelerator DAX

  • DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for DynamoDB that delivers up to a 10x performance improvement – from milliseconds to microseconds – even at millions of requests per second.
  • DAX does all the heavy lifting required to add in-memory acceleration to the tables, without requiring developers to manage cache invalidation, data population, or cluster management.
  • DAX is fault-tolerant and scalable.
  • DAX cluster has a primary node and zero or more read-replica nodes. Upon a failure for a primary node, DAX will automatically fail over and elect a new primary. For scaling, add or remove read replicas

VPC Endpoints

  • VPC endpoints for DynamoDB improve privacy and security, especially those dealing with sensitive workloads with compliance and audit requirements, by enabling private access to DynamoDB from within a VPC without the need for an internet gateway or NAT gateway.
  • VPC endpoints for DynamoDB support IAM policies to simplify DynamoDB access control, where access can be restricted to a specific VPC endpoint.
  • VPC endpoints can be created only for Amazon DynamoDB tables in the same AWS Region as the VPC
  • DynamoDB Streams cannot be access using VPC endpoints for DynamoDB

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. What are the services supported by VPC endpoints, using Gateway endpoint type? Choose 2 answers
    1. Amazon S3
    2. Amazon EFS
    3. Amazon DynamoDB
    4. Amazon Glacier
    5. Amazon SQS
  2. A company has setup an application in AWS that interacts with DynamoDB. DynamoDB is currently responding in milliseconds, but the application response guidelines require it to respond within microseconds. How can the performance of DynamoDB be further improved? [SAA-C01]
    1. Use ElastiCache in front of DynamoDB
    2. Use DynamoDB inbuilt caching
    3. Use DynamoDB Accelerator
    4. Use RDS with ElastiCache instead

AWS ELB Network Load Balancer – Certification

AWS ELB Network Load Balancer

  • Network Load Balancer operates at the connection level (Layer 4), routing connections to targets – EC2 instances, containers and IP addresses based on IP protocol data.
  • Network Load Balancer is suited for load balancing of TCP traffic
  • Network Load Balancer is capable of handling millions of requests per second while maintaining ultra-low latencies.
  • Network Load Balancer is optimized to handle sudden and volatile traffic patterns while using a single static IP address per Availability Zone.
  • NLB is integrated with other AWS services such as Auto Scaling, EC2 Container Service (ECS), and CloudFormation.

Network Load Balancer Features

Connection-based Load Balancing

  • Allows load balancing of  TCP traffic, routing connections to targets – EC2 instances, microservices and containers, and IP addresses.

High Availability

  • is highly available.
  • accepts incoming traffic from clients and distributes this traffic across the targets within the same Availability Zone.
  • monitors the health of its registered targets and routes the traffic only to healthy targets
  • if a health check fails and an unhealthy target is detected, it stops routing traffic to that target and reroutes traffic to remaining healthy targets.
  • if configured with multiple AZs and if all the targets in a single AZ fail, it routes traffic to healthy targets in the other AZs

High Throughput

  • is designed to handle traffic as it grows and can load balance millions of requests/sec.
  • can also handle sudden volatile traffic patterns.

Low Latency

  • offers extremely low latencies for latency-sensitive applications.

Preserve source IP address

  • preserves client side source IP allowing the back-end to see client IP address

Static IP support

  • automatically provides a static IP per Availability Zone (subnet) that can be used by applications as the front-end IP of the load balancer.

Elastic IP support

  • an Elastic IP per Availability Zone (subnet) can also be assigned, optionally, thereby providing a fixed IP.

Health Checks

  • supports both network and application target health checks.
  • Network-level health check
    • is based on the overall response of the underlying target (instance or a container) to normal traffic.
    • target is marked unavailable if it is slow or unable to respond to new connection requests
  • Application-level health check
    • is based on a specific URL on a given target to test the application health deeper

DNS Fail-over

  • integrates with Route 53
  • Route 53 will direct traffic to load balancer nodes in other AZs, if there are no healthy targets with NLB or if the NLB itself is unhealthy
  • if NLB is unresponsive, Route 53 will remove the unavailable load balancer IP address from service and direct traffic to an alternate Network Load Balancer in another region.

Integration with AWS Services

  • is integrated with other AWS services such as Auto Scaling, EC2 Container Service (ECS), CloudFormation, CodeDeploy, and AWS Config.

Long-lived TCP Connections

  • supports long-lived TCP connections ideal for WebSocket type of applications

Central API Support

  • uses the same API as Application Load Balancer.
  • enables you to work with target groups, health checks, and load balance across multiple ports on the same EC2 instance to support containerized applications.

Robust Monitoring and Auditing

  • integrated with CloudWatch to report Network Load Balancer metrics.
  • CloudWatch provides metrics such as Active Flow count, Healthy Host Count, New Flow Count, Processed bytes, and more.
  • integrated with CloudTrail to track API calls to the NLB

Enhanced Logging

  • use the Flow Logs feature to record all requests sent to the load balancer.
  • Flow Logs capture information about the IP traffic going to and from network interfaces in the VPC
  • Flow log data is stored using CloudWatch Logs

Zonal Isolation

  • is designed for application architectures in a single zone.
  • can be enabled in a single AZ to support architectures that require zonal isolation
  • automatically fails-over to other healthy AZs, if something fails in a AZ
  • its recommended to configure the load balancer and targets in multiple AZs for achieving high availability

Load Balancing using IP addresses as Targets

  • allows load balancing of any application hosted in AWS or on-premises using IP addresses of the application backends as targets.
  • allows load balancing to an application backend hosted on any IP address and any interface on an instance.
  • ability to load balance across AWS and on-premises resources helps migrate-to-cloud, burst-to-cloud or failover-to-cloud
  • applications hosted in on-premises locations can be used as targets over a Direct Connect connection and EC2-Classic (using ClassicLink).

Advantages over Classic Load Balancer

  • Ability to handle volatile workloads and scale to millions of requests per second, without the need of pre-warming
  • Support for static IP/Elastic IP addresses for the load balancer
  • Support for registering targets by IP address, including targets outside the VPC (on-premises) for the load balancer.
  • Support for routing requests to multiple applications on a single EC2 instance. Single instance or IP address can be registered with the same target group using multiple ports.
  • Support for containerized applications. Using Dynamic port mapping, ECS can select an unused port when scheduling a task and register the task with a target group using this port.
  • Support for monitoring the health of each service independently, as health checks are defined at the target group level and many CloudWatch metrics are reported at the target group level. Attaching a target group to an Auto Scaling group enables scaling each service dynamically based on demand

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.



AWS Organizations – Certification

AWS Organizations

  • AWS Organizations is an account management service that enables consolidating multiple AWS accounts into an organization that can be created and centrally managed.
  • AWS Organizations includes consolidated billing and account management capabilities that enable one to better meet the budgetary, security, and compliance needs of your business.
  • As an administrator of an organization, new accounts can be created in an organization and invite existing accounts to join the organization.
  • AWS Organizations enables you to
    • Centrally manage policies across multiple AWS accounts
    • Control access to AWS services
    • Automate AWS account creation and management
    • Consolidate billing across multiple AWS accounts

AWS Organizations

AWS Organization Features

Centralized management of all of your AWS accounts

  • Combine existing accounts into or create new ones within an organization that enables them to be managed centrally
  • Policies can be attached to accounts that affect some or all of the accounts

Consolidated billing for all member accounts

  • Consolidated billing is a feature of AWS Organizations.
  • Master account of the organization can be used to consolidate and pay for all member accounts.

Hierarchical grouping of accounts to meet budgetary, security, or compliance needs

  • Accounts can be grouped into organizational units (OUs) and each OU can be attached different access policies.
  • OUs can also be nested to a depth of five levels, providing flexibility in how you structure your account groups.

Control over AWS services and API actions that each account can access

  • As an administrator of the master account of an organization, access to users and roles in each member account can be restricted to which AWS services and individual API actions
  • Organization permissions overrule account permissions.
  • This restriction even overrides the administrators of member accounts in the organization.
  • When AWS Organizations blocks access to a service or API action for a member account, a user or role in that account can’t access any prohibited service or API action, even if an administrator of a member account explicitly grants such permissions in an IAM policy.

Integration and support for AWS IAM

  • IAM provides granular control over users and roles in individual accounts.
  • AWS Organizations expands that control to account level by giving control over what users and roles in an account or a group of accounts can do
  • User can access only what is allowed by both the AWS Organizations policies and IAM policies.
  • Resulting permissions are the logical intersection of what is allowed by AWS Organizations at the account level, and what permissions are explicitly granted by IAM at the user or role level within that account.
  • If either blocks an operation, the user can’t access that operation.

Integration with other AWS services

  • Select AWS services can be enabled to access accounts in the organization and perform actions on the resources in the accounts.
  • When another service is configured and authorized to access with the organization, AWS Organizations creates an IAM service-linked role for that service in each member account.
  • Service-linked role has predefined IAM permissions that allow the other AWS service to perform specific tasks in the organization and its accounts
  • All accounts in an organization automatically have a service-linked role created, which enables the AWS Organizations service to create the service-linked roles required by AWS services for which you enable trusted access
  • These additional service-linked roles come with policies that enable the specified service to perform only those required tasks

Data replication that is eventually consistent

    • AWS Organizations is eventually consistent.
    • AWS Organizations achieves high availability by replicating data across multiple servers in AWS data centers within its region.
    • If a request to change some data is successful, the change is committed and safely stored.
    • However, the change must then be replicated across the multiple servers.

AWS Organizations Terminology and Concepts

AWS Organizations Concepts


  • An entity created to consolidate AWS accounts.
  • An organization has one master account along with zero or more member accounts.
  • An organization has the functionality that is determined by the feature set that you enable i.e. All features or Consolidated Billing only


  • Parent container for all the accounts for the organization.
  • Policy applied to the root is applied to all the organizational units (OUs) and accounts in the organization.
  • There can be only one root currently and AWS Organization automatically creates it when an organization is created

Organization unit (OU)

  • A container for accounts within a root.
  • An OU also can contain other OUs, enabling hierarchy creation that resembles an upside-down tree, with a root at the top and branches of OUs that reach down, ending in accounts that are the leaves of the tree.
  • A policy attached to one of the nodes in the hierarchy, flows down and affects all branches (OUs) and leaves (accounts) beneath it
  • An OU can have exactly one parent, and currently each account can be a member of exactly one OU.


  • A standard AWS account that contains AWS resources.
  • Each account can be directly in the root, or placed in one of the OUs in the hierarchy.
  • Policy can be attached to an account to apply controls to only that one account.
  • Accounts can be organized in a hierarchical, tree-like structure with a root at the top and organizational units nested under the root.
  • Master account
    • Primary account which creates the organization
    • can create new accounts in the organization, invite existing accounts, remove accounts, manage invitations, apply policies to entities within the organization.
    • has the responsibilities of a payer account and is responsible for paying all charges that are accrued by the member accounts.
  • Member account
    • Rest of the accounts within the organization are member accounts.
    • An account can be a member of only one organization at a time.


  • Process of asking another account to join an organization.
  • An invitation can be issued only by the organization’s master account and is extended to either the account ID or the email address that is associated with the invited account.
  • Invited account becomes a member account in the organization, after it accepts the invitation.
  • Invitations can be sent to existing member accounts as well, to approve the change from supporting only consolidated billing feature to supporting all features
  • Invitations work by accounts exchanging handshakes.


  • A multi-step process of exchanging information between two parties
  • Primary use in AWS Organizations is to serve as the underlying implementation for invitations.
  • Handshake messages are passed between and responded to by the handshake initiator (master account) and the recipient (member account) in such a way that it ensures that both parties always know what the current status is.

Available feature sets

Consolidated billing

  • provides shared billing functionality

All features

  • includes all the functionality of consolidated billing,
  • includes advanced features that gives more control over accounts in the organization.
  • allows master account to have full control over what member accounts can do
  • master account can apply SCPs to restrict the services and actions that users (including the root user) and roles in an account can access, and it can prevent member accounts from leaving the organization.

Service control policy (SCP)

  • Service control policy specifies the services and actions that users and roles can use in the accounts that the SCP affects.
  • SCPs are similar to IAM permission policies except that they don’t grant any permissions.
  • SCPs are filters that allow only the specified services and actions to be used in affected accounts.
  • SCPs override IAM permission policy. So even if a user is granted full administrator permissions with an IAM permission policy, any access that is not explicitly allowed or that is explicitly denied by the SCPs affecting that account is blocked.
  • For e.g., if you assign an SCP that allows only database service access to your “database” account, then any user, group, or role in that account is denied access to any other service’s operations.
  • SCP can be attached to
    • A root, which affects all accounts in the organization
    • An OU, which affects all accounts in that OU and all accounts in any OUs in that OU subtree
    • An individual account
  • Master account of the organization is not affected by any SCPs that are attached either to it or to any root or OU the master account might be in.

Whitelisting vs. blacklisting

Whitelisting and blacklisting are complementary techniques used to apply SCPs to filter the permissions available to accounts.


  • Explicitly specify the access that is allowed.
  • All other access is implicitly blocked.
  • By default, all permissions are whitelisted.
  • AWS Organizations attaches an AWS managed policy called FullAWSAccess to all roots, OUs, and accounts, which ensures building of the organizations.
  • For restricting permissions, replace the FullAWSAccess policy with one that allows only the more limited, desired set of permissions.
  • Users and roles in the affected accounts can then exercise only that level of access, even if their IAM policies allow all actions.
  • If you replace the default policy on the root, all accounts in the organization are affected by the restrictions.
  • You can’t add them back at a lower level in the hierarchy because an SCP never grants permissions; it only filters them.


  • Default behavior of AWS Organizations.
  • Explicitly specify the access that is not allowed.
  • Explicit deny of a service action overrides any allow of that action.
  • All other permissions are allowed unless explicitly blocked
  • By default, AWS Organizations attaches an AWS managed policy called FullAWSAccess to all roots, OUs, and accounts. This allows any account to access any service or operation with no AWS Organizations–imposed restrictions.
  • With blacklisting, additional policies are attached that explicitly deny access to the unwanted services and actions

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. An organization that is currently using consolidated billing has recently acquired another company that already has a number of AWS accounts. How could an Administrator ensure that all AWS accounts, from both the existing company and the acquired company, are billed to a single account?
    1. Merge the two companies, AWS accounts by going to the AWS console and selecting the “Merge accounts” option.
    2. Invite the acquired company’s AWS account to join the existing company’s organization using AWS Organizations.
    3. Migrate all AWS resources from the acquired company’s AWS account to the master payer account of the existing company.
    4. Create a new AWS account and set it up as the master payer. Move the AWS resources from both the existing and acquired companies’ AWS accounts to the new account.
  2. Which of the following are the benefits of AWS Organizations? Choose the 2 correct answers:
    1. Centrally manage access polices across multiple AWS accounts.
    2. Automate AWS account creation and management.
    3. Analyze cost across all multiple AWS accounts.
    4. Provide technical help (by AWS) for issues in your AWS account.
  3. A company has several departments with separate AWS accounts. Which feature would allow the company to enable consolidate billing?
    1. AWS Inspector
    2. AWS Shield
    3. AWS Organizations
    4. AWS Lightsail





Amazon EMR Best Practices

Best Practices for Using Amazon EMR

Amazon has made working with Hadoop a lot easier. You can launch an EMR cluster in minutes for big data processing, machine learning, and real-time stream processing with the Apache Hadoop ecosystem. You can use the Management Console or the command line to start several nodes with ease.

The EMR pricing has now changed from pay-per-hour to pay-per-second, which results in lower costs and you no longer have to worry about the hourly boundary.

EMR makes a whole bunch of the latest versions of open source software available to you. Currently, there are 19 open source projects and new releases are made every 4 to 6 weeks, so the latest versions of the open source projects are available. This is very useful, especially for rapidly evolving open source projects such as Apache Spark where each release contains critical bug fixes and features. However, you are not forced to upgrade; a new release is made available if you choose to use it. With EMR, you can spin up a bunch of instances and you could process massive volumes of data residing on S3 at a reasonable cost.

A variety of cluster management options are supported, including YARN. You can run the following:

  • HBase
  • Presto (low latency, distributed SQL engine)
  • Spark
  • Tez
  • ganglia
  • Zeppellin
  • Notebooks
  • SQL editors

AWS Connectors

Additionally, connectors to different AWS services are also available; for example, you can use Spark to load Redshift (using the Redshift connector, which Redshift commands under the hood to get a good throughput). You can access DynamoDB for analytics applications, Sqoop to access relational data, and so on.

AWS Glue

One particularly interesting connector is AWS Glue. AWS Glue comprises three main components:

AWS Glue

  • ETL service: This lets you drag things around to create serverless ETL pipelines.
  • AWS Glue Data Catalog: This is a fully managed Hive metastore-compliant service. Earlier, the systems ran an external Hive metastore database in RDS or Aurora. This was great. If you shut down your cluster, all your metadata was persisted so you didn’t have to recreate your tables with extra durability and availability (in case something happened to your metastore with MySQL on the master node). With Glue, all that is fully managed. You have an intelligent metastore—you don’t have to write DDL to create a table; you can just make Glue crawl your data, infer what the schema is, and create those tables for you. You can also make it add partitions, which can be painful otherwise—if you are constantly updating your Hive tables, you need a process to load that partition in—Glue catalog can do it for you. It also supports a variety of complex data types.
  • Crawlers: The crawlers let you crawl the data to infer the schema.

AWS Glue is a managed service, so you spend less time monitoring. As a fully managed service, it is also responsible for replacing unhealthy nodes and autoscaling. Enabling security options in AWS Glue is pretty easy. It supports full customization and control, and you don’t have to waste time creating and configuring the cluster. In most cases, the default settings are good enough, but even if you wanted to change them or install custom components, you have root access over all the boxes, so you can make any changes you need.

Common EMR use cases


Using HBase for random access at a massive scale involves a lot of customers who are running HBase with HDFS. Now there is support for HBase using S3 object store for HFiles. Also, there is the ability to use the Read Replica HBase cluster in another AZ. Shifting to S3 can save you 50% or higher on storage costs. Instead of sizing the cluster for HDFS, they can now size it for the amount of processing power required for the HBase Region Servers. The S3 option is also good for load balancing and disaster recovery across AZs. As S3 is available across a region, you don’t have to replicate the data twice; that is, you don’t need two full HDFS clusters. Now you can set up a smaller cluster for the Read Replicas that point to the same HFiles and you can drive the read traffic through there.

Real-time and batch processing involves utilizing EMR; you can use Kinesis for pushing data to Spark. Use Spark Streaming for real-time analytics or processing data on-the-fly and then dump that data into S3. If you don’t have real-time processing use cases, then Kinesis Firehose is a great alternative too. The data can be cataloged in the Glue Data Catalog and then you can have the data accessible via a variety of different analytical engines. EMR supports several analytical engines including Hive, Tez, and Spark. Once the data is in the Data Catalog on S3, you can use Athena (serverless SQL queries), Glue ETL (serverless ETL), and Redshift Spectrum.

Data exploration with Spark using Zeppelin or Jupyter notebook allows you to arm your data scientists with a way to explore large amounts of data (instead of using one node, you can now spread the data across the cluster). This also makes it easier to move it to production.

There is a big rise in the use of Presto for ad hoc SQL queries (in combination with Athena). They approach the same thing from two different angles. Presto gives you advanced configurations and a way to build exactly what you need for your use case but you have to deal with the cluster management versus Athena where you just go to the console and start writing SQL. Now, many BI tools support Presto as well for supporting low latency dashboards. You can also perform traditional batch processing workloads using Spark.

Deep learning with GPU instances is where you can launch GPU hardware for EMR. There’s support for MxNet. You can do end-to-end data engineering work. Support for TensorFlow is coming.

Typical ML projects implement a multi-step process, including ETL, feature engineering, model training, model evaluation, model deployment, and model scoring and updates. Such pipelines need to support batch model training and real-time ML model serving. Using Apache Spark for implementing ML pipelines is very popular as it supports each step in an ML pipeline, scales for small and large jobs, good ML libraries, and has an active user base.

There are several options for deploying Spark on AWS. For example, you can use EC2 as it can support for batch/streaming, integrates with tooling, spin up/down clusters, larger/smaller clusters. Additionally, it also has support for different versions of Hadoop and Spark. However, using EC2 for Spark deployment places a huge management burden on us. Hence, EMR can be a simpler and better alternative here. It is simple to provision and you can use a wizard (and then generate the commands for the command line from it if required). You can create tags for cost management and send logs to S3.

Lowering EMR costs

If you are paying for Hadoop nodes that are not doing anything, then you are just burning money. There are ways you can batch up your workloads. Take an inventory of the jobs you have and tweak them to run in a batch mode and shutdown the cluster in-between those times. You can separate out clusters with auto-scaling instead of sizing and running it for all your workloads. You should shut down the cluster when you can, to stop paying for it unnecessarily. You can use Amazon Linux AMI with preinstalled customizations for faster cluster creation and use auto-scaling to minimize costs for long-running clusters.

AWS Auto Scaling Lifecycle – Certification

Auto Scaling Lifecycle

  • Instances launched through Auto Scaling group have a a different lifecycle then that of other EC2 instances
  • Auto Scaling lifecycle starts when the Auto Scaling group launches an instance and puts it into service.
  • Auto Scaling lifecycle ends when the instance is terminated either by the user , or the Auto Scaling group takes it out of service and terminates it
  • AWS charges for the instances as soon as they are launched, including the time it is not in InService

Auto Scaling Lifecycle Transition

Auto Scaling Group Lifecycle

Auto Scaling Lifecycle Hooks

  • Auto Scaling Lifecycle hooks enable you to perform custom actions by pausing instances as an Auto Scaling group launches or terminates them
  • Each Auto Scaling group can have multiple lifecycle hooks. However, there is a limit on the number of hooks per Auto Scaling group
  • Auto Scaling scale out event flow
    • Instances start in the Pending state
    • If an autoscaling:EC2_INSTANCE_LAUNCHING lifecycle hook is added, the state is moved to Pending:Wait
    • After the lifecycle action is completed, instances enter to Pending:Proceed
    • When the instances are fully configured, they are attached to the Auto Scaling group and moved to the InService state
  • Auto Scaling scale in event flow
    • Instances are detached from the Auto Scaling group and enter the Terminating state.
    • If an autoscaling:EC2_INSTANCE_TERMINATING lifecycle hook is added, the state is moved to Terminating:Wait
    • After the lifecycle action is completed, the instances enter the Terminating:Proceed state.
    • When the instances are fully terminated, they enter the Terminated state.
  • During the scale out and scale in events, instances are put into a wait state  (Pending:Wait or Terminating:Wait) and is paused until either a continue action happens or the timeout period ends.
  • By default, the instance remains in a wait state for one hour, which can be extended by restarting the timeout period by recoding a heartbeat. If the task finishes before the timeout period ends, the lifecycle action can be marked completed and it continues the launch or termination process.
  • After the wait period the Auto Scaling group continues the launch or terminate process (Pending:Proceed or Terminating:Proceed)
    • CloudWatch Events target to invoke a Lambda function when a lifecycle action occurs. Event contains information about the instance that is launching or terminating, and a token that can be used to control the lifecycle action.
    • Notification target (CloudWatch events, SNS, SQS) for the lifecycle hook which receives the message from EC2 Auto Scaling.The message contains information about the instance that is launching or terminating, and a token that you can use to control the lifecycle action.
    • Create a script that runs on the instance as the instance starts. The script can control the lifecycle action using the ID of the instance on which it runs.Custom action can be implemented using

Auto Scaling Lifecycle Hooks Considerations

  • Keeping Instances in a Wait State
    • Instances remain in a wait state for a finite period of time. Default being 1 hour (3600 seconds) with max being 48 hours or 100 times the heartbeat timeout, whichever is smaller.
    • Time can be adjusted using
      • complete-lifecycle-action (CompleteLifecycleAction) command to continue to the next state if finishes before the timeout period ends
      • put-lifecycle-hook command, the –heartbeat-timeout parameter to set the heartbeat timeout for the lifecycle hook during its creation
      • Restart the timeout period by recording a heartbeat, using the record-lifecycle-action-heartbeat (RecordLifecycleActionHeartbeat) command
  • Cooldowns and Custom Actions
    • Cooldown period helps ensure that the Auto Scaling group does not launch or terminate more instances than needed
    • Cooldown period starts when the instance enters the InService state. Any suspended scaling actions resume after cooldown period expires
  • Health Check Grace Period
    • Health check grace period does not start until the lifecycle hook completes and the instance enters the InService state
  • Lifecycle Action Result
    • Result of lifecycle hook is either ABANDON or CONTINUE
    • If the instance is launching,
      • CONTINUE indicates a successful action, and the instance can be put into service.
      • ABANDON indicates the custom actions were unsuccessful, and that the instance can be terminated.
    • If the instance is terminating,
      • ABANDON and CONTINUE allow the instance to terminate.
      • However, ABANDON stops any remaining actions from other lifecycle hooks, while CONTINUE allows them to complete
  • Spot Instances
    • Lifecycle hooks can be used with Spot Instances. However, a lifecycle hook does not prevent an instance from terminating due to a change in the Spot Price, which can happen at any time

Enter and Exit Standby

  • Instance in an InService state can be moved toStandby state.
  • Standby state enables you to remove the instance from service, troubleshoot or make changes to it, and then put it back into service.
  • Instances in a Standby state continue to be managed by the Auto Scaling group. However, they are not an active part of the application until they are put back into service.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your application is running on EC2 in an Auto Scaling group. Bootstrapping is taking 20 minutes to complete. You find out that instances are shown as InService although the bootstrapping has not completed. How can you make sure that new instances are not added until the bootstrapping has finished. Choose the correct answer:
    1. Create a CloudWatch alarm with an SNS topic to send alarms to your DevOps engineer.
    2. Create a lifecycle hook to keep the instance in pending:wait state until the bootstrapping has finished and then put the instance in pending:proceed state.
    3. Increase the number of instances in your Auto Scaling group.
    4. Create a lifecycle hook to keep the instance in standby state until the bootstrapping has finished and then put the instance in pending:proceed state.
  2. When a scale out event occurs, the Auto Scaling group launches the required number of EC2 instances using its assigned launch configuration. What instance state do these instances start in? Choose the correct answer:
    1. pending:wait
    2. InService
    3. Pending
    4. Terminating
  3. With AWS Auto Scaling, once we apply a hook and the action is complete or the default wait state timeout runs out, the state changes to what, depending on which hook we have applied and what the instance is doing? Select two. Choose the 2 correct answers:
    1. pending:proceed
    2. pending:wait
    3. terminating:wait
    4. terminating:proceed
  4. For AWS Auto Scaling, what is the first transition state an existing instance enters after leaving steady state in Standby mode?
    1. Detaching
    2. Terminating:Wait
    3. Pending (You can put any instance that is in an InService state into a Standby state. This enables you to remove the instance from service, troubleshoot or make changes to it, and then put it back into service. Instances in a Standby state continue to be managed by the Auto Scaling group. However, they are not an active part of your application until you put them back into service. Refer link)
    4. EnteringStandby
  5. For AWS Auto Scaling, what is the first transition state an instance enters after leaving steady state when scaling in due to health check failure or decreased load?
    1. Terminating (When Auto Scaling responds to a scale in event, it terminates one or more instances. These instances are detached from the Auto Scaling group and enter the Terminating state. Refer link)
    2. Detaching
    3. Terminating:Wait
    4. EnteringStandby




AWS CloudWatch Logs – Certification

AWS CloudWatch Logs

  • CloudWatch Logs can be used to monitor, store, and access log files from  EC2 instances, CloudTrail, Route 53, and other sources
  • CloudWatch Logs uses the log data for monitoring in an not; so, no code changes are required
  • CloudWatch Logs require CloudWatch logs agent to be installed on the EC2 instances and on-premises servers.
  • CloudWatch Logs agent makes it easy to quickly send both rotated and non-rotated log data off of a host and into the log service.
  • An VPC endpoint can be configured to keep traffic between VPC and CloudWatch Logs from leaving the Amazon network. It doesn’t require an IGW, NAT, VPN connection, or Direct Connect connection
  • CloudWatch Logs allows exporting log data from the log groups to an S3 bucket, which can then be used for custom processing and analysis, or to load onto other systems.
  • Log data is encrypted while in transit and while it is at rest
  • Log data can be encrypted using an AWS KMS or customer master key (CMK).

Required Mainly for SysOps Associate & DevOps Professional Exam

CloudWatch Logs Concepts

Log Events

  • A log event is a record of some activity recorded by the application or resource being monitored.
  • Log event record contains two properties: the timestamp of when the event occurred, and the raw event message

Log Streams

  • A log stream is a sequence of log events that share the same source for e.g. logs events from an Apache access log on a specific host.

Log Groups

  • Log groups define groups of log streams that share the same retention, monitoring, and access control settings for e.g. Apache access logs from each host grouped through log streams into a single log group
  • Each log stream has to belong to one log group
  • There is no limit on the number of log streams that can belong to one log group.

Metric Filters

  • Metric filters can be used to extract metric observations from ingested events and transform them to data points in a CloudWatch metric.
  • Metric filters are assigned to log groups, and all of the filters assigned to a log group are applied to their log streams.

Retention Settings

  • Retention settings can be used to specify how long log events are kept in CloudWatch Logs.
  • Expired log events get deleted automatically.
  • Retention settings are assigned to log groups, and the retention assigned to a log group is applied to their log streams.

CloudWatch Logs Use cases

Monitor Logs from EC2 Instances in Real-time

  • can help monitor applications and systems using log data
  • can help track number of errors for e.g. 404, 500, for even specific literal terms “NullReferenceException”, occurring in the applications, which can then be matched to a threshold to send notification

Monitor AWS CloudTrail Logged Events

  • can be used to monitor particular API activity as captured by CloudTrail by creating alarms in CloudWatch and receive notifications

Archive Log Data

  • can help store the log data in highly durable storage, an alternative to S3
  • log retention setting can be modified, so that any log events older than this setting are automatically deleted.

Log Route 53 DNS Queries

  • can help log information about the DNS queries that Route 53 receives.

Real-time Processing of Log Data with Subscriptions

  • Subscriptions can help get access to real-time feed of logs events from CloudWatch logs and have it delivered to other services such as Kinesis stream, Kinesis Data Firehose stream, or AWS Lambda for custom processing, analysis, or loading to other systems
  • A subscription filter defines the filter pattern to use for filtering which log events get delivered to the AWS resource, as well as information about where to send matching log events to.
  • CloudWatch Logs log group can also be configured to stream data Elasticsearch Service cluster in near real-time

Searching and Filtering

  • CloudWatch Logs allows searching and filtering the log data by creating one or more metric filters.
  • Metric filters define the terms and patterns to look for in log data as it is sent to CloudWatch Logs.
  • CloudWatch Logs uses these metric filters to turn log data into numerical CloudWatch metrics that can be put as graph or set an alarm on.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Once we have our logs in CloudWatch, we can do a number of things such as: Choose 3. Choose the 3 correct answers:[CDOP]
    1. Send the log data to AWS Lambda for custom processing or to load into other systems
    2. Stream the log data to Amazon Kinesis
    3. Stream the log data into Amazon Elasticsearch in near real-time with CloudWatch Logs subscriptions.
    4. Record API calls for your AWS account and delivers log files containing API calls to your Amazon S3 bucket
  2. You have decided to set the threshold for errors on your application to a certain number and once that threshold is reached you need to alert the Senior DevOps engineer. What is the best way to do this? Choose 3. Choose the 3 correct answers: [CDOP]
    1. Set the threshold your application can tolerate in a CloudWatch Logs group and link a CloudWatch alarm on that threshold.
    2. Use CloudWatch Logs agent to send log data from the app to CloudWatch Logs from Amazon EC2 instances
    3. Pipe data from EC2 to the application logs using AWS Data Pipeline and CloudWatch
    4. Once a CloudWatch alarm is triggered, use SNS to notify the Senior DevOps Engineer.
  3. You are hired as the new head of operations for a SaaS company. Your CTO has asked you to make debugging any part of your entire operation simpler and as fast as possible. She complains that she has no idea what is going on in the complex, service-oriented architecture, because the developers just log to disk, and it’s very hard to find errors in logs on so many services. How can you best meet this requirement and satisfy your CTO? [CDOP]
    1. Copy all log files into AWS S3 using a cron job on each instance. Use an S3 Notification Configuration on the <code>PutBucket</code> event and publish events to AWS Lambda. Use the Lambda to analyze logs as soon as they come in and flag issues. (is not fast in search and introduces delay)
    2. Begin using CloudWatch Logs on every service. Stream all Log Groups into S3 objects. Use AWS EMR cluster jobs to perform adhoc MapReduce analysis and write new queries when needed. (is not fast in search and introduces delay)
    3. Copy all log files into AWS S3 using a cron job on each instance. Use an S3 Notification Configuration on the <code>PutBucket</code> event and publish events to AWS Kinesis. Use Apache Spark on AWS EMR to perform at-scale stream processing queries on the log chunks and flag issues. (is not fast in search and introduces delay)
    4. Begin using CloudWatch Logs on every service. Stream all Log Groups into an AWS Elasticsearch Service Domain running Kibana 4 and perform log analysis on a search cluster. (ELK – Elasticsearch, Kibana stack is designed specifically for real-time, ad-hoc log analysis and aggregation)
  4. You use Amazon CloudWatch as your primary monitoring system for your web application. After a recent software deployment, your users are getting Intermittent 500 Internal Server Errors when using the web application. You want to create a CloudWatch alarm, and notify an on-call engineer when these occur. How can you accomplish this using AWS services? (Choose three.) [CDOP]
    1. Deploy your web application as an AWS Elastic Beanstalk application. Use the default Elastic Beanstalk CloudWatch metrics to capture 500 Internal Server Errors. Set a CloudWatch alarm on that metric.
    2. Install a CloudWatch Logs Agent on your servers to stream web application logs to CloudWatch.
    3. Use Amazon Simple Email Service to notify an on-call engineer when a CloudWatch alarm is triggered.
    4. Create a CloudWatch Logs group and define metric filters that capture 500 Internal Server Errors. Set a CloudWatch alarm on that metric.
    5. Use Amazon Simple Notification Service to notify an on-call engineer when a CloudWatch alarm is triggered.
    6. Use AWS Data Pipeline to stream web application logs from your servers to CloudWatch.



AWS Elastic Beanstalk Deployment Strategies – Certification

AWS Elastic Beanstalk Deployment Strategies

  • Elastic Beanstalk supports environments as
    • Single Instance environments, with a single instance and auto scaling to maintain the minimum/maximum 1 instance
    • Load Balanced environments, with load balancing and auto scaling
  • Elastic Beanstalk allows multiple deployment options or strategies that can be selected depending upon the requirements for deployment time, downtime, DNS change and rollback process

NOTE: Advanced Topic required for DevOps Professional Exam Only

Elastic Beanstalk Deployment Methods

Elastic Beanstalk Deployment Methods

All at Once Deployments

  • Elastic Beanstalk environment uses all-at-once deployments if it is created with a different client (API, SDK, or AWS CLI)
  • All at Once deployments performs an in place deployment on all instances at the same time
  • All at Once deployments are simple and fast, however rollback would take time in case of any issues

Rolling Deployments

  • Elastic Beanstalk environment uses rolling deployments if it is created with console or EB CLI
  • Elastic Beanstalk splits the environment’s EC2 instances into batches and deploys the new version of the application to one batch at a time, leaving the rest of the instances in the environment running the old version
  • During a rolling deployment, part of the instances serve requests with the old version of the application, while instances in completed batches serve other requests with the new version.
  • Elastic Beanstalk performs the rolling deployments as
    • When processing a batch, detaches all instances in the batch from the load balancer, deploys the new application version, and then reattaches the instances.
    • To avoid any connection issues when the instances are detached, connection draining can be enabled on the load balancer
    • After reattaching the instances in a batch to the load balancer, ELB waits until they pass a minimum number of health checks (the Healthy check count threshold value), and then starts routing traffic to them.
    • Elastic Beanstalk waits until all instances in a batch are healthy before moving on to the next batch.
    • When all instances in the batch pass enough health checks to be considered healthy by ELB, the batch is complete.
    • If a batch of instances does not become healthy within the command timeout, the deployment fails.
    • If a deployment fails after one or more batches completed successfully, the completed batches run the new version of the application while any pending batches continue to run the old version.
    • If the instances are terminated from the failed deployment, Elastic Beanstalk replaces them with instances running the application version from the most recent successful deployment.

Rolling with Additional Batch Deployments

  • Rolling with Additional Batch deployments are helpful when you need to maintain full capacity during deployments
  • This deployment is similar to Rolling deployments, except they do not do an in place deployment but a disposable one, launching a new batch of instances prior to taking any instances out of service
  • When the deployment completes, Elastic Beanstalk terminates the additional batch of instances.
  • Rolling with additional batch deployment does not impact the capacity and ensures full capacity during the deployment process

Immutable Deployments

  • All at Once and Rolling deployment method updates existing instances.
  • If you need to ensure the application source is always deployed to new instances, instead of updating existing instances, environment can be configured to use immutable updates for deployments.
  • Immutable updates are performed by launching a second Auto Scaling group is launched in the environment and the new version serves traffic alongside the old version until the new instances pass health checks.
  • Immutable deployments can prevent issues caused by partially completed rolling deployments. If the new instances don’t pass health checks, Elastic Beanstalk terminates them, leaving the original instances untouched.

Blue Green Deployments

  • Elastic Beanstalk performs an in-place update when application versions is updated, that may result in application becoming unavailable to users for a short period of time
  • Blue Green approach is suitable for deployments that depend on resource configuration changes or a new version that can’t run alongside the old version
  • Elastic Beanstalk enables the Blue Green deployment through Swap Environment URLs feature
  • Blue Green deployment provides almost zero downtime solution, where a new version is deployed to a separate environment, and then CNAMEs of the two environments are swapped to redirect traffic to the new version
  • Blue/green deployments require that the environment runs independently of the production database i.e. not maintained by Elastic Beanstalk, if your application uses one. Because if the environment has an RDS DB instance attached to it, the data will not transfer over to the second environment, and will be lost if the original environment is terminated
  • Blue Green deployment entails a DNS change and hence do not terminate the old environment until the DNS changes have been propagated and the old DNS records expire.
  • DNS servers do not necessarily clear old records from their cache based on the time to live (TTL) you set on the DNS records.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. When thinking of AWS Elastic Beanstalk, the ‘Swap Environment URLs’ feature most directly aids in what? [CDOP]
    1. Immutable Rolling Deployments
    2. Mutable Rolling Deployments
    3. Canary Deployments
    4. Blue-Green Deployments (Simply upload the new version of your application and let your deployment service (AWS Elastic Beanstalk, AWS CloudFormation, or AWS OpsWorks) deploy a new version (green). To cut over to the new version, you simply replace the ELB URLs in your DNS records. Elastic Beanstalk has a Swap Environment URLs feature to facilitate a simpler cutover process.)
  2. You need to deploy a new version of your application. You’d prefer to use all new instances if possible, but you cannot have any downtime. You also don’t want to swap any environment URLs. You’re running t2.large instances and you normally need 15 instances to meet capacity. Which deployment method should you use? Choose the correct answer:
    1. Rolling Updates
    2. Blue/Green
    3. Immutable
    4. All at Once
  3. Your team is responsible for an AWS Elastic Beanstalk application. The business requires that you move to a continuous deployment model, releasing updates to the application multiple times per day with zero downtime. What should you do to enable this and still be able to roll back almost immediately in an emergency to the previous version? [CDOP]
    1. Enable rolling updates in the Elastic Beanstalk environment, setting an appropriate pause time for application startup.
    2. Create a second Elastic Beanstalk environment running the new application version, and swap the environment CNAMEs.
    3. Develop the application to poll for a new application version in your code repository; download and install to each running Elastic Beanstalk instance.
    4. Create a second Elastic Beanstalk environment with the new application version, and configure the old environment to redirect clients, using the HTTP 301 response code, to the new environment.


AWS Elastic Beanstalk Deployment Options

AWS OpsWorks Deployment Strategies – Certification

AWS OpsWorks Deployment Strategies

NOTE: Advanced Topic required for DevOps Professional Exam Only

All at Once Deployment

  • OpsWorks Stacks does not automatically deploy updated code to online instances, and needs to be done manually
  • Deploy command (for apps) or Update Custom Cookbooks command (for cookbooks) helps deploy the update to every instance concurrently
  • Approach is simple and fast, but leads to a downtime incase of error
  • OpsWorks allows rollback to restore previously deployed app version
  • By default, AWS OpsWorks Stacks stores the five most recent deployments, which allows you to roll back up to four versions

Rolling Deployment

  • A rolling deployment updates an application on a stack’s online application server instances in multiple phases.
  • With each phase, a subset of the online instances can be updated and verified to be successful before starting the next phase.
  • In case of any issues, the instances running the old app version can continue to handle incoming traffic until the issues are resolved.
  • Steps to perform Rolling deployment
    • Deploy the app on a single application server instance.
    • The instance can be deregistered from the load balancer, to prevent it from serving traffic
    • Verify the app is working fine
    • Deploy the update on the remainder of instances

Blue Green Deployment

  • Blue Green deployment can be achieved using separate stack for each phase of the application’s lifecycle.
  • Different stacks are sometimes referred to as environments like development, staging, production etc.
    • Blue environment is the production stack, which hosts the current application.
    • Green environment is the staging stack, which hosts the updated application.
  • Development and testing can be performed on stacks, which are not publicly accessible, and when ready the traffic can be switched.
  • Steps for Blue Green deployment with OpsWorks Stacks stacks, in conjunction with Route 53 and a pool of ELB load balancers
    • Attach unused ELB from the pool to the green stack’s application server layer
    • After all of the green stack’s instances have passed the ELB health check, the weights in Route 53 can be changed to route traffic gradually from Blue to Green stack.
    • Once the Green stack works fines and is ready to handle all traffic
    • Detach the load balancer from the old blue stack’s application server layer and return it to the pool
    • Blue stack can be retained for some time, so that if any issues the update can be rolled back by reversing the procedure to direct incoming traffic back to the old blue stack

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You company runs a complex customer relations management system that consists of around 10 different software components all backed by the same Amazon Relational Database (RDS) database. You adopted AWS OpsWorks to simplify management and deployment of that application and created an AWS OpsWorks stack with layers for each of the individual components. An internal security policy requires that all instances should run on the latest Amazon Linux AMI and that instances must be replaced within one month after the latest Amazon Linux AMI has been released. AMI replacements should be done without incurring application downtime or capacity problems. You decide to write a script to be run as soon as a new Amazon Linux AMI is released. Which solutions support the security policy and meet your requirements? Choose 2 answers
    1. Assign a custom recipe to each layer, which replaces the underlying AMI. Use AWS OpsWorks life-cycle events to incrementally execute this custom recipe and update the instances with the new AMI. (AMI cannot be updated using recipes)
    2. Create a new stack and layers with identical configuration, add instances with the latest Amazon Linux AMI specified as a custom AMI to the new layer, switch DNS to the new stack, and tear down the old stack. (Blue-Green Deployment)
    3. Identify all Amazon Elastic Compute Cloud (EC2) instances of your AWS OpsWorks stack, stop each instance, replace the AMI ID property with the ID of the latest Amazon Linux AMI ID, and restart the instance. To avoid downtime, make sure not more than one instance is stopped at the same time. (Instances cannot be updated by updating the AMI id and needs to be launched anew)
    4. Specify the latest Amazon Linux AMI as a custom AMI at the stack level, terminate instances of the stack and let AWS OpsWorks launch new instances with the new AMI. (Would result in downtime)
    5. Add new instances with the latest Amazon Linux AMI specified as a custom AMI to all AWS OpsWorks layers of your stack, and terminate the old ones. (Disposable Rolling deployment)


OpsWorks Deployment Best Practices