EC2 Cost Optimization

Let’s focus on smart savings, not just cutting costs indiscriminately. Remember, not all savings are truly beneficial. While it might be tempting to reduce expenses across the board, some cost-cutting measures can hurt your business in the long run. So, what distinguishes bad savings from good savings? Let’s explore the difference and understand how strategic, thoughtful savings can drive both cost efficiency and business growth.

• Bad savings:

- Limit your ability to innovate in the future.

o?? Choosing to run your workloads on outdated EC2 instance types because they are cheaper instead of modernizing to newer instance families (like Graviton-based instances). While this may save costs initially, it can limit future opportunities to leverage performance improvements, scalability features, and new capabilities, ultimately restricting the ability to innovate.

-?Restrict business ability to respond to changing customer demands.

o?? Reducing the number of available application servers (EC2 instances) or reducing the performance of your RDS database during non-peak hours to save costs, without considering the need to scale back up quickly. If there is a sudden surge in customer traffic, the application might not be able to handle it, resulting in delays while scaling up, or even downtime.

-?Impact your end customer experience negatively.

o?? Utilizing a cheaper but slower storage solution (like cold storage or slower HDD EBS volumes) for a customer-facing application that requires fast access to data. While it may save costs, the slower storage could lead to higher latency and a poor user experience.

?

• Good Savings:

- Enable business agility through flexibility.

o?? Implementing Auto Scaling for EC2 instances or AWS Lambda for serverless computing to handle variable workloads. By using Auto Scaling, you can automatically increase or decrease the number of instances based on demand, paying only for what you use. This way, you save costs during low-demand periods without compromising the ability to handle peak loads.

- Enable more rapid innovation via lean cost structure and elasticity.

o?? Leveraging AWS Fargate for containerized applications. Fargate allows you to run containers without having to manage the underlying EC2 instances, enabling you to deploy and scale applications quickly without worrying about infrastructure management. You pay for only the resources consumed, which helps maintain a lean cost structure.

- Provide customer equal & higher performance.

o?? Using Amazon S3 Intelligent-Tiering for data storage. This storage class automatically moves data between frequent and infrequent access tiers based on usage patterns. This way, you can achieve cost savings without sacrificing performance, as data is always available in the right tier for fast access when needed.

?

Elastic Compute Cloud (EC2): If you’re not using the EC2 in an ELASTIC way then you’re not using it to fullest of its spirit what it’s designed for, of its way to deliver that efficiency & performance that you expect.

Adjusting your EC2 instance usage to ensure you have the appropriate number of instances to meet your workload demands without wasting resources or causing performance issues.

• Under-Provisioned Instances:

This occurs when there are too few instances to handle the workload, or when the instances are too small (low CPU, memory, or other resources). This results in resource bottlenecks, poor application performance, slow response times, and potential downtime.

• Over-Provisioned Instances:

Over-provisioning happens when you have more instances or larger instance types than necessary for the workload. This results in higher costs because you're paying for resources that are not fully utilized.

• Right Number of Instances (Optimized or Rightsized):

This is the ideal state where the number and size of your EC2 instances perfectly match your workload requirements. Resources are neither overused nor underused, providing a balance between performance and cost.

Cost optimization on EC2 is a continuous process that involves regular monitoring and adjustment, it’s like to have a balanced meal.

EC2 Cost optimization involves a mix of strategies focused on selecting the right instance types, managing resource utilization, and leveraging AWS pricing models. There are some effective ways to optimize costs:

?

• RIGHT INSTANCE TYPE:

Select the RIGHT INSTANCE TYPE based on your workload. For example, if your application doesn't require much CPU power, consider smaller instance types (e.g., t3.micro instead of m5.large).

?

For finding the right selection: Attribute-based instance selection (ABIS) in AWS is a feature that enables you to specify certain instance attributes when launching or scaling Amazon EC2 instances, particularly within Auto Scaling groups or EC2 Fleet configurations. Instead of selecting specific instance types manually, ABIS allows you to define desired attributes (such as vCPUs, memory, and storage), and AWS will automatically select the most appropriate instance types that match those criteria.

e.g. Let's say you want to deploy an Auto Scaling group that requires instances with:

• 4 vCPUs
• 16 GB RAM
• x86 architecture

Instead of specifying a particular instance type (like c5.xlarge), you use attribute-based instance selection to define these requirements. AWS will then automatically select the best-matching instances that meet these criteria, such as m5.xlarge, r5.xlarge, or t3a.2xlarge, based on cost, availability, and performance requirements.

• We can use tools like AWS COMPUTE OPTIMIZER to get recommendations on which instances are under-utilized or over-provisioned. AWS Compute Optimizer: It has been sent 20+ billion recommendations. It doesn’t send out recommendation if there is nothing to recommend.

• AUTO SCALING:

Implement AUTO SCALING to automatically scale the number of instances up or down based on actual usage. This ensures that you're only paying for the capacity you need, which reduces costs during off-peak times. Here are the main types of scaling policies:

1. Simple/Step Scaling

·?????? Simple Scaling:

o?? Involves straightforward rules that trigger when a specific metric crosses a threshold (e.g., CPU usage > 60%).

o?? AWS adds or removes a specified number of instances based on this condition.

o?? Example: If average CPU usage exceeds 70%, add 2 instances.

·?????? Step Scaling:

o?? An enhancement of simple scaling where you define different steps based on how much the metric deviates from the threshold.

o?? Example: If CPU usage > 70%, add 1 instance; if > 90%, add 3 instances.

·?????? Use Case: Useful when you need to scale proportionally to the workload; allows for more granular control than simple scaling.

2. Target Tracking Scaling

·?????? Automatically adjusts the number of instances to maintain a specific target value for a metric, similar to setting a thermostat.

