If Amazon could add the auto-scaling feature that exists in RDS to the EBS volumes for EC2 or EKS, it would be beneficial. This capability is currently missing and would greatly enhance scalability.

I see a need for improvement in the scalability of Amazon EBS. If I need something more scalable, I rely on another storage solution like S3. I also think the pricing of EBS is high. It's very expensive to store a lot of data.

There is a concept called Snapshot, which is a backup of the entire EBS volume, however, the cost is quite high. In EBS, standardizing storage can be expensive as there is no optimization option. Deployment is not easy as it requires server downtime to map newly created volumes, impacting operations during additional volume additions.

I want to add a firewall in the free tier, and there is a need for more services to reduce costs, especially if many people use it as freelancers. AWS services could improve by including services in the FreeTier, like Route 53 domains or SSL certificates. When we use certain applications, they incur high charges. If we add services in FreeTier, it could be beneficial. It's based on my company. Regarding EBS, if an instance is terminated, the volume is also deleted, which leads to data loss. This is why I copy files between volumes.

I would like EBS to have no limitations, similar to stream-like block storage, which can accommodate an unlimited amount of sales. EBS has limitations that could be improved.

Amazon EBS could improve by offering immutability of the data. This feature is not certain, but it could be beneficial.

The main challenge with Amazon EBS is cost management, as it is a high-performance volume. Sequencing and IOPS relative to cost are also areas of concern. 

Additionally, data durability can be an issue, with risks of accidental deletion or corruption.

There is room for improvement in AWS support. They have technically strong people. However, sometimes there is a lag in providing technical solutions to customers.

There is a challenge of intermittent reachability with instances, where the product is sometimes available and other times not, which affects the development environment's stability. Manual resizing of storage capacity is required, which could be simplified. 

Additionally, instances running on Debian experienced more intermittent failures compared to those running on CentOS.

I am still in the learning process regarding Amazon EBS, so I'm not entirely sure what specific improvements are needed. It has been good enough for my current learning and usage.

I do not have anything in mind for improvement at the moment.

There are no current recommendations for improvement. However, implementing more AI-based capabilities could enhance the service.

There is room for improvement in terms of file storage. Recently, we had a scenario in which, in a file share, we had increased the IOPS capacity; this was for the production environment. We had previously done that, but for some reason, it went down. We weren't able to access that specific drive or volume. So, because it was production, it impacted our clients also.

We had an AWS support call. Basically, they also did the same steps which we were requiring. We had requested them to decrease the IOPS capacity and make the volume available so that at least the customer impact would be reduced, but we had to wait around, like, more than 300 GBs. So, for volume recovery, we had to wait around eight hours. That took major downtime. So, it was just a small task; we had done it for increasing dial-ups, but we were not sure what went wrong, and even AWS didn't have an answer. So we had to wait a full eight hours for this to be available from the snapshot, and then we were able to attach it again. That was a major downtime or an area on which AWS could improve.

There is a lack of awareness and knowledge about Amazon EBS among potential users, which results in underutilization. Additionally, there might be a lack of marketing highlighting the capabilities of EBS, which could improve its popularity and utilization.

I feel that there are some concerns when it comes to the accessibility area of the product where improvements are required. The product should be accessible for any kind of main service. For better accessibility, users can choose Amazon NFS over Amazon EBS (Elastic Block Store). Amazon NFS can be used for multiple services. Amazon EBS (Elastic Block Store) can be used for a single point of service.

It is hard to access EBS volumes in different Availability Zones (AZs) because most EBS volumes are created in a single AZ. This can be a problem for workloads that require high availability or performance.

I would recommend that Amazon improve the accessibility of EBS volumes across AZs. This could be done by making it easier to create EBS volumes in multiple AZs or by providing a way to automatically replicate EBS volumes across AZs.

Currently, if you want to get the ability to access EBS volumes in different AZs, you need to use a different service.

Amazon EBS is a single product or service. 

I have a couple of issues related to Amazon EBS from the clients regarding the use of space, which have not been resolved. If a customer increases from one TB to two TB and wants to go back to needing one TB instead of two TB, then there is a long process involved to do so currently, even though going from one TB to two TB was very easy. Returning back to one TB from two TB or reducing the space is a problem in Amazon EBS, like S3. S3 is a scalable tool, meaning that you can increase or decrease its size. In Amazon EBS, it is difficult to reduce the space chosen by the customer. The cost increases the moment the size of the storage increases, and I will have to pay for two TB of the tool instead of one TB. If my clients want to change something in the tool, they need to get approval from their company, making it a long process. It would be better if Amazon EBS had the same features as S3 since we could easily revert back to one TB from two TB easily, which is not possible right now.

If I place Amazon EBS in South Asia, there will be an increase and decrease in terms of costs. Cost optimization is one challenge I have faced since placing Amazon EBS is the reason why basic costing is applicable. S3 is very cheap compared to Amazon EBS, and because of this, some clients request S3 and not Amazon EBS.

Depending on the requirements of my clients, I may want extra features in the product's future releases. Scalability is very important for our company since the tool's availability is already there. Most often, we use the product's scalability feature apart from the security feature. Amazon KMS, along with CRM, is a feature we deal with in our company, areas where we face issues due to low latency. If I want access to data in ESB, then it is dependent on the encryption method which I allocate in Amazon EBS.

Amazon could improve Amazon EBS (Elastic Block Store) by making it faster.

The features could be improved.

One area for improvement is the ease of scaling down the EBS volume. Having more flexibility in resizing, especially scaling down, would be beneficial. Automating the process of attaching a new volume to an existing EC2 instance would also be a valuable enhancement.

One of the major issues in the tool arises whenever it handles a large amount of traffic in the system, making it an area where improvements are required.

It is not very easy to increase the size. You can give a request to increase the size, and the size will be increased. But to actually make the EC2 machine see the newly increased size is a little difficult. You have to log in to the EC2 machine, do some commands over the terminal, and only then only it would be able to see the newly increased EBS storage.

It would be good if the solution added a button to increase the size and make the EC2 machine recognize the increased capacity of the EBS.

Amazon EBS performs well but it could improve.

There are limitations in sharing resources across multiple regions and availability zones. I recommend improving EBS by introducing multi-availability zone support to enhance its functionality. 

The initial setup is not easy.

There are not many technical things that need improvement in EBS. It has a very long history and is AWS's first product. Its main flaw is the costliness.

The product data encryption feature needs improvement.

We can directly attach any of the servers. Since the file systems of different operating systems, like Linux and Windows, are different, we cannot merge them. It would be better to analyze and find a way to merge both the file systems of Linux and Windows.

The setup could be easier. 

Amazon EBS needs to improve its user interface for data transactions. 

I think performance can be improved. It's like feeling latency when you compare apples to apples as far as what you have in a SAN on-site, on-prem versus an EBS volume in the cloud. If you want to get rid of the latency, then that's where these costs start to really add up. 

On the onset, it's cheaper to get started. It has every bit of capability and availability you would expect and even more than your own environment. If you're trying to get to the same or a higher level of performance, you have to bite the bullet and pay through the roof.

The ability to administer it, use it, set it up, install it, and operate it is all as easy or easier. You get the flexibility to change, snapshot, and all of the same things you could do with even more capabilities. But if you have to get the same or improve your performance, it gets exponentially more costly.

The product has volume limitations.