AWS Cloud Fundamentals Elastic Beanstalk and RDS

This Session's Setup

Open up the AWS Mangement Console and login to your AWS account using the admin user you created in the setup. Do not log into your root account.

At the top of your Management Console next to your username, you'll see "Ohio" listed as your region. Go ahead and change that to US East (N. Virginia).

Super important! In this section, we'll be using either Rails or Node to deploy an app to Elastic Beanstalk. Change your display name to reflect which framework you prefer. ie - Rachel W, Rails (she/her)</b>

Logistics and Expectations

1. Elastic Beanstalk brings together concepts that we talked in Session 2: VPCs, security groups, EC2 instances, etc. Like all AWS services, there are a lot of customizations and options with EB, and we will not have time to dive deeply into everything. Links to related concepts are embedded within the curriculum. We strongly recommend being present during the instruction and postponing your link-exploration of the "Additional Resources" sections until after class.
2. This session is structured differently from the previous sessions, in that the first half will be more information/lecture (note-taking recommended!) and the second half will be a hands-on workshop.
3. If you'd like more information when those terms arise in the context of the AWS services we cover, just ask and we'll be happy to pass along resources and/or documentation that you can use in your self-study. Use the Parking Lot to jot down questions you have that are not part of the course.

Review

With your breakout group, walk through this diagram from Session 2. You can disregard the Network ACLs, Virtual Private Gateway, and any IPv6 CIDR blocks.

Agenda and Goals

• Understand the purpose of Elastic Beanstalk
• Provision an environment in Elastic Beanstalk
• Provision an RDS Postgres database
• Create and configure a CodePipeline to automate app deployment

Brainstorm

In Session 2, we set up an Apache server on an EC2 instance that served a static website. Before we dive into Elastic Beanstalk, let's brainstorm what else we would need to configure on that EC2 instance to serve up either a Rails app or an Express app.

Elastic Beanstalk Overview

From AWS:

AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS.

You can simply ("simply" 😂) upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. At the same time, you retain full control over the AWS resources powering your application and can access the underlying resources at any time.

If you've ever used Heroku, you know that it simplifies the process of provisioning resources, managing configuration, and scaling applications. It allows developers instead to focus on building apps instead of managing infrastructure. Interestingly enough, Heroku actually runs on top of AWS services. Unlike Heroku, the setup process for EB is slightly more involved since it exposes more fine grained controls over your resources.

When creating an environment, EB gives you the ability to setup/configure/provision:

• Software Settings, like environment variables
• EC2 Instances
• Capacity, including auto scaling groups to add or remove EC2 instances from your environment
• Load Balancer
• Rolling Updates and Deployments, specifying how you want new versions of your app to be deployed to instances
• Security, including service roles and SSH key pairs
• Monitoring, based on health checks to the EC2 instances
• Networking components, including a security group
• Database (optional, but not recommended to provision through EB)
• Worker Details, including queues where workers will pull from

Because we are limited in time, we will not be using all of these resources today. However, we will have a fully-deployed, database-backed web application by the end of this session.

The use of EB is free; however, you will still have to pay for what resources EB provisions for you.

Using Elastic Beanstalk

As with most AWS services, there are multiple ways to use EB:

• AWS Management Console (browser)
• AWS SDKs
• AWS EB-specific CLI

In addition to the three methods of interacting with EB, there are multiple ways to deploy your code to your environment as well. EB allows a compressed (zip) version to be uploaded either through the CLI or management console. You can also automate the deployment by setting up a CodePipeline that integrates with GitHub.

Additional Resources

• AWS Elastic Beanstalk Documentation
• Elastic Beanstalk CLI

Revisiting IAM

In Session 1, we talked about Identity Access Management which gives you a way to manage who or what can use your AWS resources.

To review, IAM Users can be used for either people or applications. User accounts can be granted console and/or programmatic access depending on what you'll need the account to do. If granted programmatic access, the account will have access tokens that can be used in code.

Below is a diagram from the AWS IAM Policy documentation. Let's talk about how IAM Roles fit in.

An IAM Role can be used in multiple cases, but for today, we're going to think of a role as a way for an AWS service to have permissions to interact with another AWS service.

In today's case, Elastic Beanstalk will need to interface with many other AWS services, such as...

• EC2
• Autoscaling Groups
• Load Balancer
• S3 (for artifact storage)
• CloudWatch logs
• Security Groups
• Cloudformation Templates

When you use Elastic Beanstalk to create an environment for an application, you'll see two new roles appear in your IAM console: aws-elasticbeanstalk-ec2-role and aws-elasticbeanstalk-service-role. These roles will contain permissions so that your Elastic Beanstalk environment has permission to interact with many other AWS services.

Relational Database Service Overview

RDS is a managed relational database service from AWS. AWS manages automated backups, recovery, and software updates, and provides metrics through CloudWatch. In addition, you have the option to configure encryption on your database.

Although Elastic Beanstalk provides built-in functionality for adding a database as part of your environment, you should consider setting it up separately if you want access to the data after the environment is shut down.

At an extra cost, you can set up Multi-AZ deployment and/or Read Replicas for your RDS databases:

• For high availability, use Multi-AZ. With Multi-AZ, AWS will synchronously duplicate all of the data in your primary database to a secondary backup database that exists in a different availability zone. In the case that your primary database goes down, AWS will automatically failover to your secondary backup database.
• For high performance, use Read Replicas. If your application's workload is read-heavy, you can route any read traffic to one or more read replicas to reduce the load on your primary database. Note that read replicas do not just "automatically" work. As a developer, you must set up your application to connect to the correct database.

To summarize: high availability has to do with your application's data being available even in the case of a disaster, whereas high performance has to do with ensuring that data can be retrieved quickly. These terms apply outside of the context of databases as well.

It is best practice to isolate your RDS database in a security group that is separate from your web application and only allow incoming traffic from the security group of your EC2 instance(s). This diagram from AWS shows the relationship between EC2, RDS, and security groups:

Additional Resources

1. AWS RDS Documentation
2. RDS Multi-AZ Deployment
3. RDS Read Replicas
4. Pros and Cons of RDS vs EC2 for MySQL with AWS
5. Medium: Comparing RDS vs EC2 for PostgreSQL DB

CodePipeline Overview

From AWS:

AWS CodePipeline is a fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable application and infrastructure updates. CodePipeline automates the build, test, and deploy phases of your release process every time there is a code change, based on the release model you define.

The diagram below from AWS demonstrates a possible flow using CodePipeline:

For today's exercise, we'll setup a CodePipeline that automatically deploys our application to our Elastic Beanstalk environment (staging/production) anytime we push a change to GitHub (source). We will not integrate a test or build phase to our pipeline today.

Additional Resources

1. AWS Code Build
2. AWS Code Deploy
3. AWS Code Pipeline

Workshop: EB, RDS, and CodePipeline

At this point, we'll pair up to use the remainder of the session for a self-paced EB, RDS, and CodePipeline workshop. You can choose to deploy either a Rails app or a Node app:

• Rails EB Workshop
• Node EB Workshop

Cleanup

Make sure to complete the cleanup steps at the end of the workshop sections! Elastic Beanstalk provisions many resources for us, and we also set up an RDS database in addition to security groups and a deployment pipeline. Some of these services are free, but others have the potential to start costing money if we exceed our free tier limits.

Recommended Self-Study: Deploying on EB

For this session's self-study, you have two options:

• Deploy one of your own apps to Elastic Beanstalk using the steps from the workshop pages.
• If you deployed a Rails app during the workshop, try deploying the Node app instead (and vice versa).