Amazon Elastic Beanstalk is an end to end solution to help developers deploy their applications in the cloud without worrying about the infrastructure that needs to be deployed to run those applications. Elastic Beanstalk automatically handles the details of capacity provisioning, load balancing, scaling, and application health monitoring. This article, Amazon Elastic Beanstalk Exam Tips provides a high-level overview of the core concepts you need to understand for the AWS Certified Developer Associate Exam and the AWS Certified Solutions Architect Associate Exam.

Elastic Beanstalk Components

Application – An Elastic Beanstalk application is a collection of core components including environments, versions and configurations.
Application Version – The application version refers to a specific iteration of deployable code. You can upload multiple versions of the application code to the cloud and test differences between each version or manage updates
Environment – this is a version of the application that is deployed on AWS. Environments can only run single application versions at any one point in time. You can run multiple versions across multiple environments if you maintain the one version per environment at any given time. Once an environment has been built, Elastic Beanstalk provisions the necessary resources required to run the application
Environment Configuration – this is a collection of settings that define how an environment and its resources will function. As you update the environment configuration, Elastic Beanstalk will apply changes to existing resources which may also involve deleting and deploying new resources as required
Configuration Template – This is the template that you can use to define your environmental configuration

In deploying an Elastic Beanstalk environment, you have the option of provisioning the following types of environment tiers:

Web Server Tier – processes web requests over HTTP(S)
Worker Tier – runs background jobs

Important Exam Note: Each environment can support only one environment tier because it requires its own set of resources; for example, Elastic Beanstalk supports only one Auto Scaling group per environment.

Web Server Environment Tier

When configuring an environment tier, Elastic Beanstalk provisions the resources required to run your application. AWS will configure and create one elastic load balancer, an Auto Scaling group, and one or more Amazon EC2 instances. Each environment will also be configured with a CNAME record that points to the load balancer. The Environment will have a URL in the form of myapp.region.elasticbeanstalk.com which will be aliased to the Elastic Load Balancer (ELB) URL in the form of asdfgh-123456.region.elb.amazonaws.com.

The architecture is designed such that:

The load balancer will sit in front of the Amazon EC2 instances, which are part of an Auto Scaling group.
Auto Scaling automatically starts additional Amazon EC2 instances to accommodate increasing load on your application and stops instances when the load on the application drops.

Important Exam NOTE – The autoscaling group always leaves at least one instance running.

In addition to the above, the software stack that runs on EC2 instances is dependent on the container type. The container type will define the topology and software components that will be used by the environment. E.g. an Elastic Beanstalk environment configured for Apache Tomcat will use:

Amazon Linux Instance
Apache Web Server
Apache Tomcat

Host Manager

In addition to running the application in a container type, a Host Manager will run on each instance and is responsible for:

Deploying the application
Collating events and metrics which are then available to analysis
Generate instance events
Monitor application server
Patching
Managing the application log files and publishing them to S3

Finally, all EC2 instances as part of the environment will be associated with one or more security groups to allow traffic to flow inbound and outbound.

Worker Environment Tier

The worker tier is responsible for running all background tasks that are essentially decoupled from the web services tier. This ensures that your web services tier can focus on answering user requests much faster rather than get overwhelmed with background threads. The Web Tier then sends requests that need to be processed by the worker tier to a Simple Queue Service (SQS) queue which is then pulled by the worker tier for processing as and when there is available capacity.

Amazon Elastic Beanstalk manages the Amazon SQS queue and runs a daemon process on each instance that reads from the queue. When the daemon pulls an item from the queue, it sends an HTTP POST request locally to https://localhost/ with the contents of the queue message in the body.

When configuring for a Worker Environment Tier, your environment will include an autoscaling group, one or more EC2 instances and an IAM role. Amazon Elastic Beanstalk will provision an SQS queue and the host daemon on each EC2 instance that will pull requests from an SQS queue and send the data to the web application running in the worker environment tier for processing. When configuring multiple instances, each instance will have a separate daemon but will read from the same SQS queue.

Permissions

When configuring Amazon Elastic Beanstalk, you need to provide two AWS Identity and Access Management Roles. These are:

Service Role
Instance profile

Elastic Beanstalk assumes the service role in order to access other AWS services on your behalf. The Instance Profile is applied to the instances in your environment and allows them to upload logs to S3 as well as carry out other tasks based on the environmental type and platform.

Additionally:

You can create user policies which can be applied to IAM users which can have permissions to create and manage Elastic Beanstalk applications and environments. Elastic Beanstalk provides managed policies for full access and read-only access.
You can create your own instance profiles and user policies for advanced scenarios.
You can configure instances that need access to services that are not included in the default policies, and configure them as rules or create new policies.

Elastic Beanstalk Service Role

