Cloud Computing — AWS — Part 7

Elastic Load Balancer in AWS (ELB) — Classic Load Balancer (CLB):

A load balancer distributes incoming network or application traffic across multiple servers to ensure high availability, reliability, and performance. It prevents overloading a single server, optimizes resource utilization, and maintains service continuity by redirecting traffic if a server becomes unavailable.

What Happens if a Request is Sent to an Inactive Server?

If a request is sent to an inactive server, it will fail due to the server’s inability to process it. This may result in errors, timeouts, or no response. Load balancers typically prevent this by detecting inactive servers and routing requests to healthy, active ones.

We can see the types of load balancers available on AWS, via the load balancing section available at the left menu:

Click on the “Load balaners” option, a screen like this will appear:

Now, click on the Orange button, following screen will appear:

Let’s start to work with “Classic Load Balancer”, for this create 3 instances on different zones:

And, just change the subnet, also write the

The three instances will be like:

Check if the script we wrote is working properly or not, just copy paste the IP address of each in new tab.

Now, go to the load balancer section, again and select the “create load balancer” option, and click on the “Create” button:

Following screen will come after it:

Fill the options as you want to:

Then select the VPC and also select the security groups.

EC2 Instance Accessible by LoadBalancer only:

When we delete the HTTP connection option from the instances, we can find that it no longer allows to access the instance with the help of IP address of it.

It basically, changes “Inservice” status of Instances to “OutOfService” status.

So, how to change the security group so that only load balancer can access it?

Select the instance -> Click on security option -> Change the settings to make it accessible for HTTP by service as per the name of load balancer.

Note: AWS provide high availability as well as fault tolerance for the Load balancer created in it.

Delete Classic Load Balancer:

Just delete the Load Balancer, simply.

Application Load Balancer (ALB):

What is an Application Load Balancer (ALB)?

An Application Load Balancer (ALB) is a type of load balancer provided by cloud services like Amazon Web Services (AWS) that operates at the application layer (Layer 7) of the OSI model. ALBs route traffic based on content-specific rules (like URL paths, HTTP headers, or request parameters), making them suitable for modern microservices and web applications.

Why and When to Use an Application Load Balancer

1. Dynamic Routing and Microservices

o If your application architecture uses microservices or is designed to serve different URLs or services from the same domain, ALB is ideal.

o Example: You have a single domain (example.com) serving multiple services like /api, /user, /orders. ALB can route these paths to appropriate backend services.

1. Content-Based Routing

o ALBs can route traffic based on content such as HTTP headers, query parameters, or cookies.

o Example: Directing mobile app requests to a specific backend optimized for mobile.

1. SSL Termination

o ALBs offload the SSL termination process, reducing the workload on your backend servers.

1. WebSocket and HTTP/2 Support

o Useful for real-time applications that rely on WebSocket protocols.

1. Target Groups

o ALBs allow grouping backend servers by type or role (e.g., /api goes to Service A, /media goes to Service B).

Real-Life Example

Imagine you’re running an e-commerce platform:

• /products requests go to servers hosting the product catalog.
• /cart requests go to a microservice handling cart operations.
• /checkout requests are sent to servers managing secure payment processing.

Using an ALB, you can efficiently route these requests to the appropriate microservices, ensuring better performance and scalability.

Basic Differences: Classic Load Balancer (CLB) vs. Application Load Balancer (ALB)

Key Takeaway

Use ALBs for modern, microservice-oriented applications requiring advanced routing, content-based decisions, and protocol flexibility. For simpler architectures or when operating at Layer 4 suffices, Classic Load Balancers may still be viable.

Practical:

Create a new instance:

Under Load Balancing menu go to: Target Groups

Select “Create target groups” option:

Following window appears:

Now, write the name and leave other as defualt:

Click on “next”, following window will appear: select the instance you want to add

Click on Create target group button, and following screen will appear:

Now, again go to the “Load Balancer” -> Create load balancer:

Select the application load balancer: Following screen will appear

Fill the basic details:

Select the availabiltity zone:

Also, select the Listeners:

Then, clcik on the orange button:

Green popup will appear:

Wait for some time, and see status:

Copy the DNS name and paste it in new tab:

