AWS ESSENTIALS BASICS (theoretical) Part

AWS ESSENTIALS BASICS (theoretical) Part - 3

Monitoring Your AWS Infrastructure with Amazon CloudWatch

In the world of cloud computing, especially with AWS, building a solution like the Employee Directory Application involves numerous moving parts. Monitoring becomes crucial when maintaining the health of your infrastructure. Imagine your users are experiencing slow page loads on a Monday morning. You don’t want to wait until users complain before fixing the issue. This is where Amazon CloudWatch comes in.

Why Do We Need Monitoring?

Monitoring is essential to ensure you can proactively address problems, whether it's a server issue, database bottleneck, or network congestion. By collecting metrics and logs from your infrastructure, you can catch issues before they affect your users. AWS services generate real-time data points, known as metrics, that offer insights into the performance of your infrastructure.

Here’s how monitoring helps:

Identify Issues Before They Escalate: With the right monitoring in place, you can catch problems before they impact your users.
Pinpoint Problems Faster: Whether the issue lies with an EC2 instance, a database, or a recent code deployment, monitoring allows you to investigate efficiently.
Improve User Experience: Proactively monitoring ensures your users have a smoother experience with fewer disruptions.

What is Amazon CloudWatch?

Amazon CloudWatch is AWS's monitoring and observability tool. It gathers metrics, logs, and events from your infrastructure, providing you with a unified view of your systems’ performance. Whether it's EC2, RDS, or DynamoDB, CloudWatch can monitor a wide array of AWS services.

CloudWatch helps you to:

Monitor and Collect Metrics: You can monitor critical metrics like CPU usage, database connections, or network traffic in real-time.
Set Alarms: CloudWatch allows you to set alarms when specific thresholds are exceeded, so you can take immediate action.
Automate Responses: CloudWatch can trigger automated actions based on monitored data, like scaling your infrastructure or restarting instances.

Key Metrics to Monitor

Each AWS service generates its own set of metrics. Let’s take a look at a few:

EC2 Metrics: Monitor CPU utilization, memory usage, disk activity, and network traffic.
RDS Metrics: Track metrics like the number of database connections, disk space, and read/write throughput.
S3 Metrics: Monitor the number of objects in a bucket, bucket size, and the number of read/write requests.

These metrics provide insight into how well your system is performing and help you establish a baseline. Once you know what “normal” looks like, deviations from the baseline can alert you to potential problems before they affect users.

Benefits of CloudWatch Monitoring

Proactive Problem Solving: Identify and resolve issues before they impact your end users. For example, setting alarms based on CPU usage can help you identify if an EC2 instance is struggling with high loads.
Better System Reliability: Monitoring gives you a full view of how your system performs over time, helping you spot inefficiencies and optimize performance.
Cost Optimization: Monitoring resource utilization helps ensure that you’re not over-provisioning. You can downscale resources to match demand and save on costs.
Enhanced Security: By tracking unusual behavior, like traffic spikes or unauthorized access attempts, you can catch security threats early.

CloudWatch in Action: The Employee Directory Application Example

In the case of our Employee Directory Application, imagine the database layer (RDS) starts experiencing a high number of simultaneous connections, and the CPU on the EC2 instance hosting the application begins to spike. With CloudWatch, you can:

Collect Metrics: CloudWatch will collect metrics like CPU utilization and the number of database connections.
Set Alarms: If CPU utilization goes beyond 80%, CloudWatch can trigger an alarm that sends notifications or automatically scales up the instance.
Analyze Logs: You can set up CloudWatch to monitor application logs, enabling quick identification of the root cause of any issues.

Use Cases for Amazon CloudWatch

Respond to Anomalies: Detect unusual traffic patterns or CPU spikes, and send alerts to your team to take action before users are affected.
Optimize Resource Utilization: Right-size your resources by tracking utilization metrics, ensuring you only use and pay for what you need.
Troubleshooting: Use logs and metrics to troubleshoot issues faster, avoiding hours of manual investigation.

Monitoring with Amazon CloudWatch: How to Create Dashboards and Set Alarms

Amazon CloudWatch is an essential tool for monitoring AWS resources like EC2 instances, RDS databases, and more. In this blog, we’ll walk through how to set up a CloudWatch dashboard and create a CloudWatch alarm to monitor the health and performance of your AWS infrastructure. These steps will help you stay ahead of potential performance issues, allowing you to troubleshoot problems before they affect end-users.