·?????? Example: You set a target of 50% average CPU utilization. AWS adjusts the instances to keep the CPU usage around that value.

·?????? Use Case: Ideal when you need to maintain a consistent metric level, like CPU usage or request count, without manually defining specific step actions.

3. Scheduled Scaling

·?????? Allows you to set up scaling actions to occur automatically at specified times, regardless of current metrics.

·?????? Example: Scale out by 3 instances every weekday at 8 AM and scale in by 3 instances at 6 PM, anticipating peak and off-peak hours.

·?????? Use Case: Effective when your traffic patterns are predictable, such as regular business hours or planned events.

4. Predictive Scaling

·?????? Uses machine learning models to analyze historical usage patterns and predict future traffic.

·?????? Automatically scales out in advance of predicted demand spikes, helping to ensure availability and performance without over-provisioning.

·?????? Example: Predictive scaling might anticipate increased traffic at 5 PM based on past data and scale out in advance to prepare for the expected load.

·?????? Use Case: Useful for applications with recurring traffic patterns (e.g., daily, weekly, or monthly), such as e-commerce sites or periodic data processing tasks.

?

?

• Warm pools in AWS are a feature for Auto Scaling groups that allow you to keep a set of EC2 instances in a pre-initialized state, ready to be added to your fleet when needed. This helps reduce the time it takes for new instances to become available during scaling events, especially when launching instances can take several minutes due to initialization processes, such as loading software, configuration, or data.

Key Concepts of Warm Pools:

1. Pre-Warmed Instances: Warm pools keep instances in a partially running state, where they have already passed the initial setup phase (e.g., operating system boot-up, software installation). This ensures that they can be quickly added to your Auto Scaling group when traffic spikes, avoiding the typical wait time required for instance booting and configuration. Instances in the warm pool can be in two states: Stopped: Instances are shut down but retain their root volume and instance state. When they need to be scaled up, they can be quickly started. Running: Instances are already running, but they are not actively receiving traffic. This can be useful if you need instances to be immediately available with no delay.
2. Faster Scaling: Normally, when an Auto Scaling group needs to add new instances, it must launch them from scratch, which can take several minutes. Warm pools allow for almost immediate scaling because the instances are already prepared. This is particularly useful for applications that require rapid scaling to handle sudden spikes in traffic (e.g., flash sales, unexpected surges in user demand).
3. Cost Savings: Keeping instances in a stopped state within the warm pool is less expensive than running them continuously. AWS charges for storage but not for compute when instances are stopped. You can also manage how many instances are kept in the warm pool and adjust this number based on expected demand, helping balance cost and readiness.
4. Seamless Integration with Auto Scaling Groups: Warm pools are managed alongside your Auto Scaling groups. When scaling events are triggered, the warm pool can be used to bring instances online immediately, and then Auto Scaling can still launch additional instances if necessary. You can configure Auto Scaling to automatically replace used instances in the warm pool after they've been moved to the active fleet, ensuring that the warm pool remains prepared for future scaling needs.

• EC2 Spot Instances:

·?????? We can leverage EC2 Spot Instances for non-critical, batch processing, or fault-tolerant workloads. Spot Instances can be up to 90% cheaper than On-Demand prices.

Since 2013, spot instances have helped customers to save over $10 billion over the cost of on-demand until 2023.

we can also consider a Spot Fleet or Spot Instance Pools to improve availability by using multiple instance types across multiple Availability Zones (AZs).

• Reserved Instances (RIs):

Purchase reserved Instances for applications with predictable usage patterns. By committing to a 1-year or 3-year term, you can save up to 75% compared to On-Demand prices.

opt for Compute Savings Plans for even more flexibility across different instance families, regions, and even services like Lambda or Fargate+, while still enjoying significant discounts.

It introduced in 2019, and already saved customers $30 billion over the price of on-demand.

?

• Turn Off Unused Instances:

·?????? Set up scripts or use AWS Instance Scheduler to automatically start and stop instances at specific times.

?

• Use Elastic Load Balancing (ELB) and Auto Scaling Together:?

Inefficient traffic distribution can lead to poor performance and wasted resources.

·?????? Use Elastic Load Balancers (ELB) to distribute incoming traffic evenly across instances in different Availability Zones. This allows Auto Scaling to scale down instances when demand is low, further reducing costs.

·?????? Optimize the health check configurations to ensure instances are only added to the load balancer when they are ready to serve traffic, preventing unnecessary scaling.

?

• EBS Volumes:

·?????? Choose right size EBS volumes for e.g. Use gp3 over gp2 volumes for general-purpose SSDs to save costs while maintaining performance.

·?????? Delete Unused Volumes

·?????? Use Lifecycle Policies for Snapshots to automate the deletion of old snapshots, reducing the storage cost.

?

• Network & Data transfer Cost:

·?????? Place EC2 instances and other AWS services (like S3) in the same region and Availability Zone to reduce data transfer charges.

·?????? Leverage VPC endpoints to privately connect EC2 to other AWS services, reducing data transfer costs.

?

• Use AWS Cost Management Tools:

·?????? Use AWS Cost Explorer and AWS Budgets to monitor your usage and set alerts for unexpected increases in costs.

·?????? Use AWS Trusted Advisor to receive recommendations for cost savings, including underutilized resources, reserved instance purchase suggestions, and more.

• Conclusion:

Cost optimization on EC2 is a continuous process that involves regular monitoring and adjustment. By choosing the right instance types, leveraging AWS pricing models like Reserved Instances and Spot Instances, implementing Auto Scaling, and regularly auditing your environment, you can significantly reduce costs while maintaining the performance and reliability of your applications.

*All image credit goes to Boyd McGeachie , Video