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.

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.

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.

The features could be improved.

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.

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.

Amazon EBS performs well but it could improve.

The initial setup is not easy.

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.

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 has volume limitations.

The setup could be easier. 

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

The product data encryption feature needs improvement.

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.