Elastic Beanstalk

Question 1

Describe the All at once deployment process, stating where it would be useful.

Answer 1

All instances are stopped, then we deploy the new instances.
- Fastest deployment
- Application has downtime
- Great for quick iterations in dev env.
- No additional cost

Question 2

Describe the Rolling deployment.

Answer 2

Instances are stopped and then updated as per the predefined bucket size - e.g., 4 of v1 -> 2 of v1, 2 of v2 -> 4 of v2 (with downtime/decreased instance numbers)
- Application is running both versions at the same time
- No additional cost (instance count is never higher than max)
- Long deployment

Question 3

Describe the Rolling with additional batches deployment.

Answer 3

Same as Rolling, except a new batch of instances are deployed alongside the old ones are, and are kept while the old ones are stopped and updated (e.g., 4 of v1 -> 4 of v1, 2 of v2 -> 2 of v1, 4 of v2 -> 6 of v2 -> 4 of v2)

Question 4

Describe the Immutable deployment.

Answer 4

• Zero downtime
• New code is deployed to new instances on a temporary ASG
• New instances are then merged to the current ASG, and the old instances are then terminated
• High cost, double capacity
• Longest deployment
• Quick rollback in case of failures (terminate new ASG)

Question 5

Describe Blue / Green deployment

Answer 5

Not a ‘direct feature’ of Beanstalk
- Zero downtime and release facility
- Create a new ‘stage’ environment and deploy v2 in there
- New env. can be validated independently and rolled back if issues
- Route 53 can be setup with weighted policies to redirect some traffic to the stage env.
- Using Beanstalk, ‘swap URLs’ when done with the env. test

Question 6

What is the limit on the number of application versions Beanstalk can store, and how should you avoid hitting that limit?

Answer 6

1000 application versions
- Use a lifecycle policy to remove old versions (based on age of version or just total version count)
- Active versions will not be deleted

Question 7

How would you avoid data loss when using a lifecycle policy to delete old Beanstalk application versions?

Answer 7

Select the option not to delete the source bundle in S3

Question 8

How can you set Beanstalk configuration using files? What must you be careful of when using these files?

Answer 8

• Create your .config file in the .ebextensions/ directory in the root of source code
• YAML / JSON format
• Can modify some default settings and add other AWS resources
• Resources managed by .ebextensions get deleted if the environment goes away

Question 9

What does Beanstalk use to create all its resources? What is a use case for knowing this?

Answer 9

It uses CloudFormation to provision other AWS services
- You can define CloudFormation resources in you .ebextensions to provision ElastiCache, and S3 bucket etc.

Question 10

If you wanted to deploy a ‘test’ version of your application, what can you do?

Answer 10

Clone the environment, keeping the same configuration.

Question 11

How can you change your Beanstalk Load Balancer to another type of Load Balancer?

Answer 11

• Cannot change the balancer type in an environment once it has been chosen
  Migrate to a new configuration:
• Create a new env with the same configuration except the load balancer (therefore cannot just clone)
• Deploy your application onto the new environment
• Perform a CNAME swap or Route 53 update

Question 12

What is the issue with provisioning RDS with Beanstalk?

Answer 12

Database lifecycle is tied to the Beanstalk env lifecycle.

Question 13

How should you manage RDS with Beanstalk for prod env?

Answer 13

Separately create an RDS database and provide EB application with connection string.

Question 14

How do you decouple the RDS that has already been couple to a Beanstalk env?

Answer 14

• Snapshot the DB as a safeguard
• Go to RDS console and protect the RDS database from deletion
• Create a new Beanstalk env without RDS, and point the application to the existing RDS
• Perform a CNAME swap or Route 53 update
• Terminate old env (RDS won’t be deleted due to protection)
• Delete the CloudFormation stack for the old env (which will be stuck in the DELETE_FAILED state)

Question 15

How would you run your application as a single docker container?

Answer 15

Provide either:
- Dockerfile: Beanstalk will build and run the Docker container
- Dockerrun.aws.json (v1): Describe where already built Docker image is

Question 16

How would you run your application as a multi docker container?

Answer 16

Requires a config Dockerrun.aws.json (v2) at the root of source code
- This file will be used to generate the ECS task definition
- Docker images must be pre-build and stored in ECR for example

Question 17

What is an important difference between single and multi docker container setup?

Answer 17

Single does not use ECS - multi generates an ECS task definition to create an ECS cluster

Question 18

How can you use HTTPS with Beanstalk?

Answer 18

• Load SSL certificate into the Load Balancer from the Console
• Load it in the .ebextensions/securelistener-alb.config
• SSL certificate can be provisioned using ACM or CLI
• Must configure a security group rule to allow incoming port 443

Question 19

How can you redirect HTTP to HTTPS with Beanstalk?

Answer 19

Configure the ALB (only the ALB) with a rule

Question 20

What should you do to manage tasks that take a long time to complete?

Answer 20

Create a dedicated worker env, and push messages to this env via SQS Queue (worker env is not exposed to public)

Question 21

What is a use case for Beanstalk with a Custom Platform, and what are the high level steps to do this?

Answer 21

Using an app language that is incompatible with Beanstalk & doesn’t use Docker
- Define an AMI using Platform.yaml
- Build that platform using the Packer software (open source tool to create AMIs)

Question 22

What is the difference between Custom Platform and Custom Image

Answer 22

• Custom image is to tweak an exisiting Beanstalk Platform (Python, Node, Java…)
• Custom Platform is to create an entirely new Platform