Week 4 : High Availability and Scalability in Cloud

4.1 High Availability and Scalability

High Availability : Highly available systems are reliable in the sense that they continue operating even
when critical components fail. They are also resilient, meaning that they are able to simply handle failure
without service disruption or data loss, and seamlessly recover from such failure.

Scalability : Scalability is the ability of a system to handle the increase in demand without impacting the
application’s performance or availability. When the demand is too high and there are not enough resources,
then it impacts performance. There are two types of scalability: 1.Vertical: scale up or down: Add or remove
resources: CPU Memory Storage 2.Horizontal: scale out or in: Add or remove systems

4.2 Elastic Load Balancer (ELB) and Auto Scaling Groups (ASG)
Nowadays many applications and websites can serve millions of concurrent requests to users/clients
globally. When the amount of network workload increases on an application or website, a single server may
fail to support network traffic. To manage the demand of volatile network traffic efficiently, you can use a
Load balancer to distribute incoming network traffic across multiple servers, and prevent failure caused by
overloading on a single server. The load balancer sits between user/client devices and backend servers to
support efficient handling of high traffic.

Elastic Load Balancer is a highly available cloud service. You can distribute traffic in one Availability
Zone or multiple Availability Zones. ELB only routes traffic to healthy targets like EC2 instances, IP
addresses, Lambda functions. Health check configuration allows monitoring the health status of your targets
that are running behind the load balancer.
For example, if any EC2 server is unhealthy or not available, ELB routes traffic to the other healthy EC2
server. It can also route traffic to the other availability zones, in case of all EC2 servers are down in a
specific availability zone.
Elastic Load Balancing automatically distributes your incoming application traffic across all the EC2
instances that you are running. Elastic Load Balancing helps to manage incoming requests by optimally
routing traffic so that no one instance is overwhelmed.
An Auto Scaling group contains a collection of EC2 instances that are treated as a logical grouping for the
purposes of automatic scaling and management. An Auto Scaling group also lets you use Amazon EC2 Auto
Scaling features such as health check replacements and scaling policies.
 To use Elastic Load Balancing with your Auto Scaling group, attach the load balancer to your Auto
Scaling group. This registers the group with the load balancer, which acts as a single point of contact for all
incoming web traffic to your Auto Scaling group.
When you use Elastic Load Balancing with your Auto Scaling group, it's not necessary to register
individual EC2 instances with the load balancer. Instances that are launched by your Auto Scaling group are
automatically registered with the load balancer. Likewise, instances that are terminated by your Auto
Scaling group are automatically deregistered from the load balancer.
After attaching a load balancer to your Auto Scaling group,
you can configure your Auto Scaling group to use Elastic Load Balancing metrics (such as the Application
Load Balancer request count per target) to scale the number of instances in the group as demand fluctuates.

4.3 Classic Load Balancer (CLB)

The Load Balancer which balances the traffic across multiple instances in multiple availability zones is
called a Classic Load Balancer.A classic load balancer distributes incoming application traffic across
multiple EC2 instances in multiple Availability Zones. This increases the fault tolerance of your
applications.
Classic load balancer serves as a single point of contact for clients. This increases the availability of your
application. You can add and remove instances from your load balancer as your needs change, without
disrupting the overall flow of requests to your application.
A listener checks for connection requests from clients, using the protocol and port that you configure, and
forwards requests to one or more registered instances using the protocol and port number that you configure.
You add one or more listeners to your load balancer.
You can configure health checks, which are used to monitor the health of the registered instances so that
the load balancer only sends requests to the healthy instances.

To ensure that your registered instances are able to handle the request load in each Availability Zone, it is
important to keep approximately the same number of instances in each Availability Zone registered with the
load balancer. For example, if you have ten instances in Availability Zone us-west-2a and two instances in
us-west-2b, the requests are distributed evenly between the two Availability Zones. As a result, the two
instances in us-west-2b serve the same amount of traffic as the ten instances in us-west-2a. Instead, you
should have six instances in each Availability Zone.

By default, the load balancer distributes traffic evenly across the Availability Zones that you enable for
your load balancer. To distribute traffic evenly across all registered instances in all enabled Availability
Zones, enable cross-zone load balancing on your load balancer. However, we still recommend that you
maintain approximately equivalent numbers of instances in each Availability Zone for better fault tolerance.

4.4 Lab – CLB Create a Classic Load Balancer

 This part provides a hands-on introduction to Classic Load Balancers through the AWS Management
Console, a web-based interface. You'll create a load balancer that receives public HTTP traffic and sends it
to your EC2 instances.

Before you begin

 Complete the steps in Prepare your VPC and EC2 instances.
 Launch the EC2 instances that you plan to register with your load balancer. Ensure that the security
groups for these instances allow HTTP access on port 80.
 Install a web server, such as Apache or Internet Information Services (IIS), on each instance, enter its
DNS name into the address field of an internet-connected web browser, and verify that the browser
displays the default page of the server.

Create a Classic Load Balancer using the AWS Management Console

Use the following procedure to create your Classic Load Balancer. Provide basic configuration
information for your load balancer, such as a name and scheme. Then provide information about your
network, and the listener that routes traffic to your instances.
To create a Classic Load Balancer
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. On the navigation bar, choose a Region for your load balancer. Be sure to select the same Region that
you selected for your EC2 instances.
3. On the navigation pane, under Load Balancing, choose Load Balancers.
4. Choose Create Load Balancer.
5. Expand the Classic Load Balancer section, then choose Create.
6. Basic configuration
a. For Load balancer name, type a name for your load balancer.
The name of your Classic Load Balancer must be unique within your set of Classic Load Balancers for the
Region, can have a maximum of 32 characters, can contain only alphanumeric characters and hyphens, and
must not begin or end with a hyphen.
b. For Scheme, select Internet-facing.
7. Network mapping
a. For VPC, select the same VPC that you selected for your instances.
b. For Mappings, first select an Availability Zone, then choose a public subnet from its available
subnets. You can only select one subnet per Availability Zone. To improve the availability of your load
balancer, select more than one Availability Zone and subnet.
8. Security groups
a. For Security groups, select an existing security group that is configured to allow the required HTTP
traffic on port 80.
9. Listeners and routing
a. For Listener, ensure the protocol is HTTP and the port is 80.
b. For Instance, ensure the protocol is HTTP and the port is 80.
10. Health checks
a. For Ping Protocol, ensure the protocol is HTTP.
b. For Ping Port, ensure the port is 80.
c. For Ping Path, ensure the path is /.
d. For Advanced health check settings, use the default values.
11. Instances
a. Select Add instances, to bring up the instance selection screen.
 b. Under Available instances, you can select from the current instances that are available to the load
balancer, based on the current network settings.
c. After you're satisfied with your selections, select Confirm to add the instances to be registered to the
load balancer.
12. Attributes
a. For Enable cross-zone load balancing, Enable connection draining, and Timeout (draining
interval) keep the default values.
13. Load balancer tags (optional)
a. The Key field is required.
b. The Value field is optional.
c. To add another tag, select Add new tag then input your values into the Key field, and optionally
the Value field.
d. To remove an existing tag, select Remove next to the tag you want to remove.
14. Summary and creation
a. If you need to change any settings, select Edit next to the setting needing to be changed.
b. After you're satisfied with all the settings shown in the summary, select Create load
balancer to begin creation of your load balancer.
c. On the final creation page, select View load balancer to view your load balancer in the
Amazon EC2 console.
15. Verify
a. Select your new load balancer.
b. On the Target instances tab, check the Health status column. After at least one of your EC2
instances is In-service, you can test your load balancer.
c. In the Details section, copy the load balancers DNS name, which would look similar to my-load-
balancer-1234567890.us-east-1.elb.amazonaws.com.
d. Paste your load balancers DNS name into the address field of a public internet connected web
browser. If your load balancer is functioning correctly, you will see the default page of your server.
16. Delete (optional)
a. If you have a CNAME record for your domain that points to your load balancer, point it to a
new location and wait for the DNS change to take effect before deleting your load balancer.
b. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
c. Select the load balancer.
d. Choose Actions, Delete load balancer.
e. When prompted for confirmation, type confirm then select Delete.
f. After you delete a load balancer, the EC2 instances that were registered with the load
balancer continue to run. You will be billed for each partial or full hour that they continue running.
When you no longer need an EC2 instance, you can stop or terminate it to prevent incurring additional
charges.