Path base routing in application load balancer:

Here we will create two different instances and create one seuciryt group and assign it both of them. Then we edited the rules and made it work for path.

How to get client IP address on Application server:

Launch the instance and go to the log of nginx:

Since we hadn’t runned nginx, so we didn’t get the IP address of the client. If in case we had edited our shell script to load nginx, like we had done earlier, we will be able to see the public ip address of the device we are using.

Stickiness And Custom Page Routing in Application Load Balancer

Stickiness in an Application Load Balancer (ALB) refers to the ability to maintain a user’s session on a specific target server. This is achieved by using cookies, ensuring that requests from a client are routed to the same server, enhancing user experience by maintaining session consistency.

Custom Page Routing in an ALB allows routing requests to different targets based on URL paths, hostnames, or query parameters. It enables flexible routing by directing specific requests to different backend services or application versions, optimizing resource utilization and enabling microservices architectures.

Click on edit: scroll down to “stickiness”

Note: Cross-Zone Load Balancing: Enabled by default, allowing the ALB to distribute traffic evenly across targets in different availability zones.

Network Load Balancer | Layer 4 Load Balancer:

What is Network Load Balancer in AWS?

A Network Load Balancer (NLB) is a Layer 4 (Transport Layer) load balancer that distributes incoming network traffic based on IP protocol data. It is designed to handle high-throughput and low-latency traffic, making it ideal for handling millions of requests per second.

When to Use?

Use NLB when you need high performance, low latency, and the ability to handle TCP, UDP, or TLS traffic. It’s suitable for applications requiring fast, reliable load balancing at the connection level, such as gaming servers, IoT, or real-time communication apps.

How It Works?

NLB routes incoming traffic based on IP address and TCP/UDP port to target instances. It uses static IPs and supports Elastic IP for high availability. NLB can handle sudden spikes in traffic by scaling automatically and efficiently distributing traffic to healthy backend resources.

Options Available in Network Load Balancer

• TCP, UDP, and TLS Listener: Supports multiple protocols for traffic distribution.
• Static IP: NLB provides static IP addresses, ensuring easy configuration with DNS.
• Target Groups: Routes traffic to EC2 instances, IP addresses, or Lambda functions.

Why Is It Fast Compared to Application Load Balancer?

NLB operates at Layer 4 (transport), processing traffic at the connection level, which results in faster throughput and lower latency. In contrast, Application Load Balancer operates at Layer 7 (application), which introduces additional overhead for processing complex application logic and content-based routing.

Click on the load balancer, and then on Create new load balaner:

Following screen will appear:

Fill the form, write Load balancer name:

Leave others as defualt, and scroll to select the availability zones:

Scroll down to select the Listeners and routing oprions:

Then, select the “Create target Group” link, and create a new target group:

Select the instances to be attached to:

Click on the orange button, following green scree confirmaion will occur:

Now, go to the Listeners and routing section of the Network load balancer section, and select the traget group from the “defualt action”:

Scroll down and click on the orange button, following confirmation will occur:

Go to the target group to see if the targets are in healthy state or not:

Since they are in initail state, wait for them to turn healthy.

WS Launch Template — Auto Scaling Group ( ASG ):

1. Launch Template

A Launch Template in AWS is a configuration that contains the settings required to launch EC2 instances in an Auto Scaling Group (ASG) or standalone. It defines the parameters for launching instances and can be used repeatedly, ensuring consistency in your EC2 instance deployments. You can think of it as a blueprint or a template for launching EC2 instances with predefined configuration values.

Key Features of a Launch Template:

• AMI (Amazon Machine Image): Specifies the image to use when launching the instance (like an OS or pre-configured application stack).
• Instance Type: Defines the instance type (e.g., t2.micro, m5.large) to be used.
• Key Pair: Specifies the key pair to be used for SSH access to the instance.
• Security Groups: Security groups that should be associated with the instance.
• IAM Role: Role that will be assumed by the instance.
• Block Device Mapping: Specifies the volumes and storage attached to the instance.
• User Data: Scripts that will run on the instance when it launches.
• Network Configuration: VPC, subnet, and other networking settings.
• Tagging: Tags that are applied to the instance at launch.

