Questions tagged with Amazon Elastic Block Store
Content language: English
Sort by most recent
Need help with Autoscaling and warm pool
We are currently testing a scenario where we will run two Ec2 instances (Running custom application) at a time in autoscaling group. One will be hot and another will be warm ready to go. When the active server goes down due to application failure, the autoscaling will bring the warm one to the active state. While the active server is up and running we are taking snapshot of the attached EBS volume every hour. Is there a way when the active server goes down and the warm one comes up, it has the EBS volume attached and mounted to it with the latest snapshot? I am aware of triggering a Lambda and have it attached an EBS volume to the instance but then I am not sure how will I mount it when the warm pool ec2 instance is in autoscaling:EC2_INSTANCE_LAUNCHING state? The application will be running on RHEL8 AMI. Any guidance, suggestion are appreciated. Thanks
Windows Instances launched using RegisterImage API are showing PlatformDetails as "Linux/UNIX" and are not booting - when the EBS volume snapshots are created using StartSnapshot() API
Steps to reproduce: 1. Create a Windows Instance with a single EBS volume (aka root volume) 2. Take a snapshot of the root volume (Snap-1) 3. Create a new EBS snapshot (Snap-2) using `StartSnapshot` API with the Snap-1 as parent snapshot. 4. On Snap-2, issue `CompleteSnapshot` API with 0 changed blocks. 5. Create an AMI using `RegisterImage` API with Snap-2 as the root volume and same block device mapping as the original instance. 6. Any instance created using the AMI has "Linux/UNIX" in Platform Details and does not boot. It was observed that this issue occurs only if the EBS snapshot used is created using `StartSnapshot` API. For example, if Snap-1 was used in the `RegisterImage` call, any instance created using the AMI is showing platform as "windows" and is booting up properly. Question: Is there any way to create a Windows AMI (that creates bootable windows instances) using EBS snapshots created via `StartSnapshot` API or is there any workaround for this ?
Attachment order for EBS volumes as /dev/nvme devices
Hello, We started seeing (from what I can find, our old instances from months ago don't exhibit this behavior) that the order of attached EBS volumes changes after first reboot. For example, we attach (using AWS console): vol-011117cfde1966e5f as /dev/sdf vol-0222290fbbd8a3b79 as /dev/sdg and they immediately show up as /dev/nvme1n1 and /dev/nvme2n1. After reboot, they change order, where vol-011117cfde1966e5f becomes /dev/nvme2n1 and vol-0222290fbbd8a3b79 becomes /dev/nvme1n1. This order becomes permanent even if you reboot again any number of times. In the console, vol-0111* is still listed first alphabetically as sdf and vol-0222* second as sdg. I'm seeing this behavior on CentOS 7.9, RockyLinux and AlmaLinux 8.6 and RockyLinux 9.0, so it doesn't seem to be specific to any operating system. I tested with t3a and m6i instance types. I am aware that we can mount filesystems using UUIDs to ensure order. I also know that https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nvme-ebs-volumes.html says "The block device driver can assign NVMe device names in a different order than you specified for the volumes in the block device mapping." The question is whether it's expected behavior that this order changes after first reboot only, and then doesn't change again?
large 2nd disk volume not mounted, unable to access 2nd disk volume.
I have an ECS instance (AWS Linux, t2.xlarge) with a a large 2nd disk volume (block device: /dev/sdb 80 Gib) When my instance is started, the 2nd disk volume is not mounted onto any directories. I ssh into my instance as a non-root user, and tried to mount the /dev/sdb, but I am not allowed to do so because I do not have root privileges. What should I do? How can I access my 2nd disk volume? Could there be an issue because of the large disk size? Also, is there a way to request for root privileges for my instance? Thanks.
Understand RDS PIOPS, EBS IO and EBS BYTE Balance (%) ?
I have a Posgrest RDS instance using r5.xlarge type. 500GB SSD gp2 type. As I understand, with 500GB gp2, i got a baseline with (3 x 500) = 1500 IOPS. Now I need to increase it to 2500 IOPS, what should I do ? As documents said, I have 2 option (please correct me if I'm wrong) : 1. I can increase the size of DB to ~ 850 ( 3x850 ~ 2500 IOPS) 2. Change the disk type to IO1 and set PIOPS = 2500. 500GB Gp2 cost 115$ per month With option 1, I has to pay 195$ per month. With option 2, I has to pay 115$ + 500$ ( 0.2 * 2500) = 615$ per month. I know that Gp1 Provide more throughput and SLA level, but do I really need to use io1 + PIOPS? Which case should I use it (assume that I just need 99% SLA) ? And one more question, assume that I have RDS with 1000 GB Gp2, so the baseline is 3000 IOPS, what happen if I change it to io1 and set PIOPS to 1000? Now what is the baseline IO of my RDS? 3000 or 1000 or 3000 + 1000 ? ------ I saw EBS IO Balance (%) and EBS Byte Balance (%) in CloudWatch metric, as I understand, it's my reserved balance of (IO and Throughput), but how do I know the absolute value of it ? (So I can count how many IO balance remaining) Let say I have RDS with 1000GB Gp2, as I understand from documents, I got 3000 IOPS, if my RDS used < 3000 IOPS, it will reserved the IO credits to my balance, but what is the maximum balance that I can reserved? I couldn't find the documents said about that. Is there anyway to monitor how RDS consume my IO ( independently of AWS ) ? Thank you so much.
Do I need to extend EC2 file system after resizing?
I increased the size of a gp2 EBS attached to a Linux EC2 instance from 8GB to 25GB. From the documentation, I thought I would then need to extend the Linux file system. However, I think that the output of `lsblk` is telling me that it has happened automatically and I do not need to do anything. I have pasted the output below. I think it is saying that I have a 25G EBS volume called xvda and that has 3 partitions in it. One of them, xvda1, is 24.9G. If that is correct then presumably I do not have to do anything more. I can just use the extra space. Please correct me if I am wrong. ``` ubuntu@ip-172-31-32-80:~$ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 25.1M 1 loop /snap/amazon-ssm-agent/5656 loop1 7:1 0 43.9M 1 loop /snap/certbot/2192 loop2 7:2 0 55.5M 1 loop /snap/core18/2409 loop3 7:3 0 55.6M 1 loop /snap/core18/2538 loop4 7:4 0 62M 1 loop /snap/core20/1593 loop5 7:5 0 62M 1 loop /snap/core20/1611 loop6 7:6 0 79.9M 1 loop /snap/lxd/22923 loop7 7:7 0 103M 1 loop /snap/lxd/23541 loop8 7:8 0 47M 1 loop /snap/snapd/16010 loop9 7:9 0 47M 1 loop /snap/snapd/16292 xvda 202:0 0 25G 0 disk ├─xvda1 202:1 0 24.9G 0 part / ├─xvda14 202:14 0 4M 0 part └─xvda15 202:15 0 106M 0 part /boot/efi ubuntu@ip-172-31-32-80:~$ ```
AWS MGN , EBS Volumes
Hi Team, we are doing a lift & shift migration using AWS MGN. In on-Prem we have 1 TB storage attached to a server in that only 250 GB is utilised. So here during replication , AWS MGN agent created 1 TB EBS volume.Is there any way to customise the EBS volumes that are created by the MGN during replication or during cutover phase ?? . Why we need to pay for unused volume ? Can you please guide us providing a right solution.
Low throughput on EBS gp3 volume
Hi everyone, I'm having a very low read throughput on a gp3 volume that I'm using. The volume is set to the standard 3000 IOPS and a max throughput of 125MB/s. However, Cloudwatch reports only 60 Ops/s and a read bandwith of 7000 KiB/s (there is no write). What could be the reason for this?
instance keeps crashes in intervals after extending ebs volume
My EC2 instance keeps crashing (unreachable) after I extended the EBS volume. When I reboot the instance, it comes back up and then become inaccessible after 24-48 hours and the circle continues. Please help. I need it to stay up continuously like before
Can I reduce an over-sized EBS volume?
Amazon Linux 2 EC2 instance with an EBS GP2 boot volume that has one GPT partition and XFS file system: The EBS volume was extended from 1.5TB to 3TB. Turns out this is greater than necessary. The Linux partition and XFS file system were *NOT* extended to use the additional volume capacity; the partition and XFS file system are still 1.5TB. Can I reduce the EBS volume to, perhaps, 2TB without damaging the XFS file system? I am aware that I can replace the volume using a snapshot, etc. I'm looking to avoid that effort if possible.