Why Use CloudWatch?

CloudWatch enables you to collect and visualize metrics from AWS services, as well as set alarms that notify you when something goes wrong. For example, in the case of an Employee Directory Application, CloudWatch can track CPU utilization and trigger alerts if usage exceeds a specific threshold, ensuring optimal performance.

Setting Up a CloudWatch Dashboard

Navigate to CloudWatch: After logging into your AWS console, find Amazon CloudWatch in the list of services. This is your central hub for monitoring resources and setting up alarms.
Create a Dashboard:
- Click Dashboards in the left-hand navigation pane.
- Click Create Dashboard and give it a unique name, such as mydashboard.
Add a Widget:
- A widget allows you to visualize specific metrics. Choose the Line Graph widget to track resource metrics over time.
- Select Metric as your data source.
Choose the Metrics to Track:
- In the metrics section, select the service you want to monitor (for instance, EC2 for an instance's CPU utilization).
- Drill down into Per-Instance Metrics and select CPU Utilization.
Save the Dashboard: Once you’ve chosen your metrics, save the dashboard. You can now monitor your EC2 instance’s CPU utilization, along with any other metrics you add in the future.

Tip: You can customize the dashboard to include multiple widgets, tracking different metrics from multiple AWS services for a comprehensive view of your system's health.

Setting Up a CloudWatch Alarm

CloudWatch alarms help you respond proactively to performance issues by alerting you when your system deviates from defined thresholds.

Create an Alarm:
- In the CloudWatch console, navigate to Alarms and click Create Alarm.
- Choose the Metric you want to monitor, such as EC2 CPU Utilization.
Set the Threshold:
- Select the time period for monitoring (e.g., 5 minutes).
- Specify the threshold value (e.g., trigger the alarm if CPU utilization exceeds 70%).
Configure Actions:
- You can set the alarm to trigger various actions, such as sending a notification via Amazon SNS (Simple Notification Service).
- Create an SNS topic and add email recipients who should be notified when the alarm triggers.
Define the Alarm State:
- CloudWatch alarms can be in three states: OK, ALARM, or INSUFFICIENT_DATA.
- Set the alarm to trigger an action when it transitions from OK to ALARM (e.g., when CPU utilization crosses the threshold).
Review and Create:
- Give the alarm a meaningful name and description.
- Review the configuration and click Create Alarm.

Once the alarm is created, it will begin monitoring your system and remain in the INSUFFICIENT_DATA state until enough data is collected. After that, it will move to OK or ALARM depending on the metric behavior.

Breaking Down Metrics

Metrics: Metrics are data points like CPU utilization, memory usage, or network activity. For example, if you want to track how much CPU is being used by your EC2 instance, CloudWatch can provide this metric.
Namespaces: Metrics are organized into namespaces to categorize them by service (e.g., EC2, RDS). For instance, CPU utilization data for EC2 instances is stored under the EC2 namespace.
Dimensions: Dimensions are filters for metrics. For example, if you want to view the CPU utilization for a specific EC2 instance, you would use the InstanceId dimension to isolate data for that particular instance.

Setting Up Custom Metrics

By default, CloudWatch provides basic metrics, but sometimes you need to monitor custom data, like page views or request error rates. Here’s how:

Custom Metrics: Suppose you run an e-commerce website and want to track the number of successful transactions per hour. You can create a custom metric called SuccessfulTransactions and send that data to CloudWatch using the PutMetricData API.
High-Resolution Metrics: For more precise monitoring, high-resolution custom metrics allow you to collect data at 1-second intervals. For example, if you need to monitor the number of requests to your API per second, high-resolution metrics will give you that level of granularity.

CloudWatch Dashboards

CloudWatch Dashboards allow you to visualize metrics from multiple AWS services on one page. Let’s look at how you can create and use dashboards:

Create a Dashboard: In the CloudWatch console, go to Dashboards and click Create Dashboard. For instance, if you are running a web application, you can create a dashboard that monitors the CPU utilization and network traffic of the EC2 instance running your app.
Add Widgets: Widgets are customizable visual elements that display metrics. You might want to add a line graph that shows CPU utilization over time or a number widget that displays the current number of active database connections.
Customize: Create dashboards for specific use cases. For example, if you’re running multiple services across different AWS regions, you can create a dashboard that pulls data from all of those regions to give you a global view of your system’s performance.

CloudWatch Logs

CloudWatch Logs centralize and store log data from AWS services like EC2, Lambda, and RDS.

Log Events: A log event is a record of activity. For example, if an application throws an error, that error is recorded as a log event.
Log Streams: Log events from a specific resource (like an EC2 instance) are grouped into a log stream. This is useful for filtering logs related to a particular instance.
Log Groups: Log streams are organized into log groups, which allow you to manage logs based on retention and access settings. For instance, you might create a log group for all EC2 logs and set retention policies for 30 days.

Example: Suppose your application is logging all failed user login attempts. You can configure the CloudWatch Logs agent on your EC2 instance to push those log events to CloudWatch Logs for centralized analysis.

CloudWatch Alarms

CloudWatch Alarms notify you or take automated actions based on predefined thresholds for metrics.

Choose a Metric: Let’s say you want to set up an alarm to monitor the CPU utilization of your EC2 instance. You’d choose CPUUtilization as the metric.
Define a Threshold: For example, you want to be alerted if CPU utilization exceeds 80% for more than 5 minutes. Set this threshold in the alarm settings.
Select an Action: If the alarm is triggered, you can send a notification via Amazon SNS. For instance, if the CPU utilization spikes over the set threshold, the alarm can send an email to your team for immediate action.

Example: Suppose you’re running an online store, and the load spikes during a flash sale. You can set an alarm to automatically trigger when the CPU utilization exceeds 90% for 10 minutes. Once triggered, this alarm can automatically scale up additional EC2 instances to handle the traffic.

Use Case: Setting Up a 500-Error Alarm

For an Employee Directory Application, you can set an alarm for HTTP 500 errors:

Create a Metric Filter: Monitor logs for 500-error response codes using CloudWatch Logs. For example, configure the logs to capture each time a user encounters an HTTP 500 error.
Create an Alarm: Set the alarm to trigger if more than five 500 errors occur within an hour. This allows you to react promptly to high error rates.
Set an Action: You can configure the alarm to send an email via SNS to your DevOps team, alerting them to investigate the issue immediately

Building a Highly Available and Scalable Infrastructure with Amazon EC2 Auto Scaling and Load Balancing

When you're running a web application on AWS, such as an Employee Directory Application, maintaining availability and scaling efficiently are crucial. This post will walk you through how to achieve both with Amazon EC2 Auto Scaling and Load Balancing.

The Problem: Single Point of Failure

Currently, we have a single EC2 instance hosting our Employee Directory Application, and while our database (Amazon DynamoDB) and static file storage (Amazon S3) are highly available by design, our application instance is vulnerable. If this EC2 instance goes down, employees lose access to the application, leading to downtime.

Example: Imagine it's a Monday morning, and employees can't access the directory because the only instance is down. Without redundancy, there’s no backup server to handle the workload, leading to operational delays.

The Solution: Adding Redundancy

To increase availability, we need redundancy, which means running more than one instance of the application. However, placing all the instances in a single Availability Zone (AZ) could be risky. What if that AZ goes down due to a hardware failure?

Step 1: Multi-AZ Deployment
To minimize the risk, we place the new instance in a different AZ. Now, if one AZ experiences an issue, the other instance in the second AZ can continue running, ensuring your application remains available.

Example: If instance A (in AZ1) goes down, instance B (in AZ2) is still up and serving the directory, ensuring continuous availability for employees.

Scaling: Vertical vs. Horizontal

As your company grows and more employees access the application, you’ll need to scale to meet demand. There are two primary ways to scale:

Vertical Scaling: Increasing the size of the EC2 instance (more CPU, memory, etc.). However, this has limits, and you’ll eventually reach the upper bound of how large an instance can be.
Horizontal Scaling: Instead of increasing the size of a single instance, you add more instances to handle the traffic. This is more flexible as you can add as many instances as needed.

Example: If you’re expecting a spike in traffic—say, during an all-hands company meeting—you can add more EC2 instances to handle the load.

Automating Scaling with Amazon EC2 Auto Scaling

Manually launching and shutting down instances as demand fluctuates can be tedious and inefficient. This is where Amazon EC2 Auto Scaling comes in.

Auto Scaling automatically adjusts the number of EC2 instances based on the conditions you define. You set thresholds based on metrics like CPU utilization, and Auto Scaling will launch or terminate instances accordingly.

Example: If CPU utilization across your fleet exceeds 80%, Auto Scaling can launch additional instances to distribute the load. Once the traffic decreases and the CPU usage drops below 40%, it can shut down unneeded instances to save costs.

Introducing a Load Balancer

Now that you have multiple instances, you face another challenge: how do users access the application when it’s distributed across several servers? Manually managing the public IPs for each instance isn’t practical.

Step 1: Add a Load Balancer
An Elastic Load Balancer (ELB) distributes incoming traffic across your fleet of EC2 instances, ensuring no single instance becomes overwhelmed. It can also automatically route traffic to only healthy instances, further improving availability.

Example: Instead of accessing instance A or B directly, users connect to the load balancer, which automatically routes their requests to the instance with the least load or the one that’s most geographically appropriate. This way, the user experience remains consistent, even during high traffic periods.

Address Customer Redirection

Once your application is running on multiple instances, the next challenge is directing customers to the correct server. The goal is to ensure that user requests are routed efficiently, without causing delays or downtime.

There are two main strategies for this:

DNS (Domain Name System): You can configure a DNS record that points to the IP addresses of your available servers. However, DNS propagation can sometimes take time, meaning users may not be redirected to new or updated IP addresses immediately.
Load Balancer: A Load Balancer is the preferred option in most cases. It sits between your clients and your servers, distributing traffic across available instances and performing health checks to ensure only healthy servers handle requests.

Example: Imagine your application has three EC2 instances in different availability zones. If one instance goes down, the load balancer automatically routes traffic to the remaining healthy instances, avoiding downtime and ensuring a smooth user experience.

Understand the Types of High Availability

When running multiple servers, you need to decide how they will work together. This involves choosing between active-passive and active-active setups.

Active-Passive

In an active-passive configuration, one instance actively handles all traffic, while the other is on standby. If the active server fails, the passive instance takes over. This is ideal for applications that require maintaining session data on a specific server (stateful applications).

Example: A healthcare application might store sensitive patient data during a session. In an active-passive setup, the user is always directed to the same server, ensuring their session remains intact.

Active-Active

In an active-active setup, both instances are active and can handle traffic. This setup allows for better scalability since traffic is distributed evenly across all servers. However, this configuration works best for stateless applications, where the session data isn’t tied to a particular server.

Example: For an e-commerce website handling millions of visitors, active-active allows multiple servers to share the load. If one server fails, the others continue to serve traffic without interruption. However, the application should not rely on data stored on a specific server for this to work smoothly.

Elastic Load Balancing (ELB)

1. What is ELB and Its Features?

Elastic Load Balancing (ELB) is an AWS service that automatically distributes incoming application traffic across multiple EC2 instances. This improves fault tolerance and ensures that your applications can scale seamlessly as traffic fluctuates. ELB supports three types of load balancers: Application Load Balancer (ALB), Network Load Balancer (NLB), and Gateway Load Balancer (GWLB).

Example:

Imagine you have a web application hosted on two EC2 instances. Without a load balancer, all traffic could go to one instance, overloading it while the other remains idle. With ELB, traffic is distributed between the instances, improving performance and availability.

2. Features of ELB

Automatic Scaling: ELB automatically scales based on the incoming traffic. It adjusts the number of EC2 instances handling requests to ensure high availability.
High Availability: ELB operates across multiple Availability Zones, ensuring that even if one instance or zone goes down, the service remains available.
Security: ELB integrates with AWS security features like Security Groups and AWS Certificate Manager for SSL/TLS encryption.

Example:

A news website might experience spikes in traffic when breaking news occurs. ELB will automatically distribute traffic across additional instances as needed.

3. Health Checks

Health checks are a critical part of ELB, ensuring that only healthy EC2 instances handle requests. ELB periodically checks whether instances are functioning properly by sending a request to a defined endpoint. If an instance fails, ELB stops sending traffic to it until it passes health checks again.

Example:

For a blog website, you might set a health check on /status to verify that the server and database are running. If the page doesn't return a 200 OK status, ELB will mark the instance as unhealthy and reroute traffic to other instances.

4. Components of ELB

Listeners: A listener checks for connection requests. It specifies the protocol (HTTP, HTTPS) and port for incoming traffic.
Target Groups: A collection of instances or other resources to which ELB routes traffic. It ensures that traffic is only sent to healthy instances.
Rules: These control how ELB routes requests. For example, traffic directed at /api can be routed to one set of instances, while /web can be routed to another.

5. Types of ELB

Application Load Balancer (ALB): Ideal for HTTP/HTTPS traffic, supports advanced routing based on request details like URL paths and headers.
Network Load Balancer (NLB): Used for TCP, UDP, and TLS traffic. NLB can handle high-throughput scenarios with extremely low latency.
Gateway Load Balancer (GWLB): Primarily used for distributing traffic to third-party appliances, like firewalls or intrusion detection systems.

Auto Scaling

1. What is Auto Scaling?

Auto Scaling is a service that helps you automatically adjust the number of EC2 instances to handle traffic. It ensures your application always has the right resources to meet demand, scaling in during periods of low demand and scaling out during peaks.

Example:

For an e-commerce store, traffic typically spikes during the holiday season. Auto Scaling can automatically launch additional EC2 instances to handle the surge and reduce them when traffic returns to normal.

2. Vertical and Horizontal Scaling

Vertical Scaling: Involves increasing the instance size (e.g., upgrading to a more powerful EC2 instance).
Horizontal Scaling: Involves adding more instances to share the load. This is more cost-effective in large-scale systems.

Example:

If your blog site needs more processing power, vertical scaling would mean upgrading from a t2.micro instance to a t2.large. Horizontal scaling would involve adding another t2.micro instance.

3. Integration of Auto Scaling with ELB

Auto Scaling integrates seamlessly with ELB to balance traffic across newly launched instances. When demand increases, Auto Scaling launches new instances and adds them to the load balancer, ensuring smooth distribution of traffic.

Example:

During a product launch, traffic spikes. Auto Scaling launches new EC2 instances and automatically adds them to the ELB to handle the extra load.

4. Components of Auto Scaling

Launch Templates: Define the configuration for new instances, including AMI, instance type, and security groups.
Example:
If you're launching instances for a web app, the launch template would specify the AMI and instance size (t2.micro) used.
Auto Scaling Group (ASG): Defines the pool of instances managed by Auto Scaling, including minimum, maximum, and desired instance count.
Example:
You may set the minimum instance count to 2, and Auto Scaling will ensure there are always 2 running instances, scaling up or down based on demand.
Scaling Policies: Define how Auto Scaling adjusts resources, such as increasing instances when CPU usage exceeds 70%.
Example:
If CPU usage across all instances exceeds 70%, Auto Scaling can add an additional instance to balance the load.

5. Scaling Policies and Types

Simple Scaling Policy: Adds or removes instances based on a single metric like CPU utilization.
Example:
If CPU usage exceeds 80% for 5 minutes, the policy adds one EC2 instance.
Step Scaling Policy: Responds to different levels of demand. For example, add 1 instance when CPU is above 60%, and 2 when above 80%.
Example:
If CPU usage is between 60% and 80%, one instance is added; if CPU goes above 80%, two instances are added.
Target Tracking Policy: Automatically maintains a target metric, such as keeping CPU utilization at 50%.
Example:
Auto Scaling adds or removes instances to keep average CPU utilization at 50%.

Steps to Create ELB and Auto Scaling

Creating an ELB

Go to the EC2 Console: Under "Load Balancers," click "Create Load Balancer."
Choose Load Balancer Type: Select Application, Network, or Gateway Load Balancer based on your use case.
Configure Basic Settings: Name the load balancer, choose an internet-facing or internal load balancer, and select Availability Zones.
Configure Listeners: Set the protocol and port (HTTP/80 or HTTPS/443).
Create a Target Group: Choose the type (EC2 instance, Lambda, etc.), configure the health check, and select your instances.
Finish Creation: Review settings and create the load balancer.

Creating Auto Scaling

Go to the EC2 Console: Under "Auto Scaling Groups," click "Create Auto Scaling Group."
Create Launch Template: Specify your AMI, instance type, security groups, and user data script for instance configuration.
Configure Auto Scaling Group: Name the group, select your VPC and subnets, and choose the ELB target group for load balancing.
Set Minimum, Maximum, Desired Capacity: Define the baseline number of instances and upper limits.
Configure Scaling Policies: Choose between simple, step, or target tracking policies to adjust instance count based on demand.
Review and Create: Complete the setup by reviewing the configurations and clicking "Create Auto Scaling Group."

Machine learning guider