Launch Templates make it easier to manage instances because you can centralize configuration settings and reuse them. Additionally, you can version the templates and modify them over time without impacting existing infrastructure.

2. Auto Scaling Group (ASG)

An Auto Scaling Group (ASG) is a collection of EC2 instances that can scale in and out automatically based on demand. The ASG allows you to maintain the desired number of instances (called desired capacity) and ensures that you are running the correct number of instances to handle incoming traffic or workloads.

Get Aditya Kumar’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Key Features of an Auto Scaling Group:

• Scaling Policies: You can define automatic scaling rules based on metrics such as CPU utilization, memory usage, network traffic, etc. For example, you might scale out (add instances) if the CPU utilization is above 80% for a certain period.
• Desired Capacity: The target number of instances you want running in the group.
• Minimum and Maximum Capacity: Specifies the lower and upper bounds for the number of instances in the group. This ensures that Auto Scaling will not scale below or above the specified limits.
• Health Checks: Auto Scaling performs periodic health checks on instances in the group. If an instance is deemed unhealthy (e.g., it fails to respond to health checks), the ASG will terminate it and launch a new instance to replace it.
• Availability Zones: ASGs can distribute instances across multiple availability zones for high availability.
• Instance Launch Template: ASGs require a Launch Template or Launch Configuration, which defines the setup for the EC2 instances they will scale. This template provides the configuration needed to launch instances in the group (like instance type, AMI, security groups, etc.).

How Launch Template and ASG Work Together

When creating an Auto Scaling Group, you need to specify a Launch Template (or Launch Configuration) that defines how each EC2 instance in the group should be launched. The Launch Template provides the details on what the instances will look like when they are created, including the instance type, AMI, network configuration, and other parameters.

Example Scenario

Imagine you are managing a web application that needs to scale based on traffic. You could use the following AWS resources:

• Launch Template: Create a launch template that defines the EC2 instance configuration — for example, an m5.large instance with a specific AMI, security group, and IAM role.
• Auto Scaling Group: Create an ASG that uses this Launch Template. Set a desired capacity of 2 instances and configure scaling policies to add more instances when traffic increases (e.g., if CPU utilization exceeds 80% for 5 minutes).

With this setup:

• The ASG will automatically scale the number of EC2 instances up or down based on traffic demand, using the settings in the Launch Template.
• If any instance becomes unhealthy, the ASG will terminate the unhealthy instance and launch a new one based on the Launch Template configuration.

Benefits of Using Launch Template with ASG

• Consistency: Ensures that every instance launched in the ASG follows the same configuration.
• Versioning: You can create and manage versions of Launch Templates, making it easier to upgrade and roll back configurations.
• Automation: ASGs automatically handle scaling, health checks, and instance replacement based on traffic, ensuring high availability and optimal resource utilization.

Conclusion

• A Launch Template defines the configuration for EC2 instances, including AMI, instance type, security groups, and other settings.
• An Auto Scaling Group (ASG) ensures the right number of EC2 instances are running at any given time, based on traffic and performance metrics.
• Together, they provide a flexible and automated way to scale applications in the cloud while ensuring consistency and high availability.

Summary of Scaling Types:

Go to the instance section in left menu and click on “Launch templates:

Then click on the orange button in the appeared window:

Following window will appear:

Scroll down and select the OS, and also the instance type:

Write some shell script:

Click on the orange button, following window will appear as:

Now, for the case we want atleast one server always, we will go as: Click on the auto scaling group from the main window

Click on the orange button from the appeared window, and then the following window will appear:

Then select the following:

After it an instane will be created automatically:

Now, let’s delete this instance:

delete existing one.

Auto Scaling in Action — How to Enable Automatic Scaling

How to delete the template we had created in last topic?

Select the template and click on “actions”:

Now, create one more template:

Scroll down to the network settings:

Then add the security group, as shown:

Scroll down and write the shell script:

Then click on the orange button, a the following confirmation popup will appear:

Now, go to the Autoscaling group:

Follow the following steps:

At end, we will get something like this:

Autoscaling in AWS refers to the ability to automatically adjust the number of resources (such as EC2 instances, databases, etc.) in your environment based on demand. This ensures that you have the right amount of computing capacity available, regardless of workload fluctuations, improving performance, and reducing costs.

