Join Joseph Holbrook for an in-depth discussion in this video Monitoring EBS storage bottlenecks, part of Amazon Web Services: Analysis.
- [Instructor] Monitoring EBS Storage. EBS is Amazon's Elastic Block Store. Amazon EBS provides persistent block storage volumes that use with Amazon EC2 instances in the Amazon Cloud. Amazon is Elastic Block Storage, it's also network block storage as a service. EBS volumes can attach to any EC2 instances in the same Availability Zone.
They're also scalable in that zone as well. Designed for five 9s of availability, meaning that your data is there when you need it. Over two million volumes are created daily and that's an impressive number of volumes. EBS volume types that you should know. First is magnetic, meaning that this is your typical spinning disk. SSD General Purpose, these SSDs are generally what you'd want to use for typical work loads.
And SSD Provision IOPS you would typically want to use where you need to have the highest level of service and performance. EBS Magnetic. HDD are basically good for infrequent data access. So, for typical workloads that you may want to place on Magnetic would be for applications like HR perhaps. Or perhaps a production app that doesn't require the highest performance SLA.
With HDD you receive 100 IOPS best effort, 40 to 90 megabits throughput, as well as latency around 10 to 40 ms for reads and two to 10 ms for writes. When we speak about SSDs we want to understand that the general purpose, also known as GP, solid-state drives are good for most workloads.
Typically most customers like to use SSD General Purpose because it's a good balance between the IOPS provisioned and the SSD types that you have. 100 to 10,000 IOPS best effort. There is a burst bucket to 3,000 IOPS, which is 30 minutes. And 160 megabits per second throughput. Latency is an average of five ms and for the exam please do remember those numbers.
When we speak about Amazon EBS SSD Provisioned, this is your highest level of service with AWS. These are solid-state drives, good for mission critical, where as you have SLAs where you need to maintain the highest level of performance for that application. This will have the lowest latency as well. You'll also receive 100 to 20,000 IOPS. There's also a feature called a burst bucket again, as well, and that's 3,000 IOPS, 30 minutes guaranteed.
And remember bursting is where you have a workload that spikes in requests or traffic perhaps. 320 megabits throughput as well as the same latency of five ms. What are some EBS performance factors? Now, when we talk about EBS IOPS is typically going to be your number of requests going in and out of the Amazon backend of the cloud. So, for example, the number of read and writes.
Latency, that is going to be the average time that you send a request, for example, and the time that the request comes back. And throughput is essentially how much information can you send and have it received appropriately at the other end? Some performance factors that you would want to consider with your EBS volumes would be references, does that application need to have a specific link that it references? Buffer size.
I/O size, up to 128 K, and just remember that you can use smaller increments, as well, so if your application only requires 64, that is fine as well. Cache size and then queue depth is essentially how much requests are pending for that specific volume. Now, there's two forms of cloud metrics. When we talk about CloudWatch metrics, we need to understand that basic is going to provide you the views that you might require, your volumes, specifically inputs and outputs.
Detailed is going to be more focused around provisioned IOPS, so it's very granular in the sense that it's one minute intervals versus five minutes. Period request is also added to detail as well. When we talk about performance, it's important that you also map your performance. Basically what that means is that you understand how your application is sending requests and receiving requests, and this should help enable you to look at the factors that do effect your performance.
On this specific chart here, we see that we have mapped specific workloads to specific volume types and specific instance types. So, performance wise, please correlate your performance requirements to the right EBS volume. Here are some best practices when we speak about EBS. Consider parallelism using threads. So, typically resources do respond better when you have specific requests being sent in parallel.
Think about it as a perspective of filling up a bucket with two hoses instead of one. Use EBS, optimize volumes. Typically EBS optimized volumes will be optimized by Amazon with a template, will maintain a specific performance level, use the correct instance type will also be something that should enable you to get the best performance.
Use the proper file systems and structures as well. When we talk about EBS Optimized volumes, just remember that these optimized volumes and instances do remove confusion. Amazon has specifically created these to ensure that you get a specific quality of service. Network traffic and EBS traffic are shared. So, you may want to understand that Amazon has really created a template to help enable the optimization for you.
Optimized configured stack, that provides the additional and dedicated capacity between EC2 and EBS. 500 and 1,000 Mbs dedicated bandwidth. And performance-sensitive production databases, PIOPS as they're known. These are typically production databases, that again Amazon has optimized the template to perform in most workload scenarios. Here is a test tip.
EBS volumes can only be attached to one instance at a time. So, please do remember that for the exam.
- AWS performance bottlenecks
- Monitoring EC2 instances with CloudWatch
- Monitoring EBS storage bottlenecks
- Monitoring RT53
- Optimizing the environment
- Optimizing RDS database services
- Consolidated billing best practices
- Identifying application issues
- Customizing CloudWatch metrics and dashboards
- CloudFront edge caching