4.5 Application Load Balancer (ALB)

An Application Load Balancer functions at the application layer, the seventh layer of the Open Systems
Interconnection (OSI) model. After the load balancer receives a request, it evaluates the listener rules in
priority order to determine which rule to apply, and then selects a target from the target group for the rule
action. You can configure listener rules to route requests to different target groups based on the content of
the application traffic. Routing is performed independently for each target group, even when a target is
registered with multiple target groups. You can configure the routing algorithm used at the target group
level. The default routing algorithm is round robin; alternatively, you can specify the least outstanding
requests routing algorithm.
 You can configure health checks, which are used to monitor the health of the registered targets so that the
load balancer can send requests only to the healthy targets.

Benefits of migrating from a Classic Load Balancer

Using an Application Load Balancer instead of a Classic Load Balancer has the following benefits:
 Support for Path conditions. You can configure rules for your listener that forward requests based on the
URL in the request. This enables you to structure your application as smaller services, and route requests to
the correct service based on the content of the URL.
 Support for Host conditions. You can configure rules for your listener that forward requests based on the
host field in the HTTP header. This enables you to route requests to multiple domains using a single load
balancer.
 Support for routing based on fields in the request, such as HTTP header conditions and methods, query
parameters, and source IP addresses.
 Support for routing requests to multiple applications on a single EC2 instance. You can register an
instance or IP address with multiple target groups, each on a different port.
 Support for redirecting requests from one URL to another.
 Support for returning a custom HTTP response.
 Support for registering targets by IP address, including targets outside the VPC for the load balancer.
 Support for registering Lambda functions as targets.
 Support for the load balancer to authenticate users of your applications through their corporate or social
identities before routing requests.
 Support for containerized applications. Amazon Elastic Container Service (Amazon ECS) can select an
unused port when scheduling a task and register the task with a target group using this port. This enables you
to make efficient use of your clusters.
 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 you to scale each service dynamically based on demand.
 Access logs contain additional information and are stored in compressed format.
 Improved load balancer performance.

4.6 Lab – ALB Getting started with Application Load Balancers

This section provides a hands-on introduction to Application Load Balancers through the AWS
Management Console, a web-based interface. To create your first Application Load Balancer, complete the
following steps.
Tasks
 Before you begin
 Step 1: Configure your target group
 Step 2: Choose a load balancer type
 Step 3: Configure your load balancer and listener
 Step 4: Test your load balancer
 Step 5: (Optional) Delete your load balancer
For demos of common load balancer configurations, see Elastic Load Balancing demos.

Before you begin

 Decide which two Availability Zones you will use for your EC2 instances. Configure your virtual private
cloud (VPC) with at least one public subnet in each of these Availability Zones. These public subnets are
used to configure the load balancer. You can launch your EC2 instances in other subnets of these
Availability Zones instead.
 Launch at least one EC2 instance in each Availability Zone. Be sure to install a web server, such as
Apache or Internet Information Services (IIS), on each EC2 instance. Ensure that the security groups for
these instances allow HTTP access on port 80.

Step 1: Configure your target group

Create a target group, which is used in request routing. The default rule for your listener routes requests to
the registered targets in this target group. The load balancer checks the health of targets in this target group
using the health check settings defined for the target group.
To configure your target group
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. In the navigation pane, under Load Balancing, choose Target Groups.
3. Choose Create target group.
4. Under Basic configuration, keep the Target type as instance.
5. For Target group name, enter a name for the new target group.
6. Keep the default protocol (HTTP) and port (80).
7. Select the VPC containing your instances. Keep the protocol version as HTTP1.
8. For Health checks, keep the default settings.
9. Choose Next.
10. On the Register targets page, complete the following steps. This is an optional step for creating the load
balancer. However, you must register this target if you want to test your load balancer and ensure that it is
routing traffic to this target.
a. For Available instances, select one or more instances.
b. Keep the default port 80, and choose Include as pending below.
11. Choose Create target group.

Step 2: Choose a load balancer type

Elastic Load Balancing supports different types of load balancers. For this tutorial, you create an
Application Load Balancer.
To create a Application Load Balancer
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. On the navigation bar, choose a Region for your load balancer. Be sure to choose the same Region that
you used for your EC2 instances.
3. In the navigation pane, under Load Balancing, choose Load Balancers.
4. Choose Create Load Balancer.
5. For Application Load Balancer, choose Create.

Step 3: Configure your load balancer and listener

To create an Application Load Balancer, you must first provide basic configuration information for your
load balancer, such as a name, scheme, and IP address type. Then, you provide information about your
network, and one or more listeners. A listener is a process that checks for connection requests. It is
configured with a protocol and a port for connections from clients to the load balancer.
To configure your load balancer and listener
1. For Load balancer name, enter a name for your load balancer. For example, my-alb.
2. For Scheme and IP address type, keep the default values.
3. For Network mapping, select the VPC that you used for your EC2 instances. Select at least two
Availability Zones and one subnet per zone. For each Availability Zone that you used to launch your EC2
instances, select the Availability Zone and then select one public subnet for that Availability Zone.
4. For Security groups, we select the default security group for the VPC that you selected in the previous
step. You can choose a different security group instead. The security group must include rules that allow the
load balancer to communicate with registered targets on both the listener port and the health check port. For
more information, see Security group rules.
5. For Listeners and routing, keep the default protocol and port, and select your target group from the list.
This configures a listener that accepts HTTP traffic on port 80 and forwards traffic to the selected target
group by default. For this tutorial, you are not creating an HTTPS listener.
6. For Default action, select the target group that you created and registered in Step 1: Configure your
target group.
7. (Optional) Add a tag to categorize your load balancer. Tag keys must be unique for each load balancer.
Allowed characters are letters, spaces, numbers (in UTF-8), and the following special characters: + - = . _ : /
@. Do not use leading or trailing spaces. Tag values are case-sensitive.
8. Review your configuration, and choose Create load balancer. A few default attributes are applied to
your load balancer during creation. You can view and edit them after creating the load balancer. For more
information, see Load balancer attributes.

Step 4: Test your load balancer

After creating the load balancer, verify that it's sending traffic to your EC2 instances.
To test your load balancer
1. After you are notified that your load balancer was created successfully, choose Close.
2. In the navigation pane, under Load Balancing, choose Target Groups.
3. Select the newly created target group.
4. Choose Targets and verify that your instances are ready. If the status of an instance is initial, it's
probably because the instance is still in the process of being registered, or it has not passed the minimum
number of health checks to be considered healthy. After the status of at least one instance is healthy, you can
test your load balancer.
5. In the navigation pane, under Load Balancing, choose Load Balancers.
6. Select the newly created load balancer.
7. Choose Description and copy the DNS name of the load balancer (for example, my-load-balancer-
1234567890abcdef.elb.us-east-2.amazonaws.com). Paste the DNS name into the address field of an internet-
connected web browser. If everything is working, the browser displays the default page of your server.
8. (Optional) To define additional listener rules, see Add a rule.