AWS provides various services and mechanisms to implement autoscaling, allowing businesses to maintain optimal resource levels. Below is an explanation of types of Autoscaling in AWS:

1. EC2 Auto Scaling

This is the most common form of autoscaling used in AWS. EC2 Auto Scaling automatically adjusts the number of Amazon Elastic Compute Cloud (EC2) instances running in response to changing traffic patterns or resource requirements.

Key Components of EC2 Auto Scaling:

• Launch Configuration/Template: A specification for the EC2 instances that Auto Scaling will launch. It includes instance type, AMI, security group, key pair, etc.
• Auto Scaling Group (ASG): A group of EC2 instances that can be scaled in or out based on specified conditions.
• Scaling Policies: Rules that define how to scale, including triggers based on metrics like CPU utilization, memory usage, or custom metrics.
• Scheduled Scaling: Allows you to scale based on a schedule, such as scaling up before a known traffic spike.

Types of Scaling Policies:

• Dynamic Scaling: Based on real-time metrics such as CPU usage, memory, etc.
• Target Tracking Scaling: You define a metric (e.g., CPU usage), and AWS adjusts the number of instances to keep that metric at a target value.
• Step Scaling: More advanced, allows scaling in steps based on specific thresholds (e.g., scale up by 2 instances if CPU utilization exceeds 70% for 10 minutes).
• Simple Scaling: Scales based on a single trigger and adjusts by a fixed number of instances.

2. Elastic Load Balancer (ELB) with Auto Scaling

While ELB helps distribute traffic to your EC2 instances, it works in tandem with EC2 Auto Scaling to handle traffic spikes by dynamically adding or removing instances based on load.

3. AWS Lambda Auto Scaling

For serverless applications, AWS Lambda automatically scales based on the number of incoming requests. When requests are made, Lambda functions are triggered, and AWS manages the scaling automatically in the background without any manual intervention.

Lambda Autoscaling Types:

• Event-driven Scaling: Automatically scales based on events like file uploads, message queue entries, etc.
• Concurrency Limits: You can set a concurrency limit to control the maximum number of Lambda instances running at once.

4. Amazon RDS Autoscaling

Amazon RDS (Relational Database Service) can scale in and out by adjusting the database instance size (vertical scaling) or adding read replicas (horizontal scaling).

RDS Scaling Types:

• Read Replica Scaling: Use read replicas to distribute read queries and improve performance.
• Storage Autoscaling: Automatically increases storage when nearing capacity.
• Instance Class Scaling: Adjusts the instance size to accommodate changes in database load.

5. Amazon ECS and EKS Autoscaling

For containerized applications, Amazon ECS (Elastic Container Service) and Amazon EKS (Elastic Kubernetes Service) can scale the number of running container instances.

• ECS: Scales the number of tasks based on the desired capacity and load.
• EKS: Uses Kubernetes-based auto-scaling (horizontal pod autoscaling, cluster autoscaling) to dynamically adjust resources.

6. Amazon DynamoDB Autoscaling

DynamoDB is a fully managed NoSQL database service that automatically scales to handle large amounts of traffic and data. Autoscaling in DynamoDB adjusts throughput capacity (read and write capacity units) based on traffic patterns.

7. Amazon S3 and CloudFront Autoscaling

Though not directly an “autoscaling” service, Amazon S3 (Simple Storage Service) and Amazon CloudFront (Content Delivery Network) scale automatically with your data storage and traffic demands, respectively.

Key Benefits of Autoscaling in AWS:

1. Cost Efficiency: Automatically adjusts resource consumption, ensuring you only pay for what you use.
2. Improved Performance: Ensures your applications can handle traffic spikes without performance degradation.
3. High Availability: Increases the number of instances during high traffic or unexpected demand to ensure availability.
4. Elasticity: Allows your infrastructure to grow or shrink in response to workload changes.

In summary, AWS offers a variety of autoscaling options that help you scale both compute and storage resources to handle varying loads, improve performance, and save costs by adapting resources dynamically based on demand.

Auto Scaling With Load Balancer — Load Balancer with Auto Scaling