Elastic Beanstalk can assume a service role that you specify when creating an Elastic Beanstalk environment, for example when it calls an EC2, ELB or Auto Scaling APIs to gather information about the health of its AWS resources for enhanced health monitoring. An example is the AWSElasticBeanstalkEnhancedHealth managed policy which grants permissions that Elastic Beanstalk needs to monitor environment health. When configuring an environment for Elastic Beanstalk, you will be prompted to create a service role named aws-elasticbeanstalk-service-role with the default set of permissions and a trust policy that allows Elastic Beanstalk to assume the service role.

Elastic Beanstalk Instance Profile

Instance profiles are IAM roles that are applied to instances you launch in an Elastic Beanstalk environment. When setting up Elastic Beanstalk environment, you specify the instance profile that is used when your instances:

Write logs to Amazon S3
Uploads debugging data to X-Ray in AWS X-Ray integrated environments,
Coordinate container deployments with Amazon EC2 Container Service, in multi-container Docker environments
Read from AmazonSQS queue
Perform leader election with Amazon DynamoDB
Publish instance health metrics to Amazon CloudWatch

Elastic Beanstalk User Policy

It is recommended that you create IAM users for each person who uses Elastic Beanstalk to avoid using your root account or sharing credentials. Elastic Beanstalk requires permissions for using its API actions as well as launching resources in an environment including:

EC2 instances
ELB Lanches
Deployment of Autoscaling groups
Save logs and templates to S3
Send notifications via SNS, etc.

Design Considerations

When designing an Amazon Elastic Beanstalk solutions on the Amazon Cloud, you need to consider core components as part of your design strategy including:

Scalability – You can use autoscaling to scale up or down based on triggers derived from metrics monitoring your environment. You can use Autoscaling to add or remove compute capacity as your usage increases or decreases. Elastic Beanstalk applications should also be as stateless as possible, using loosely coupled, fault-tolerant components that can be scaled out as needed.
Security – Amazon AWS works on a principal of shared responsibility when it comes security. AWS expects your to regularly monitor your application for security bugs and deploys available resources to make your designs as secure as possible. You are responsible for the security of data coming in and out of your Elastic Beanstalk environment and the security of your application.
Persistent Storage – When configuring Elastic Beanstalk applications that run on Amazon EC2 instance, you must remember that there is no local persistent storage. If an instance terminates, the local file system is also terminated and you cannot recover this. In order to ensure that you still have your data, you need to configure your application to store critical data on:
- S3
- EBS
- DynamoDB
- Amazon RDS
Fault Tolerance – Design Elastic Beanstalk applications to be fault tolerant by implementing some of the following core services and solutions:
- Use multiple availability zones for your EC2 instances and RDS DBs
- Use CloudWatch for monitoring the health of your Elastic Beanstalk application and take action to ensure you deal with hardware issues
- Configure autoscaling to maintain your fleet of EC2 instances at a fixed size
- Set the retention period for backups, so that Amazon RDS can perform automated backups
Content Delivery – Due to the nature of the Internet, consider incorporating Amazon CloudFront with your Elastic Beanstalk application to help overcome any latency issues by distributing your web content across a network of edge locations around the world.
Software Updates and Patches – Elastic Beanstalk regularly perform updates to its configurations with new software and patches. Elastic Beanstalk does not upgrade running environments to new configuration versions automatically so you will need to determine when to perform a platform upgrade. Elastic Beanstalk will perform updates in batches and use rolling updates to keep your application available.
Connectivity – Elastic Beanstalk will need to connect to the instances in your environment to complete deployments. If you deploy an Elastic Beanstalk application inside an Amazon VPC, then connectivity will depend on the type of Amazon VPC environment you create. For example:
- If you deploy single instance environments, Elastic Beanstalk assigns each Amazon EC2 instance a public Elastic IP address that enables the instance to communicate directly with the Internet.
- If you are using load balancing, autoscaling environments in an Amazon VPC with both public and private subnets, you need to ensure that you:
  - Create a load balancer in the public subnet to route inbound traffic from the Internet to the Amazon EC2 instances.
  - Create a network address translation (NAT) device to route outbound traffic from the Amazon EC2 instances to the Internet.
  - Create inbound and outbound routeing rules for the Amazon EC2 instances inside the private subnet.
  - When using NAT, you need to configure the security groups for the NAT instance and Amazon EC2 instances to enable Internet communication.
- If you deploy load balancing and autoscaling environment in an Amazon VPC that has a single public subnet, no additional configuration is required because the Amazon EC2 instances are configured with a public IP address that enables the instances to communicate with the Internet.

180 Practice Exam Questions – Get Prepared for your Exam Day!

Our Exam Simulator with 180 practice exam questions comes with comprehensive explanations that will help you prepare for one of the most sought-after IT Certifications of the year. Register Today and start preparing for your AWS Certified Solutions Architect – Associate Exam.