Comments on: AWS Elastic Block Storage (EBS) – Can We Get It Truly Elastic?

By: Peter Zaitsev

Peter Zaitsev — Thu, 13 Dec 2018 13:56:41 +0000

In reply to MF. In the database world we are not particularly fond running databases on the NFS and similar filesystems. I agree though for some workloads it can be possible but yet it does not offer the same flexibility as using the proven filesystem of choice on the block device

By: MF

MF — Wed, 12 Dec 2018 19:12:55 +0000

You can look into EFS, which sounds like it more or less does what you want https://aws.amazon.com/efs/

It has been a couple of years, but when we implemented EFS when reading/writing a few large files, the performance was sufficient for us. When we implemented a system that had a lot of small reads/writes to files we experienced a lot of latency with the file access and reverted back to EBS.

By: Peter Zaitsev

Peter Zaitsev — Wed, 12 Dec 2018 15:20:30 +0000

In reply to renato. Yeah. This is a challenge I think especially if you're increasing storage capabilities and your change was not enough :)

By: renato

renato — Wed, 12 Dec 2018 14:24:28 +0000

That would be amazing but I do not dream that big. I would be happy if at least they would get rid of the hard limit of not be able to make further storage modifications for six hours or while the DB instance status is storage-optimization that affects both EBS and RDS. It would not be truly elastic yet but it would be better than now.

By: Bajrang Panigrahi

Bajrang Panigrahi — Wed, 12 Dec 2018 12:56:55 +0000

This is an amazing feature request to have in AWS, lot of customers running their workload on io1 and gp2, will be beneficial if this truly turns out on the actual size of the disk consumed.

The one thing, which comes on top of my head is, it might relax our capacity planning efforts to some extent, on each cycle. Also a lot of cost-savings on AWS pay-as-you-go model, for Elastic Storages too.