Step 5: (Optional) Delete your load balancer

As soon as your load balancer becomes available, you are billed for each hour or partial hour that you keep
it running. When you no longer need a load balancer, you can delete it. As soon as the load balancer is
deleted, you stop incurring charges for it. Note that deleting a load balancer does not affect the targets
registered with the load balancer. For example, your EC2 instances continue to run after deleting the load
balancer created in this guide.
To delete your load balancer
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. In the navigation pane, under Load Balancing, choose Load Balancers.
3. Select the checkbox for the load balancer, choose Actions, then choose Delete.
4. When prompted for confirmation, choose Yes, Delete.

4.6 Network Load Balancer (NLB)

A Network Load Balancer functions at the fourth layer(Transport Layer) of the Open Systems
Interconnection (OSI) model. It can handle millions of requests per second. After the load balancer receives
a connection request, it selects a target from the target group for the default rule. It attempts to open a TCP
connection to the selected target on the port specified in the listener configuration.
 When you enable an Availability Zone for the load balancer, Elastic Load Balancing creates a load
balancer node in the Availability Zone. By default, each load balancer node distributes traffic across the
registered targets in its Availability Zone only. If you enable cross-zone load balancing, each load balancer
node distributes traffic across the registered targets in all enabled Availability Zones. For more information,
see Availability Zones.
To increase the fault tolerance of your applications, you can enable multiple Availability Zones for your
load balancer and ensure that each target group has at least one target in each enabled Availability Zone. For
example, if one or more target groups does not have a healthy target in an Availability Zone, we remove the
IP address for the corresponding subnet from DNS, but the load balancer nodes in the other Availability
Zones are still available to route traffic. If a client doesn't honor the time-to-live (TTL) and sends requests to
the IP address after it is removed from DNS, the requests fail.
For TCP traffic, the load balancer selects a target using a flow hash algorithm based on the protocol,
source IP address, source port, destination IP address, destination port, and TCP sequence number. The TCP
connections from a client have different source ports and sequence numbers, and can be routed to different
targets. Each individual TCP connection is routed to a single target for the life of the connection.
For UDP traffic, the load balancer selects a target using a flow hash algorithm based on the protocol,
source IP address, source port, destination IP address, and destination port. A UDP flow has the same source
and destination, so it is consistently routed to a single target throughout its lifetime. Different UDP flows
have different source IP addresses and ports, so they can be routed to different targets.

Benefits of migrating from a Classic Load Balancer

Using a Network Load Balancer instead of a Classic Load Balancer has the following benefits:
 Ability to handle volatile workloads and scale to millions of requests per second.
 Support for static IP addresses for the load balancer. You can also assign one Elastic IP address per
subnet enabled for the load balancer.
 Support for registering targets by IP address, including targets outside the VPC for the load balancer.
 Support for routing requests to multiple applications on a single EC2 instance. You can register each
instance or IP address with the same target group using multiple ports.
 Support for containerized applications. Amazon Elastic Container Service (Amazon ECS) can select an
unused port when scheduling a task and register the task with a target group using this port. This enables you
to make efficient use of your clusters.
 Support for monitoring the health of each service independently, as health checks are defined at the target
group level and many Amazon CloudWatch metrics are reported at the target group level. Attaching a target
group to an Auto Scaling group enables you to scale each service dynamically based on demand.

4.7 Lab – NLB Getting started with Network Load Balancers

To create your first Network Load Balancer, complete the following steps.
Tasks
 Before you begin
 Step 1: Configure your target group
 Step 2: Choose a load balancer type
 Step 3: Configure your load balancer and listener
 Step 4: Test your load balancer
 Step 5: (Optional) Delete your load balancer

Before you begin

 Decide which Availability Zones you will use for your EC2 instances. Configure your virtual private
cloud (VPC) with at least one public subnet in each of these Availability Zones. These public subnets are
used to configure the load balancer. You can launch your EC2 instances in other subnets of these
Availability Zones instead.
 Launch at least one EC2 instance in each Availability Zone. Ensure that the security groups for these
instances allow TCP access from clients on the listener port and health check requests from your VPC. For
more information, see Target security groups.

Step 1: Configure your target group

Create a target group, which is used in request routing. The rule for your listener routes requests to the
registered targets in this target group. The load balancer checks the health of targets in this target group
using the health check settings defined for the target group.

To configure your target group

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. In the navigation pane, under Load Balancing, choose Target Groups.
3. Choose Create target group.
4. Keep the target type as instances.
5. For Target group name, enter a name for the new target group.
6. For Protocol, choose TCP, and for Port, choose 80.
7. For VPC, select the VPC that contains your instances.
8. For Health checks, keep the default settings.
9. Choose Next.
10. On the Register targets page, complete the following steps. This is an optional step to create a target
group. However, you must register your targets if you want to test your load balancer and ensure that it is
routing traffic to your targets.
a. For Available instances, select one or more instances.
b. Keep the default port 80, and choose Include as pending below.
11. Choose Create target group.

Step 2: Choose a load balancer type

Elastic Load Balancing supports different types of load balancers. For this tutorial, you create a Network
Load Balancer.

To create a Network Load Balancer

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. On the navigation bar, choose a Region for your load balancer. Be sure to choose the same Region that
you used for your EC2 instances.
3. In the navigation pane, under Load Balancing, choose Load Balancers.
4. Choose Create load balancer.
5. For Network Load Balancer, choose Create.

Step 3: Configure your load balancer and listener

To create a Network Load Balancer, you must first provide basic configuration information for your load
balancer, such as a name, scheme, and IP address type. Then provide information about your network, and
one or more listeners. A listener is a process that checks for connection requests. It is configured with a
protocol and a port for connections from clients to the load balancer. For more information about supported
protocols and ports, see Listener configuration.

To configure your load balancer and listener

1. For Load balancer name, enter a name for your load balancer. For example, my-nlb.
2. For Scheme and IP address type, keep the default values.
3. For Network mapping, select the VPC that you used for your EC2 instances. For each Availability
Zone that you used to launch your EC2 instances, select the Availability Zone and then select one public
subnet for that Availability Zone.
4. For Security groups, we preselect the default security group for your VPC. You can select other security
groups as needed. If you don't have a suitable security group, choose Create a new security group and create
one that meets your security needs.
Warning : If you don't associate any security groups with your load balancer now, you can't associate them
later on.
5. For Listeners and routing, keep the default protocol and port, and select the target group from the list.
This configures a listener that accepts TCP traffic on port 80 and forwards traffic to the selected target group
by default.
6. (Optional) Add tags to categorize your load balancer. Tag keys must be unique for each load balancer.
Allowed characters are letters, spaces, numbers (in UTF-8), and the following special characters: + - = . _ : /
@. Do not use leading or trailing spaces. Tag values are case-sensitive.
7. Review your configuration, and choose Create load balancer. A few default attributes are applied to
your load balancer during creation. You can view and edit them after creating the load balancer. For more
information, see Load balancer attributes.

Step 4: Test your load balancer

After creating the load balancer, verify that it's sending traffic to your EC2 instances.

To test your load balancer