Go to the Auto scaling group, make sure you have a template created before hand.

Now, fill the required information in the appeared window:

You will observer that one instance is created and is in pending state while one load balancer is also created.

Now, go to the load balancer and copy paste the DNS in new tab.

Enable Termination Protection — Hibernet vs PowerOff

When discussing Termination Protection in the context of cloud computing, especially in platforms like AWS, it relates to protecting instances from being accidentally terminated (deleted) during operations. The two main options for stopping an instance are Hibernation and Power Off (or simply stopping it). Below is a breakdown of Termination Protection in relation to Hibernation and Power Off:

1. Termination Protection:

• What it is:

o Termination Protection is a setting you can enable to prevent an instance from being accidentally terminated. Once enabled, even if someone tries to terminate the instance, AWS will prevent that action.

o You would typically enable this feature to protect critical or production instances from being accidentally stopped or terminated.

• Does it work with Hibernation or PowerOff?

o Yes, Termination Protection is independent of whether the instance is in a hibernated or powered off state.

o It specifically protects against the termination of the instance (not stopping or hibernating). So, regardless of the instance’s state (on, off, or hibernated), if termination protection is enabled, you cannot terminate the instance without first disabling the protection.

2. Hibernation:

• What it is:

o Hibernation saves the instance’s memory to disk and allows the instance to resume where it left off when started again.

o Hibernation is typically used for instances that require a quick start-up with the state preserved (e.g., for workloads with large amounts of in-memory data).

o You can only hibernate an EC2 instance if it meets certain conditions (e.g., the instance type supports hibernation, and the instance is using EBS-backed storage).

• Termination Protection with Hibernation:

o If you have Termination Protection enabled, you cannot terminate the instance while it’s hibernated.

o However, hibernation itself does not impact whether termination protection is active. The instance remains protected from termination regardless of whether it’s running, stopped, or hibernated.

3. Power Off (Stop):

• What it is:

o Power Off or Stop means to shut down the instance without deleting it. The instance is stopped, and you are not charged for running time, but you are still charged for EBS storage.

o Stopping an instance does not preserve its memory state like hibernation does. When you restart the instance, it starts fresh, but data on persistent storage (EBS) is preserved.

• Termination Protection with Power Off:

o Termination Protection will still prevent the instance from being terminated while it is stopped.

o Stopping the instance does not affect the termination protection setting, so even if the instance is powered off, it cannot be accidentally terminated unless the protection is manually disabled.

Summary:

• Termination Protection is a setting that prevents accidental termination of an instance.
• Hibernation and Power Off are states the instance can be in, but Termination Protection is not affected by whether the instance is in hibernation or powered off. It only prevents termination, not stopping or hibernation.

Go to the launch instance, and create one new instance:

Scroll down to the Advanced Settings:

Click on the orange button, and wait for a while:

Now, try to terminate it: NO terminate option is enabled here.

So, how to delete this instance:

Disbale the check box, and click ok, now try again:

How to create Reserve Instance — How to attach multiple NIC

Go to the left side menu and click on the “Create Network Interface” option, following screen will

Once the interface is created select it and then, go to actions and attach it to the instance created by you:

Check the available IPs after connecting the AWS:

Definition:
Reserved Instances (RIs) in AWS are a pricing model that allows users to reserve cloud resources (like EC2 instances) for a term (1 or 3 years) in exchange for lower hourly rates. It provides significant savings compared to On-Demand instances.

Use Case:
RIs are ideal for predictable workloads or applications with steady usage, such as enterprise applications, databases, or batch processing jobs, where resource demand is stable over time.

Advantages:
RIs offer cost savings (up to 75% compared to On-Demand), capacity reservation, and flexible term options. They also allow for predictable billing and help manage long-term cloud infrastructure budgets effectively.

Disadvantages:
RIs require upfront commitment, making them less flexible for unpredictable workloads. They come with limited ability to adjust configurations or change instance types, potentially leading to underutilization if demands change.

Contact Me:
📧 Email: adii.utsav@gmail.com
🔗 LinkedIn: https://www.linkedin.com/in/aditya-kumar-3241b6286/
💻 GitHub: https://github.com/Rememberful