This content originally appeared on DEV Community and was authored by Rohini Gaonkar
Sharing with you typical cost savings tips I have shared with customers as a Solutions Architect. These are some of the obvious (but often ignored) items that customers can do to save cost as they build and grow on Amazon Web Services (AWS).
- 1. Backup frequency and retention in services like Amazon RDS
- 2. EBS Snapshots & Volumes
- 3. Storing Logs in CloudWatch, without ever purging
- 4. Data Transfer
- 5. Unused Metrics & Alarms
- Summary
Let's talk about some of the commonly ignored ones :
1. Backup frequency and retention in services like Amazon RDS
Sometimes customers want to be extra cautious while taking database backups. This is great compared to being completely ignorant and not taking backups.
True story: couple of my customers were taking manual snapshots of RDS instances every 4 hrs, storing them for 15 days, and each backup being more than 500 GB. Plus there was 1 automated snapshot everyday retained for 7 days. Additional backup storage for your provisioned database storage is billed at $0.095 per GiB-month.
If you just do a rough calculation on above items, you can estimate that they must be paying 100s, if not 1000s, of dollars on unnecessary backups that were useless in case of a disaster, if any. No one would be using a 13th days old 2nd backup to restore database, the data already was too old for the system to be up and running.
Hence, the frequency and retention of backups must be selected depending on the RTO/RPO discussed with your business stakeholders.
Read more information on the Disaster Recovery (DR) objectives in the AWS documentation
2. EBS Snapshots & Volumes
2.1. Stopped Instances
It is a common saying for EC2 - when you stop the instances, you stop paying. Yes, this is correct, but only for the compute and data transfer costs. If you have an EBS volume attached to the EC2 instance, you will continue to pay for storage.
If you don't need the EC2 instances again, its good to backup data in cheaper storage like Amazon S3 bucket or simply create an Amazon Machine Image. Snapshot storage is based on the amount of space your data consumes in Amazon S3. Because Amazon EBS does not save empty blocks, it is likely that the snapshot size will be considerably less than your volume size.
Moreover the costs are slightly lower. For example, in US-EAST-1 :
EBS Volume (gp2) - $0.08 per GB-month
EBS Snapshot - $0.05 per GB-month of data stored
2.2. Amazon EBS 'DeleteOnTermination' attribute
By default, Amazon EBS root device volumes are automatically deleted when the instance terminates. However, by default, any additional EBS volumes that you attach at launch, or any EBS volumes that you attach to an existing instance persist even after the instance terminates.
A lot of times customers are unaware of this and end up with 'Available' volumes in their account which are left over by terminated instances, ultimately adding to your EBS cost. This gets more troublesome when you have AutoScaling instances scaling in and out all the time.
This behavior is controlled by the volume's DeleteOnTermination attribute, which you can modify. You can change the value of the DeleteOnTermination attribute for a volume when you launch the instance or while the instance is running.
To verify the value of the DeleteOnTermination attribute for an EBS volume that is in use, look at the instance's block device mapping. To query instances with this attribute as false, run following command:
aws ec2 describe-instances \
--filters "Name=block-device-mapping.delete-on-termination,Values=false"
For more information and if you want to modify this, see View the EBS volumes in an instance block device mapping.
2.3. Recent Announcements from AWS re:Invent 2021
You can now use 2 new features from AWS :
- EBS Snapshot Archive, a low-cost storage tier to archive full, point-in-time copies of EBS Snapshots that you must retain for 90 days or more for regulatory and compliance reasons, or for future project releases.
- EBS Snapshot Recycle Bin - lets you set up rules to retain deleted snapshots so that you can recover them after an accidental deletion.
3. Storing Logs in CloudWatch, without ever purging
Amazon CloudWatch Logs is awesome. You can use it with services like X-ray and CloudWatch ServiceLens for better observability of your application.
However, it is important to note that default retention setting is ‘never expire’. This means all that log data from months ago which you may not require now is still stored and costing you money.
Purge or export your CloudWatch Logs to Amazon S3 to save on cost for long term.
You can configure how long to store log data in a log group. Any data older than the current retention setting is deleted automatically. You can change the log retention for each log group at any time.
4. Data Transfer
4.1. NAT Gateway to S3 bucket
You can use a network address translation (NAT) gateway to enable instances in a private subnet to connect to the internet or other AWS services, but prevent the internet from initiating a connection with those instances. This is a great security feature that is highly recommended to customers.
If you create a NAT gateway in your VPC, you are charged for each “NAT Gateway-hour" that your NAT gateway is provisioned and available. And the data processing charges apply for each Gigabyte processed through the NAT gateway regardless of the traffic’s source or destination.
Many miss out the important note mentioned on its pricing page :
'To avoid the NAT Gateway Data Processing charge in this example, you could setup a Gateway Type VPC endpoint and route the traffic to/from S3 through the VPC endpoint instead of going through the NAT Gateway. There is no data processing or hourly charges for using Gateway Type VPC endpoints.'
So, if you have used a NAT Gateway for all your traffic, including to and fro from Amazon S3 bucket you end up paying a lot of data transfer cost.
Instead use a Gateway Endpoint to route the traffic to/from S3. And the NAT Gateway will route rest of the traffic.
For this, simply attach a Gateway endpoint to your VPC and update the Route Table for private subnets. The route table will take care of forwarding the requests automatically. Following is architectural representation of same:
Please note, S3 access through gateway endpoints is supported only for resources in a specific VPC to which the endpoint is associated. S3 gateway endpoints do not currently support access from resources in a different Region, different VPC, or from an on-premises (non-AWS) environment. However, if you’re willing to manage a complex custom architecture, you can use proxies. In all those scenarios, where access is from resources external to VPC, S3 interface endpoints access S3 in a secure way. Check out the blog Choosing Your VPC Endpoint Strategy for Amazon S3
4.2. Chatty applications
Some customers have chatty applications that talk to each other a lot which pile up the Data Transfer cost for inter-region.
True story: One of my customers' managed this by making silos of their architecture per AZ. So, LBs will talk to instances in only one AZ. They managed routing of customer segments and failover between AvailabilityZone with Route53. Ofcourse this is not always possible and not easy to manage.
There are many different ways of handling this depending on your use-case so I recommend reaching out to your AWS Solutions Architect(SA) to help dive deep into this. They can help you if your spend is significantly high, thank me later. If you don't know who it is and if you wish to be connected to our Sales/Solutions Architect teams, submit a request here
5. Unused Metrics & Alarms
By default, your EC2 instance is enabled for basic monitoring with 5-min interval. You can optionally enable detailed monitoring, then the Amazon EC2 console displays monitoring graphs with a 1-minute period for the instance. This is great as you get additional information.
However, it is important to note that detailed monitoring is charged. The number of metrics sent by an EC2 instance as part of EC2 Detailed Monitoring is dependent on the instance type. Most commonly used instance types have atleast 7 metrics. So the pricing would be Monthly CloudWatch Metrics Charges @$0.30 per custom metric = 7 * $0.30 = $2.1 per instance. This can pile up quickly.
So, ensure you are enabling detailed monitoring for instances that you require additional information and those instances are not simply left in stopped mode.
Similarly, create alarms only when they are required and used frequently.
Summary
In this blog, we learnt simple yet effective ways of optimising cost in your AWS account and stop the wastage.
Ofcourse this is not an exhaustive list, so please feel free to add any more tips you have to benefit everyone. Hope some of these help you make the right decisions for your workload. Looking forward to your feedback.
Do let me know if you found this helpful, and would like to see more cost saving tips/reminders.
This content originally appeared on DEV Community and was authored by Rohini Gaonkar
Rohini Gaonkar | Sciencx (2022-02-09T08:04:27+00:00) How to stop overspending – AWS Cost Optimisation tips. Retrieved from https://www.scien.cx/2022/02/09/how-to-stop-overspending-aws-cost-optimisation-tips/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.