1. After you are notified that your load balancer was created successfully, choose Close.
2. In the navigation pane, under Load Balancing, choose Target Groups.
3. Select the newly created target group.
4. Choose Targets and verify that your instances are ready. If the status of an instance is initial, it's probably
because the instance is still in the process of being registered, or it has not passed the minimum number of
health checks to be considered healthy. After the status of at least one instance is healthy, you can test your
load balancer.
5. In the navigation pane, under Load Balancing, choose Load Balancers.
6. Select the name of the newly created load balancer to open its details page.
7. Copy the DNS name of the load balancer (for example, my-load-balancer-1234567890abcdef.elb.us-east-
2.amazonaws.com). Paste the DNS name into the address field of an internet-connected web browser. If
everything is working, the browser displays the default page of your server.

Step 5: (Optional) Delete your load balancer

As soon as your load balancer becomes available, you are billed for each hour or partial hour that you keep
it running. When you no longer need a load balancer, you can delete it. As soon as the load balancer is
deleted, you stop incurring charges for it. Note that deleting a load balancer does not affect the targets
registered with the load balancer. For example, your EC2 instances continue to run.

To delete your load balancer

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. In the navigation pane, under Load Balancing, choose Load Balancers.
3. Select the checkbox for the load balancer, and choose Actions, Delete.
4. When prompted for confirmation, enter confirm and choose Delete.

4.7 Gateway Load Balancer (GWLB)

Gateway Load Balancers enable you to deploy, scale, and manage virtual appliances, such as firewalls,
intrusion detection and prevention systems, and deep packet inspection systems. It combines a transparent
network gateway (that is, a single entry and exit point for all traffic) and distributes traffic while scaling
your virtual appliances with the demand.
A Gateway Load Balancer operates at the third layer of the Open Systems Interconnection (OSI) model,
the network layer. It listens for all IP packets across all ports and forwards traffic to the target group that's
specified in the listener rule.
Gateway Load Balancers use Gateway Load Balancer endpoints to securely exchange traffic across VPC
boundaries. A Gateway Load Balancer endpoint is a VPC endpoint that provides private connectivity
between virtual appliances in the service provider VPC and application servers in the service consumer
VPC. You deploy the Gateway Load Balancer in the same VPC as the virtual appliances. You register the
virtual appliances with a target group for the Gateway Load Balancer.
Traffic to and from a Gateway Load Balancer endpoint is configured using route tables. You must create
the Gateway Load Balancer endpoint and the application servers in different subnets. This enables you to
configure the Gateway Load Balancer endpoint as the next hop in the route table for the application subnet.

4.8 Elastic Load Balancer - Sticky Sessions

ELB can be configured to use Sticky Session feature (also called session affinity) which enables it to
bind a user’s session to an instance and ensures all requests are sent to the same instance.Stickiness
remains for a period of time which can be controlled by the application’s session cookie if one exists, or
through a cookie, named AWSELB , created through Elastic Load balancer. Sticky sessions for CLB and
ALB are disabled, by default. NLB does not support sticky sessions
Requirements
 An HTTP/HTTPS load balancer.
 SSL traffic should be terminated on the ELB.
 ELB does session stickiness on an HTTP/HTTPS listener by utilizing an HTTP cookie. ELB has no
visibility into the HTTP headers if the SSL traffic is not terminated on the ELB and is terminated on the
back-end instance.
 At least one healthy instance in each Availability Zone.
Types of Stricky Sessions :
1.Duration-Based Session Stickiness
Duration-Based Session Stickiness is maintained by ELB using a special cookie created to track the
instance for each request to each listener.
2. Application-Controlled Session Stickiness
Load balancer uses a special cookie which follows the lifetime of the application cookie specified in the
policy configuration.Load balancer only inserts a new stickiness cookie if the application response includes
a new application cookie. The load balancer stickiness cookie does not update with each request.

4.9 Elastic Load Balancer - Cross Zone Load Balancing

The nodes for your load balancer distribute requests from clients to registered targets. When cross-zone
load balancing is enabled, each load balancer node distributes traffic across the registered targets in all
enabled Availability Zones. When cross-zone load balancing is disabled, each load balancer node distributes
traffic only across the registered targets in its Availability Zone.
The following diagrams demonstrate the effect of cross-zone load balancing with round robin as the
default routing algorithm. There are two enabled Availability Zones, with two targets in Availability Zone A
and eight targets in Availability Zone B. Clients send requests, and Amazon Route 53 responds to each
request with the IP address of one of the load balancer nodes. Based on the round robin routing algorithm,
traffic is distributed such that each load balancer node receives 50% of the traffic from the clients. Each load
balancer node distributes its share of the traffic across the registered targets in its scope.
If cross-zone load balancing is enabled, each of the 10 targets receives 10% of the traffic. This is because
each load balancer node can route its 50% of the client traffic to all 10 targets.

If cross-zone load balancing is disabled:

 Each of the two targets in Availability Zone A receives 25% of the traffic.
 Each of the eight targets in Availability Zone B receives 6.25% of the traffic.
This is because each load balancer node can route its 50% of the client traffic only
to targets in its Availability Zone.

4.10 Elastic Load Balancer - SSL Certificates

Installing an SSL Certificate on your AWS Elastic Load Balancer
The first thing you’ll need to do is login to your AWS Console, click on “EC2” and select “Load
Balancers” up in the left hand portion of the navigation.
Now, click “Create Load Balancer.”

After you’ve named your load balancer, scroll down to “Listener Configuration” and add a new HTTPS
load balancer protocol with “HTTP Instance” protocol. Click “continue.”
Now select “Upload New SSL Certificate

.”
After filling out the appropriate fields, click “continue.”
Select “ELBSample-ELBDefaultNegotiationPolicy” as your SSL cipher policy.
Click “continue.”
Now configure the “Health Check” to your requirements, set the “Ping Path” to “/.”
Add your EC2 Instance and click “continue.”
Now, the final step, review your setup and click “Create.”
Congratulations! You’ve now installed your SSL Certificate on your AWS Load Balancer.

4.11 Elastic Load Balancer - Connection Draining

With Connection Draining feature enabled, if an EC2 backend instance fails health checks the Elastic
Load Balancer will not send any new requests to the unhealthy instance. However, it will still allow
existing (in-flight) requests to complete for the duration of the configured timeout.
Enabling this feature will allow better management of the resources behind the Elastic Load Balancer,
such as replacing backend instances without impacting the user experience. For example, taking an
instance out of service and replacing it with a fresh EC2 instance that contains updated software, while
avoid breaking open network connections.

Enable connection draining

To enable connection draining using the console

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. On the navigation pane, under Load Balancing, choose Load Balancers.
3. Choose the name of the load balancer to open its detail page.
4. On the Attributes tab, choose Edit.
5. On the Edit load balancer attributes page, in the Traffic configuration section, select Enable
connection draining.
6. (Optional) For Timeout (draining interval), enter a value between 1 and 3,600 seconds. Otherwise the
default of 300 seconds is used.
7. Choose Save changes.
Disable connection draining

You can disable connection draining for your load balancer at any time.

To disable connection draining using the console

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. On the navigation pane, under Load Balancing, choose Load Balancers.
3. Choose the name of the load balancer to open its detail page.
4. On the Attributes tab, choose Edit.
5. On the Edit load balancer attributes page, in the Traffic configuration section, deselect Enable
connection draining.
6. Choose Save changes.

4.12 Auto Scaling Groups (ASG) Overview

An Auto Scaling group is a collection of EC2 instances that are treated as a logical
grouping for the purposes of automatic scaling and management. With an Auto
Scaling group we can use Amazon EC2 Auto Scaling features such as health check
replacements and scaling policies.The size of an Auto Scaling group depends on the
number of instances.You can adjust its size to meet demand, either manually or by
using automatic scaling.
The Auto Scaling group continues to maintain a fixed number of instances even if an
instance becomes unhealthy. If an instance becomes unhealthy, the group terminates
the unhealthy instance and launches another instance to replace it.
You can use scaling policies to increase or decrease the number of instances in your
group dynamically to meet changing conditions. When the scaling policy is in effect,
the Auto Scaling group adjusts the desired capacity of the group, between the
minimum and maximum capacity values that you specify, and launches or terminates
the instances as needed. You can also scale on a schedule.
An Auto Scaling group can launch On-Demand Instances, Spot Instances, or both.
Spot Instances provide you with access to unused EC2 capacity at steep discounts
relative to On-Demand prices.The price for Spot Instances varies based on demand
When instances are launched, if you specified multiple Availability Zones, the
desired capacity is distributed across these Availability Zones. If a scaling action
occurs, Amazon EC2 Auto Scaling automatically maintains balance across all of the
Availability Zones that you specify.

4.13 Lab – ASG Create an Auto Scaling group using a launch template
When you create an Auto Scaling group, you must specify the necessary information to configure the
Amazon EC2 instances, the Availability Zones and VPC subnets for the instances, the desired capacity, and
the minimum and maximum capacity limits.
To configure Amazon EC2 instances that are launched by your Auto Scaling group, you can specify a
launch template or a launch configuration. The following procedure demonstrates how to create an Auto
Scaling group using a launch template.
Prerequisites
 You must have created a launch template. For more information, see Create a launch template for an
Auto Scaling group.
To create an Auto Scaling group using a launch template (console)
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/, and choose Auto Scaling
Groups from the navigation pane.
2. On the navigation bar at the top of the screen, choose the same AWS Region that you used when you
created the launch template.
3. Choose Create an Auto Scaling group.
4. On the Choose launch template or configuration page, do the following:
a. For Auto Scaling group name, enter a name for your Auto Scaling group.
b. For Launch template, choose an existing launch template.
c. For Launch template version, choose whether the Auto Scaling group uses the default, the
latest, or
a specific version of the launch template when scaling out.
d. Verify that your launch template supports all of the options that you are planning to use, and
then
choose Next.
5. On the Choose instance launch options page, under Network, for VPC, choose a VPC. The Auto
Scaling group must be created in the same VPC as the security group you specified in your launch template.
6. For Availability Zones and subnets, choose one or more subnets in the specified VPC. Use subnets in
multiple Availability Zones for high availability. For more information, see Considerations when choosing
VPC subnets.
7. If you created a launch template with an instance type specified, then you can continue to the next step to
create an Auto Scaling group that uses the instance type in the launch template.
Alternatively, you can choose the Override launch template option if no instance type is specified in your
launch template or if you want to use multiple instance types for auto scaling. For more information,
see Auto Scaling groups with multiple instance types and purchase options.
8. Choose Next to continue to the next step.
Or, you can accept the rest of the defaults, and choose Skip to review.
9. (Optional) On the Configure advanced options page, configure the following options, and then
choose Next:
a. To register your Amazon EC2 instances with a load balancer, choose an existing load
balancer or create a new one. For more information, see Use Elastic Load Balancing to distribute traffic
across the instances in your Auto Scaling group. To create a new load balancer, follow the procedure
in Configure an Application Load Balancer or Network Load Balancer from the Amazon EC2 Auto
Scaling console.
b. (Optional) For Health checks, Additional health check types, select Turn on Elastic Load
Balancing health checks.
c. (Optional) For Health check grace period, enter the amount of time, in seconds. This is how
long Amazon EC2 Auto Scaling needs to wait before checking the health status of an instance after it
enters the InService state. For more information, see Set the health check grace period for an Auto
Scaling group.
d. Under Additional settings, Monitoring, choose whether to enable CloudWatch group
metrics collection. These metrics provide measurements that can be indicators of a potential issue, such
as number of terminating instances or number of pending instances. For more information, see Monitor
CloudWatch metrics for your Auto Scaling groups and instances.
e. For Enable default instance warmup, select this option and choose the warm-up time for
your application. If you are creating an Auto Scaling group that has a scaling policy, the default instance
 warmup feature improves the Amazon CloudWatch metrics used for dynamic scaling. For more
information, see Set the default instance warmup for an Auto Scaling group.
10. (Optional) On the Configure group size and scaling policies page, configure the following options, and
then choose Next:
a. For Desired capacity, enter the initial number of instances to launch. When you change this number
to a value outside of the minimum or maximum capacity limits, you must update the values
of Minimum capacity or Maximum capacity. For more information, see Set capacity limits on your
Auto Scaling group.
b. To automatically scale the size of the Auto Scaling group, choose Target tracking scaling
policy and follow the directions. For more information, see Target tracking scaling policies for Amazon
EC2 Auto Scaling.
c. Under Instance scale-in protection, choose whether to enable instance scale-in protection. For more
information, see Use instance scale-in protection.
11. (Optional) To receive notifications, for Add notification, configure the notification, and then
choose Next. For more information, see Get Amazon SNS notifications when your Auto Scaling group
scales.
12. (Optional) To add tags, choose Add tag, provide a tag key and value for each tag, and then
choose Next. For more information, see Tag Auto Scaling groups and instances.
13. On the Review page, choose Create Auto Scaling group.

To create an Auto Scaling group using the command line

You can use one of the following commands:
 create-auto-scaling-group (AWS CLI)
 New-ASAutoScalingGroup (AWS Tools for Windows PowerShell)

4.14 Auto Scaling Groups - Scaling Policies

EC2 Auto Scaling Policies provide several ways for scaling the Auto Scaling group.
o Manual Scaling
o Scheduled Scaling
o Dynamic Scaling
o Predictive Scaling

1. Manual Scaling
 Manual scaling can be performed by
o Changing the desired capacity limit of the ASG
o Attaching/Detaching instances to the ASG
 Attaching/Detaching an EC2 instance can be done only if
o Instance is in the running state.
o AMI used to launch the instance must still exist.
o Instance is not a member of another ASG.
o Instance is in the same Availability Zone as the ASG.
o If the ASG is associated with a load balancer, the instance and the load balancer must both be
in the same VPC.
 Auto Scaling increases the desired capacity of the group by the number of instances being attached.
But if the number of instances being attached plus the desired capacity exceeds the maximum size,
the request fails.
  When Detaching instances, an option to decrement the desired capacity for the ASG by the number
of instances being detached is provided. If chosen not to decrement the capacity, Auto Scaling
launches new instances to replace the ones that you detached.
 If an instance is detached from an ASG that is also registered with a load balancer, the instance is
deregistered from the load balancer. If connection draining is enabled for the load balancer, Auto
Scaling waits for the in-flight requests to complete.

2.Scheduled Scaling
 Scaling based on a schedule allows you to scale the application in response to predictable load
changes for e.g. last day of the month, the last day of a financial year.
 Scheduled scaling requires the configuration of Scheduled actions, which tells Auto Scaling to
perform a scaling action at a certain time in the future, with the start time at which the scaling action
should take effect, and the new minimum, maximum, and desired size of group should have.
 Auto Scaling guarantees the order of execution for scheduled actions within the same group, but not
for scheduled actions across groups.
 Multiple Scheduled Actions can be specified but should have unique time values and
they cannot have overlapping times scheduled which will lead to their rejection.
 Cooldown periods are not supported.

3.Dynamic Scaling
 Allows automatic scaling in response to the changing demand for e.g. scale-out in case CPU
utilization of the instance goes above 70% and scale in when the CPU utilization goes below 30%
 ASG uses a combination of alarms & policies to determine when the conditions for scaling are met.
o An alarm is an object that watches over a single metric over a specified time period. When
the value of the metric breaches the defined threshold, for the number of specified time
periods the alarm performs one or more actions (such as sending messages to Auto Scaling).
o A policy is a set of instructions that tells Auto Scaling how to respond to alarm messages.
Dynamic scaling process works as below
o CloudWatch monitors the specified metrics for all the instances in the Auto Scaling Group.
o Changes are reflected in the metrics as the demand grows or shrinks
o When the change in the metrics breaches the threshold of the CloudWatch alarm, the
CloudWatch alarm performs an action. Depending on the breach, the action is a message sent
to either the scale-in policy or the scale-out policy
o After the Auto Scaling policy receives the message, Auto Scaling performs the scaling
activity for the ASG.
o This process continues until you delete either the scaling policies or the ASG.
 When a scaling policy is executed, if the capacity calculation produces a number outside of the
minimum and maximum size range of the group, EC2 Auto Scaling ensures that the new capacity
never goes outside of the minimum and maximum size limits.
 When the desired capacity reaches the maximum size limit, scaling out stops. If demand drops and
capacity decreases, Auto Scaling can scale out again.

4. Predictive Scaling
 Predictive scaling can be used to increase the number of EC2 instances in the ASG in advance of
daily and weekly patterns in traffic flows.
 Predictive scaling is well suited for situations where you have:
o Cyclical traffic, such as high use of resources during regular business hours and low use of
resources during evenings and weekends
 o Recurring on-and-off workload patterns, such as batch processing, testing, or periodic data
analysis
o Applications that take a long time to initialize, causing a noticeable latency impact on
application performance during scale-out events
 Predictive scaling provides proactive scaling that can help scale faster by launching capacity in
advance of forecasted load, compared to using only dynamic scaling, which is reactive in nature.
 Predictive scaling uses machine learning to predict capacity requirements based on historical data
from CloudWatch. The machine learning algorithm consumes the available historical data and
calculates the capacity that best fits the historical load pattern, and then continuously learns based on
new data to make future forecasts more accurate.
 Predictive scaling supports forecast only mode so that you can evaluate the forecast before you
allow predictive scaling to actively scale capacity

4.15 Databases in Cloud

A cloud database is a database service built and accessed through a cloud platform. It serves many of the
same functions as a traditional database with the added flexibility of cloud computing. Users install software
on a cloud infrastructure to implement the database.
Key features:
 A database service built and accessed through a cloud platform
 Enables enterprise users to host databases without buying dedicated hardware
 Can be managed by the user or offered as a service and managed by a provider
 Can support relational databases (including MySQL and PostgreSQL) and NoSQL
databases (including MongoDB and Apache CouchDB)
 Accessed through a web interface or vendor-provided API
Amazon Web Services Database Services offer a fully managed and scalable database solution for your
applications. Amazon offers a variety of database choices, which include Amazon RDS, Aurora,
DynamoDB, ElasticCache, and Redshift.
AWS offers a wide range of database options that you can choose for your applications. AWS database
services mainly fall into two categories: Relational and non-relational.
 Amazon RDS – Aurora, Oracle, PostgreSQL, MySQL, MariaDB, SQL Server
 DynamoDB
 ElasticCache – Memcached, Redis
 Redshift

4.15 Amazon RDS Overview

Amazon RDS is the service provided by the AWS which makes it easy to set up, deploy, scale, and
operate relational databases in the cloud. It provides you with six familiar database engines to choose and
that includes Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database, and SQL Server.

As RDS is a managed service provided by AWS, we can expect that like other AWS services it will
provide scalability, security and cost effectiveness to the various RDBMS it provides. The database products
available through AWS RDS are as listed below.
 MySQL - Support versions for MySQL 5.5 to 5.7. Minor upgrades happen automatically without
needing any involvement from the user.
 MariaDB – Support versions for MariaDB from 10.0 to 10.2.
 Oracle – Supports version 11g and 12c. You can use the oracle license provided by aws or bring
your own license. The costing for these two are different.
  Microsoft SQL Server – Supports version 200t to 2017. Also AWS supports the various editions
like – Enterprise, Standard, Web and Express.
 PostgreSQL – Supports version 9 to 11. Can be configured as a multi A-Z deployment with read
replicas.
 Amazon Aurora – This is Amazon’s own RDBMS. We will be covering it in a separate tutorial.

Each of these Database software is offered as Software as a Service (saas) by providing following features.
 Customization of CPU capacity, Memory allocation and IOPS(Input Output per second) for a
database instance.
 Manage software patching, failure and recovery of the RDBMS software without any user
intervention.
 Allow manual or automated backup of the database using snapshots. Restore the database from these
snapshots.
 Provide high availability by creating a primary and secondary instance which are synchronous. In
case of a failure of primary AWS RDS automatically fails over to secondary.
 Put the databases in a virtual private cloud (VPC) and aslo use AWS IAM (Identity and Access
management) service to control access to the databases.
 There are two purchase options for AWS RDS service. On-Demand Instances and Reserved
Instances. For on-Demand instance you pay for every hour of usage while for Reserved instance you
make a upfront payment for one year to three period time frame.
 For using any Aws service you ned to set up an AWS account. We assume you have set up the AWS
account by following the guide lines mentioned in the Amazon Web Services aws home page.
Below are the preliminary steps to access the RDS services from the console.

Step-1
 After logging in to the amazon console, to access the RDS services we need to navigate to the
Amazon RDS home page by searching for RDS in the search box of under the services tag as shown
in the diagram below.
 Step-2
 On clicking the link above we get the Amazon RDS home page. If it is the first time ever you are
accessing RDS services, then it will show you a screen prompting for creating a database as shown
below.

 In case you have already created some RDS resources a summary of that will be available by
scrolling down in the above page. A screen shot is shown below.

Step-3
  The next screen gives us an option to select the DB engine we need and that is the start of our
configuration steps for the database we need.

Now we will see the details on each of the industry’s popular database configuration and usage.
Amazon RDS - Interfaces

The RDS interfaces are a way to access the RDS service we create. After the creation and configuration of
the RDS service there is a need of accessing the data, uploading data to this database and running some other
program which should be able to connect to the database. Such requirements of accessing and manipulating
data by end users of the database and not necessarily the AWS account holder which created the database
needs these interfaces.

There are three main such interfaces.

1.GUI Console

This is the simplest of the interfaces where the user can login through a web browser and start using the
DB services. The down side of such access is , it needs a human to interact with the RDS services and we
cannot run a database program to do some regular tasks like – backup or analysing the DB etc.
2.Command Line Interface
It is also called CLI access where you can execute DB command through the AWS command prompt
screen which should have been installed in the client computer you are using. Below are the steps to install
CLI in your local system using which you will access AWS services.
The steps to install AWS CLI are as below.

Step-1 : Check for the version of python in your environment.

ubuntu@ubuntu:~$ python -V
ubuntu@ubuntu:~$ python3 -V
When we run the above program, we get the following output −
Python 2.7.12
Python 3.5.2
If the version is less than 2.6 or 3.3 , then you need to upgrade the version of python in your system.
Step -2 : Check for availability of the python package named pip . It will be needed to install AWS CLI.
Pip -V
When we run the above program, we get the following output −
pip 10.0.1 from /home/ubuntu/.local/lib/python3.5/site-packages/pip (python 3.5)

Step -3 : Issue the following command to install the AWS CLI.

pip install awscli –upgrade –user
aws --version
When we run the above program, we get the following output −
Aws-cli/1.11.84 Python/3.6.2 Linux/4.4.0

Step-4 : Next we configure the aws CLI with credentials. We issue this command and then input the
required values one by one.

aws configure

When we run the above program, we get the following output −

AWS Access Key ID [None]: ****PLE

AWS Secret Access Key [None]: ********8
Default region name [None]: us-west-2
Default output format [None]: json

With the above configuration in place you are now ready to use CLI for communicating with AWS
environments for setting up and using amazon RDS. In the next chapters we will see how we can do that.

3. AWS API

Amazon Relational Database Service (Amazon RDS) also provides an application programming interface
(API). APIs are used when the information is exchanged between the systems rather than a human issuing
the commands and receiving the result. For example, if you want to automate the addition of database
instances to a RDS service when the number of transactions reach certain threshold , then you use a AWS
SDK to write a program which will monitor the number of database transactions and spin-off a RDS
instance when the required condition is met.

Below is an example of API code that creates a copy of a DB snapshot. It is a python program which uses
AWS sdk named boto3. The client library in boto3 has a method named copy_db_snapshot which is called
by the python program to create a copy of the DB snapshot with the required parameters as shown.

import boto3
client = boto3.client('rds')
response = client.copy_db_snapshot(
SourceDBSnapshotIdentifier='mydbsnapshot',
TargetDBSnapshotIdentifier='mydbsnapshot-copy',
)
print(response)

When the above program is run we get the response which describes the various properties of the copy
event. Here the term string represents the various names of parameters which is defined by the user for their
environment. For example VpcID represents the ID of the vpc in which the copy action is happening.

{
'DBSnapshot': {
'DBSnapshotIdentifier': 'string',
'DBInstanceIdentifier': 'string',
 'SnapshotCreateTime': datetime(2015, 1, 1),
'Engine': 'string',
'AllocatedStorage': 123,
'Status': 'string',
'Port': 123,
'AvailabilityZone': 'string',
'VpcId': 'string',
'InstanceCreateTime': datetime(2015, 1, 1),
'MasterUsername': 'string',
'EngineVersion': 'string',
'LicenseModel': 'string',
'SnapshotType': 'string',
'Iops': 123,
'OptionGroupName': 'string',
'PercentProgress': 123,
'SourceRegion': 'string',
'SourceDBSnapshotIdentifier': 'string',
'StorageType': 'string',
'TdeCredentialArn': 'string',
'Encrypted': True|False,
'KmsKeyId': 'string',
'DBSnapshotArn': 'string',
'Timezone': 'string',
'IAMDatabaseAuthenticationEnabled': True|False,
'ProcessorFeatures': [
{
'Name': 'string',
'Value': 'string'
},
]
}
}

4.16 a. RDS Encryption + Security

RDS Encryption : Amazon RDS encrypts your databases using keys you manage with the AWS Key
Management Service (KMS). On a database instance running with Amazon RDS encryption, data stored at
rest in the underlying storage is encrypted, as are its automated backups, read replicas, and snapshots.

AWS RDS Security : AWS provides multiple features to provide RDS security
DB instance can be hosted in a VPC for the greatest possible network access control
IAM policies can be used to assign permissions that determine who is allowed to manage RDS resources
Security groups allow controlling what IP addresses or EC2 instances can connect to the databases on a DB
instance
Secure Socket Layer (SSL) connections with DB instances
RDS encryption to secure RDS instances and snapshots at rest.
Network encryption and transparent data encryption (TDE) with Oracle DB instances

4.16 Amazon Aurora

 AWS RDS Aurora is an AWS native relational database that is compliant with MySQL as well as
PostgreSQL, and a fully managed database service. It is available in an instance sized model as well as a
serverless model. It is available for deployment as a single region as well as a multi-region database.
Considering the various features and compliance it offers with above mentioned open source databases, it is
a very promising migration candidate for those who intend to migrate from open source databases to cloud-
native databases without losing compatibility or having to re-work the entire database and connected
systems. In this article, we will learn how to get started with the AWS RDS Aurora DB cluster and create a
new Aurora database instance.

Lab -AWS RDS Aurora Setup

Aurora is one of the six databases offered as part of the AWS RDS database offerings. So, we need to first
navigate to the AWS RDS homepage. Open the AWS Management Console, and type AWS in the search
console. It would show the AWS RDS Service link as shown below. Click on that to navigate to the AWS
RDS Dashboard page.
 Once you land on the dashboard page, it would look as shown below. Generally, there would be an
informational message showing that Aurora is a MySQL and PostgreSQL compatible database, with
a Create database button to start creating the database from the dashboard page itself. You can click this
button or you can click on the Database Instances link in the Resources section.

Clicking on any of the options would land you on the create database wizard. The first option to select on
this wizard is whether one would like to use the Standard Create option or the Easy Create option. The
Standard Create option provides options to configure and customize all the details to configure the AWS
RDS Aurora cluster, while the Easy Create option uses recommended settings for most of the options.
Advance users generally go with the Standard Create option, which is the default option as well. We will
select this option as we intend to explore all the settings to create the cluster.
 The next step is the Engine options. As we intend to create an AWS RDS Aurora cluster, we would select
Amazon Aurora as the Engine. Aurora engine comes in two editions – MySQL compatible and PostgreSQL
compatible. The topology and architecture of Aurora remain native of Aurora, but the database engine
remains compliant with the selected edition. This enables users to use their existing MySQL or PostgreSQL
tools with the Amazon Aurora engine and still benefit from the additional features that Aurora provides on
the top of these database engines. Select the edition of your choice.

The next step is the Database Location. Aurora allows the creation of a Regional database Or a Global
database. As the name suggests, one can create an Aurora database in any single AWS region, whereas the
Global database can span multiple regions. One does not need a global database unless they need their
database existence in multiple geographies or regions. For the demonstration, we would be continuing with
the Regional database.

The next step is to select the database features. There are four options as shown below.
 One writer multiple readers – This is the default option, and can be used in general when you have
more reads than writes on your database instance
 One writer and multiple readers – Parallel Query – This option is suitable when you have analytical
workloads that may involve large scale data aggregation, complex calculations, and typical
operations of analytical workloads on a massive volume of transactional data
 Multiple writers – This option is suitable for use-cases where the database writes are extremely high
in volume compared to reads, and parallel write capacity is required by multiple applications
 Serverless – This option is suitable when the database usage is very volatile or unpredictable, and
you need the database capacity to elastically scale with the workloads
After selecting the database feature, the next step is to select the template – whether the database is being
created for production workloads or lower environments. This option sets the default settings of the rest of
the database configuration accordingly. For demo purposes, we can go ahead with Dev/Test template.
 In the next step, we need to configure the settings of the database in the Aurora cluster. Provide a name for
the cluster identifier as well as a username and password that would be used to connect to the cluster.

Now we need to select the database instance size. This will determine the compute capacity available to
the database. The Memory-optimized instance class is the default selection. In case if you anticipate
workloads that will have occasional spikes when you need more capacity and for the rest, you need lower
capacities, one can consider burstable classes.
If one needs a high-availability deployment of the cluster, one can create database replicas in multiple
availability zones, which may have an impact on the overall database instance cost as well. In lower
environments like development or test, one can opt to not create a database replica. As we selected the
templates as Dev/Test, the default option for Availability and durability is to not create Aurora Replica.

The next step is to configure network connectivity. One can change the VPC and the subnets, if one does
not want to go with the default option. To access this cluster over the internet, one needs to select the Yes
option for the publicly accessible setting. Alternatively, you can also place this cluster in a private subnet,
and configure the network connectivity over a VPN over other suitable options, to avoid exposing the AWS
RDS aurora cluster on the private subnet.
 Security groups control the inbound and outbound traffic over specific ports. While it is possible to choose
