devopsy.kinsta.cloud

Tag: rightsizing

  • Tips on Rightsizing to Reduce AWS Costs Now

    Tips on Rightsizing to Reduce AWS Costs Now

    In this business climate, everyone is looking to reduce costs. CFOs are reevaluating their software and infrastructure spend, and naturally, companies are looking for ways to optimize their AWS costs. In fact, we are now leveraging a major reason cloud is so compelling in the first place: you have more flexibility to control costs based on business needs. 

    How Do You Reduce Costs While Maintaining Performance? 

    A good starting point is to determine where most of the AWS spend is coming from. Once you know that, you can focus on factors that are causing the most charges and determine those services that can be scaled down and those that need the most resources. Depending on the service, there are many options, such as Amazon EC2 Reserved Instances (RI), Amazon EC2 Spot instances and resource rightsizing. In this blog post, I’ll cover rightsizing.

    There are some great AWS and third-party tools (I’m partial to nOps) to help you learn and analyze current usage patterns and make recommendations for rightsizing RI and Spot instances. In my experience, Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (Amazon RDS) and Amazon Simple Storage Service (Amazon S3) show up consistently in the top five items on the AWS bill. So, in this article, I’ll focus on rightsizing strategies with these three services.

    Rightsizing doesn’t just mean migrating from the old instance to the new generation instance. You’re probably not going to save lots of money with that approach. Rightsizing can help to identify resources that are clearly over-provisioned. Furthermore, many of the resources are provisioned using HashiCorp Terraform, AWS CloudFormation or an Auto Scaling group on AWS, so finding the rightsizing opportunities for ephemeral resources, and updating the automation not only reduces cost now but can also lower your future cost on AWS. 

    Optimizing Amazon EC2 and Amazon RDS Instances

    Hands down, Amazon EC2 spend is most-often the most expensive item on your AWS bill. Amazon EC2 comes with a robust set of options for CPU, memory and network I/O, ranging from 0.5GB of memory to 1TB. Having so many options can be a double-edged sword—how do you choose?

    You can choose the appropriate instance type based on your use case: Compute Optimized (for CPU-intensive workloads), Memory Optimized (for memory-intensive workloads) or Network Optimized (for enhanced network throughput).

    Some parameters need to be considered when choosing the optimal instances for your workload. Whether it is an HPC workload, or a simple Python Flask application or a Data Pipeline project, there is an Amazon EC2 instance type best suited for each of those workloads. 

    To select instances wisely, apply the most cost-effective Amazon EC2 instance type based on the network I/O and CPU utilization of the currently running instance. For example, if a t3.xlarge is configured for a Python Flask application and less than half of the memory is in use, the instance type has been over-provisioned for that workload. In such a case, a smaller instance size, such as a t3.small, is probably more appropriate.

    It’s also worth noting that, while most EC2 instances are provisioned with performance in mind, over time the utilization of the program can decrease, resulting in instances that are over-provisioned based on the current CPU/memory usage. I normally look at Amazon CloudWatch for instances that are not consuming all the resources that are currently available to each instance and, based on the historical usage, provide a recommendation to rightsize them. And, I can see the cost savings associated with the suggested changes.

    This approach can also be applied to Amazon RDS. The underlying architecture of Amazon RDS instances is very similar to that of Amazon EC2 instances. Both require an Amazon Virtual Private Cloud (Amazon VPC), security groups and a disk to run the managed database instance. 

    Optimizing Amazon S3 Storage Classes

    Amazon S3 offers a range of storage classes designed for different use cases:

    • S3 Standard for general-purpose storage of frequently accessed data.
    • S3 Intelligent-Tiering for data with unknown or changing access patterns.
    • S3 Standard-Infrequent Access (S3 Standard-IA) and S3 One Zone-Infrequent Access (S3 One Zone-IA) for long-lived, but less frequently accessed data.
    • Amazon S3 Glacier (S3 Glacier) and Amazon S3 Glacier Deep Archive (S3 Glacier Deep Archive) for long-term archive and digital preservation.

    You can determine the most appropriate storage class based on the usage of the objects in that bucket. As a result, you can cut the cost of storage of objects in the bucket and the cost of GET requests needed to download or transfer files from Amazon S3 to any other location.

    Getting Results Fast

    Uber, like many rapid-growth companies, was looking for ways to optimize AWS costs without slowing its high-velocity teams. They were able to save 15% of AWS costs in just 30 days using some of the strategies described above, as well as others. One of the keys for Uber is they are monitoring and optimizing costs continuously–not a one-and-done approach–because they have such high velocity with continuous changes to their AWS environment. They use nOps cloud management for this.

    Nick Cobb, senior engineering manager, Infrastructure Platform, Advanced Technologies Group at Uber, reports he’s able to “operationalize costs and get them in front of the engineers directly, saving 15% in the first month of implementation. In addition to providing reports for leadership and budget processes, our efficiency team can enact behavioral changes for R&D engineers typically used to throwing money at challenging problems.”

    If you’re interested in more details on the strategies that Uber has used, plus other cost-optimization strategies your organization can use right now, Nick will be joining me and AWS for a devopsy.kinsta.cloud webinar on continuous cost optimization on April 21. It’s a hot topic for so many organizations right now, so please join us.

  • Optimizing AWS Performance Over the Long Term

    Optimizing AWS Performance Over the Long Term

    Ask most folks how to optimize performance on AWS, and they’ll talk about things such as autoscaling and rightsizing.

    Those tools are certainly part of an effective AWS performance optimization strategy. On their own, however, they are not enough to guarantee performance and reliability over the long haul.

    That’s because tools and processes such as autoscaling and rightsizing only help you optimize the performance of applications that are running currently, or are about to be deployed. They do little to ensure that performance remains optimal—especially as cloud services, cost structures and architectures evolve.

    With that challenge in mind, let’s discuss how to get the most out of AWS performance over the long term.

    What is AWS Performance?

    Before delving into long-term AWS performance strategies, let’s make clear what we mean by performance. A high-performing application is one that:

    • Meets or exceeds user expectations regarding responsiveness and speed.
    • Meets or exceeds SLA requirements for availability.
    • Is able to scale seamlessly as performance requirements change.
    • Does all of the above in a cost-efficient manner.

    These aspects of a high-performing AWS application are important to emphasize because they reflect a holistic approach to performance. Sometimes performance is defined narrowly, in terms of application responsiveness and/or availability. Those are part of the performance equation, but in order to maximize performance over the long term, you need to think about other dimensions of performance, like the role played by scalability and cloud spend.

    Long-Term AWS Performance Considerations

    To optimize AWS performance over the long term, you must take a variety of factors into consideration.

    Handling AWS Service Changes and Upgrades

    AWS is constantly evolving. A performance strategy that works well today may not be as effective tomorrow if AWS introduces a new service or changes the features of an existing service.

    The challenge here lies not just in updating your app and your cloud configuration as AWS changes how a particular service works. It also requires constantly evaluating whether the service you are using is the best fit for your application.

    For example, think back about five years to when AWS Lambda (AWS’s serverless computing service) appeared. At the time, if you were running your apps inside virtual servers, you might have been able to improve overall performance by moving some of the workloads to serverless functions—not because anything in your virtual servers had become less efficient, but because better efficiency opportunities opened up with the addition of a new AWS service.

    Thus, being constantly aware of the various services in AWS and the opportunities they offer is key to optimizing long-term performance.

    Plan for Changing Cost Structures

    AWS not only changes its menu of service offerings frequently, it also updates pricing. Since cost optimization is one key component of performance optimization, you must ensure that your cloud workloads are running in the most cost-efficient way even as cost structures change.

    Staying aware of new cloud services (such as lower-cost S3 storage tiers) when they appear is one way to do this. But you also need visibility into the tremendously complex world of AWS pricing in all of its region-specific details.

    Plan Long-Term for OSS Dependencies

    Open-source software is something else that is constantly changing. If you rely on open source code to help run your AWS applications, you need to stay on top of changes in the projects you depend on.

    If you are using the same version of an open-source application or module that you built into your application when you first deployed it, you may be missing out on performance optimization opportunities that have arisen since then.

    Here again, constant awareness of and visibility into the complex open-source ecosystem is essential for ensuring that you are not missing out on optimization opportunities.

    Application-Specific Performance Monitoring

    Every application is a special snowflake and you need to keep that in mind when it comes to the way you track and optimize application performance.

    The metrics or KPIs that work for optimizing the performance of one app may not be ideal for another. The pre-deployment testing routines you use for applications might vary, too.

    So, make sure to tailor your monitoring strategy to your applications. Doing so is the only way to ensure you have the greatest, most relevant level of visibility into application performance over the long term.

    Backup and Disaster Recovery

    No matter how well your AWS workloads perform, sooner or later something will go wrong and they will fail. Whether the failure leads to a critical availability disruption or a mere hiccup hinges in large part on whether you have a backup and disaster recovery plan in place beforehand.

    For AWS apps, an effective backup and recovery plan entails more than just backing up data to storage buckets and downloading it to rebuild servers. It should also take advantage of opportunities like the ability to create image-level backups of virtual servers and restore them automatically to EC2 if disaster strikes.

    And of course, as AWS changes, you’ll need to keep your backup and recovery strategy in sync.

    Changing SLA Requirements

    Last but not least, keep your SLAs in mind. The SLAs you have to support today could change in the future—and by extension, so will the levels of availability and responsiveness that your users expect.

    For this reason, make sure your AWS performance strategy is capable not only of meeting the SLAs you currently have in place, but also adapting and scaling as SLA requirements become more rigid.

    Conclusion

    Although we tend to think of performance within the context of the present, it’s really a long-tail game. Sure, you can autoscale your workloads or use rightsizing tools to help choose the best type of EC2 instance for right now. But truly maximizing performance requires you to think longer-term and be prepared to react with agility as new performance challenges and opportunities arise.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi