Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now
Uncategorised

AWS Tutorials: FinOps – AWS ELB Cost optimization strategies

August 21, 2024 Leave a Comment
StrategyDescriptionApplicable ELB Types
Use the Right Type of ELBChoose the appropriate load balancer type (ALB, NLB, CLB) based on traffic type and application needs.ALB, NLB, CLB
Right-Size Your Load BalancerUse smaller instance types and pair with Autoscaling groups to avoid overprovisioning.ALB, NLB, CLB
Enable Cross-Zone Load BalancingDistribute traffic evenly across Availability Zones to reduce instance size or number.ALB, NLB
Reduce Idle ELBsIdentify and remove unused ELBs, or consolidate low-traffic ELBs into one.ALB, NLB, CLB
Optimize Listener ConfigurationsReduce the number of listeners and rules; use HTTP/2 to improve performance with fewer connections.ALB
Monitor and Analyze ELB UsageUse AWS Cost Explorer and CloudWatch to track usage and identify inefficiencies.ALB, NLB, CLB
Use AWS Savings Plans or Reserved InstancesCommit to Savings Plans or Reserved Instances for consistent workloads to reduce costs.ALB, NLB, CLB
Leverage Spot InstancesUse Spot Instances with your ELB for significant cost savings if your application can tolerate interruptions.ALB, NLB, CLB
Optimize Traffic RoutingUse geolocation routing with Route 53 or offload static content to a CDN like CloudFront.ALB, NLB, CLB
Review Data Transfer CostsMinimize inter-AZ data transfer to reduce additional charges.ALB, NLB, CLB

This table summarizes cost optimization strategies for AWS Elastic Load Balancers, including the applicable types for each strategy.

Unused AWS Elastic Load Balancers (ELBs) created by Kubernetes cluster,

To locate and clean up unused AWS Elastic Load Balancers (ELBs) created by your Kubernetes cluster, you can follow these steps:

Identify Unused ELBs • Check Kubernetes Annotations:


• Kubernetes typically creates ELBs based on service annotations. You can identify which ELBs are associated with Kubernetes services by inspecting the annotations or tags that Kubernetes applies to the ELBs.
• Use AWS CLI to List ELBs:
• List all ELBs in your AWS account:

    #List all ELBs in your AWS account:
aws elb describe-load-balancers --query 'LoadBalancerDescriptions[*].[LoadBalancerName,CreatedTime,DNSName]' --output table

# For ALBs and NLBs, use:
aws elbv2 describe-load-balancers --query 'LoadBalancers[*].[LoadBalancerName,CreatedTime,DNSName]' --output table

    Check Traffic Metrics:

    •   Use Amazon CloudWatch to monitor traffic and requests to each ELB. ELBs with zero or minimal traffic over a significant period might be unused.
•   Check metrics like RequestCount, HealthyHostCount, and UnHealthyHostCount.

    To differentiate between real traffic and traffic generated by health checks on an Elastic Load Balancer (ELB), you can follow these steps:

    Understand the Metrics

    •   RequestCount: This metric shows the total number of requests handled by the ELB. By default, it includes both real traffic and health check requests.
•   HealthyHostCount and UnHealthyHostCount: These metrics show the number of healthy or unhealthy instances behind the ELB, but they don’t directly reflect user traffic.

    To find out the real traffic for each type of Load Balancer in AWS (Classic, Network, and Application)

    To find out the real traffic for each type of Load Balancer in AWS (Classic, Network, and Application), you can refer to specific metrics in CloudWatch. Here’s a breakdown of the key metrics to monitor real traffic for each type of Load Balancer:

    1. Classic Load Balancer (CLB) • RequestCount: The total number of requests handled by the load balancer. This metric includes all incoming requests, which is useful for understanding the volume of traffic.
      • HealthyHostCount: The number of healthy instances registered with the load balancer.
      • UnHealthyHostCount: The number of unhealthy instances registered with the load balancer.
      • Latency: The time taken for the load balancer to respond to a request. This can help gauge the load and performance of the load balancer.
      • HTTPCode_Backend_2XX: The number of 2xx response codes from the backend, indicating successful requests.
      • HTTPCode_Backend_4XX: The number of 4xx response codes from the backend, indicating client errors.
      • HTTPCode_Backend_5XX: The number of 5xx response codes from the backend, indicating server errors.
      • BackendConnectionErrors: The number of connections that were not successfully established between the load balancer and the backend instances.
    2. Network Load Balancer (NLB) • ActiveFlowCount: The total number of active TCP/UDP flows (or connections) processed by the load balancer. This metric gives you an idea of the number of ongoing connections.
      • NewFlowCount: The number of new connections established by the load balancer per second.
      • ProcessedBytes: The total number of bytes processed by the load balancer, including both incoming and outgoing traffic. This metric can be used to estimate the volume of traffic.
      • HealthyHostCount: The number of healthy targets (backend instances) for each load balancer target group.
      • UnHealthyHostCount: The number of unhealthy targets (backend instances) for each load balancer target group.
      • TCP_Client_Reset_Count: The number of reset (RST) packets sent from a client to a target. High numbers may indicate issues with traffic handling.
      • TCP_Target_Reset_Count: The number of reset (RST) packets sent from a target to a client. It can indicate potential problems with target health.
    3. Application Load Balancer (ALB) • RequestCount: The number of requests processed by the load balancer. This metric provides an overall view of the traffic hitting the ALB.
      • TargetResponseTime: The average time taken for a target to respond to a request. This helps in understanding the performance of the targets.
      • HTTPCode_Target_2XX_Count: The number of 2xx response codes from targets, indicating successful requests.
      • HTTPCode_Target_3XX_Count: The number of 3xx response codes from targets, indicating redirects.
      • HTTPCode_Target_4XX_Count: The number of 4xx response codes from targets, indicating client errors.
      • HTTPCode_Target_5XX_Count: The number of 5xx response codes from targets, indicating server errors.
      • TargetConnectionErrorCount: The number of connections that were not successfully established between the load balancer and the target.
      • ConsumedLCUs: Load Balancer Capacity Units (LCUs) consumed by the ALB, which helps in understanding the resource utilization and cost associated with the ALB.

    Key Considerations for Real Traffic Analysis:

    •   Filtering Health Check Traffic: When analyzing RequestCount and similar metrics, remember that they might include health check traffic. To focus only on real user traffic, consider filtering out requests to known health check endpoints or use application-level logs to differentiate between real and health check traffic.
•   HealthyHostCount and UnHealthyHostCount: These metrics are crucial to understanding the state of the backend targets and ensuring that your load balancer is distributing traffic effectively.
    Rajesh Kumar
    Follow me
    Latest posts by Rajesh Kumar (see all)
    Subscribe
    Notify of
    guest
    0 Comments
    Newest
    Oldest Most Voted
    Inline Feedbacks
    View all comments
    0
    Would love your thoughts, please comment.x
    ()
    x