an existing security group, there’s also an option to create a new security group just for the AWS RDS
Aurora cluster right through the wizard. We are going to keep all the default values for the network
configuration of this AWS RDS Aurora Cluster. The default database port for Aurora is 3306. One can
change this default port to any desired port number. For this exercise, we are going to keep the default port
number as well.
 AWS RDS Aurora cluster supports password-based authentication, as well as password and IAM based
authentication. If one’s entire cloud security is not IAM driven, one can just continue with password-based
authentication which is password authentication.

In the additional configuration section, one can configure the initial database name. This is the database that
would be created in the aurora database and would be treated as the default database.
 The next setting is the Backtrack feature. It’s a unique feature that allows us to rewind the data to a
historical point-in-time, without the need to restore a snapshot as a new cluster, and then deleting the
existing cluster..

The next setting is related to monitoring. One can enable enhanced monitoring as well as configure the
time period granularity at which the metrics should be collected. The Log exports section provides an option
to enable different kinds of logs generated in CloudWatch Logs. Depending upon the nature of data and
compliance requirements, one can enable different logs.
 The last setting is the maintenance setting, which can be configured to schedule the maintenance window
as well as version upgrades. With this, we have covered all the settings that can be configured to create the
AWS RDS Aurora cluster. Finally, click on the Create database button to create the Aurora cluster.

This will start the creation of the cluster as well as the database, and it would be in an available state in
few minutes generally, as shown below. On the connectivity and security tab, you would find the read-only
and read-write endpoints, which can be used with your existing IDEs that you may be using for MySQL, to
connect to the AWS RDS Aurora cluster.
 One can delete this cluster from the Delete menu item from the Actions drop-down as shown below. This
cluster can prove to be costly if kept on for a long duration without any use. Consider deleting this cluster
one the exercise is completed.

In this way, one can create an AWS RDS Aurora Cluster compliant with MySQL or PostgreSQL.
Conclusion
 In this section, we learned how to create a brand-new AWS RDS Aurora cluster. We learned almost every
setting that can be configured while creating the cluster from the AWS Console.

4.18 Amazon ElastiCache

ElastiCache is AWS in-memory database solution that makes it easy to deploy, operate, and scale an in-
memory cache in the cloud. It provides faster retrieval of information from fast, managed, in-memory caches
instead of relying entirely on slower disk-based databases, thereby improving the performance of web
applications.

Amazon ElastiCache offers two open-source in-memory cache database engines:

 Memcached: it is an ASCII text file memory object caching system. ElastiCache is protocol
compliant with Memcached. So, all the tools used with existing Memcached environments can even
be used with ElastiCache.
 Redis is a preferred open-source in-memory key-value store that supports information structures like
lists and sorted sets. In addition, the AWS ElastiCache service conjointly includes a feature for
master/slave replication and multi-AZ, which will be used for achieving cross-AZ redundancy.

Lab –ElasticCache: Simple steps to launch an ElastiCache Redis server

Sign in to the AWS Management Console, and open the ElastiCache console
at https://console.aws.amazon.com/elasticache/.

Image Source: docs.aws.amazon.com

1. In the navigation list, choose the Subnet Groups.

2. Choose Create Subnet Group.

3. In the Create Subnet Group wizard, do the following. When all the settings are as you want them,
choose Yes, Create
a. In the Name box, type a name for your subnet group
 b. In the Description box, type a description for your subnet group

In the VPC ID box, choose the Amazon VPC that you created

c. In the Availability Zone and Subnet ID lists, choose your private subnet’s Availability Zone and
ID, and then select Add

4. Click on create in subnet group

5. Click on ElastiCache Dashboard and Get Started

6. Choose Redis from the navigation pane

7. Select Create.
8. For Cluster engine, choose Redis. Make sure the Cluster-Mode enabled check box is cleared
9. Complete the remaining based on the requirement
10. Launch an EC2
Note: In the ElastiCache security group the instance security group should be open on port 6379

11. Install Redis-cli on that

1 ~$ sudo apt install redis

12. Run the following command

 1 $ redis-cli -h redis-primary-endpoint -p 6379

Benefits of ElastiCache Server

 Simple to deploy:
With the assistance of Amazon web Services Console or the API, it is deploying a Memcached or
Redis compliant environment. It is simply deployable without fear concerning infrastructure
provisioning, installing, and maintaining cache software.
 Managed:
By automating the long management tasks like patch management, recovery, and failure detection,
ElastiCache permits a user to focus alone on application development.
 Compatible:
ElastiCache offers native access to in-memory caching environments like Memcached and Redis,
which provides compatibility with existing tools and applications.
 Elastic:
To satisfy the applying load, nodes may be easily added or far away from the ElastiCache cluster by
using the API or AWS Management Console. In Memcached, the auto-discovery option permits
automatic discovery of cache nodes by ElastiCache purchasers as they’re adscititious or removed
from the cluster.
 Reliable:
It runs on identical extremely reliable infrastructure utilized by other AWS services and provides
options like automatic failure detection and recovery. ElastiCache enhances dependability for
essential production deployments.
 Integrated:
It may be used with other AWS like relational database Service (RDS), DynamoDB, Elastic
Compute Cloud (EC2), CloudWatch, and easy Notification Service (SNS).
 Secure:
There are several security mechanisms to secure cache clusters, like using an internet services
interface to piece firewall settings to manage network access to the cluster.
 Cost-Effective:
It saves the executive price related to putting in and managing a multi-node cache cluster by
eliminating the necessity to plan, purchase and maintain hardware. Also, since cache nodes may be
easily adscititious or removed from supported application performance, a user solely needs to acquire
the resources they use.
 Multi-AZ:
For the Redis engine, ElastiCache provides replication options and multi-AZ functionality.
 Backup and restore:
ElastiCache helps in protecting knowledge by making snapshots of the cluster. Also, AWS
Management Console or the API may be used to take manual snapshots or for configuring automatic
backups.
4.19 RDS Read Replicas vs Multi AZ

DB instances replicas can be created in two ways Multi-AZ & Read Replica.

Multi-AZ

Multi-AZ allows you to have an exact copy of your production database in another AZ. AWS handles the
replication for you, so when your production database is written to, this write will automatically be
synchronized to the stand-by database.

In the event of planned database maintenance, DB instance failure, or an AZ failure, RDS will
automatically failover to the stand-by so that database operations can resume quickly without administrative
intervention.

For disaster recovery purposes, a database that's in us-east-1A will automatically replicate over to us-east-
1b. The important thing about this to understand is that you don't deal with IP addresses for this reason. If
us-east-1a fails, AWS automatically switches over to us-east-1b. Since there's no explicit IP address being
referenced in your code (but a DNS instead), the switch is seamless from the application's perspective.

It is important to understand that multi-AZ is for disaster recovery only. It is not for performance
improvements. For improving performance, you need read replicas.

Multi-AZ Databases

 SQL Server
 Oracle
 MySQL
 PostgreSQL
 MariaDB

Read Replicas

Read replicas allow you to have a read-only copy of your production database. This is achieved by using
Asynchronous replication from the primary RDS instance to the read replica. You use read replicas
primarily for very read-heavy database workloads.

 Used for scaling, not disaster recovery.

 Must have automatic backups turned on in order to deploy a read replica.
 You can have up to 5 read replica copies of any database.
 You can have read replicas of read replicas (but watch out for latency).
 Each read replica will have its own DNS endpoint.
 You can have read replicas that have Multi-AZ.
 You can create read replicas of Multi-AZ source databases.
 Read replicas can be promoted to be their own databases. This rbeaks the replication.
 You can have a read replica in a second region.

Read Replica Databases

 MySQL
 PostgreSQL
 MariaDB
 Aurora