Browse through the questions and answers listed below or filter and sort to narrow down your results.
How do I report a bug present with EBS snapshot feature in "AWS console"?
I found likely bugs in AWS console when using EBS snapshot feature. How do I report a defect or bug in AWS? Following is the issue. I am allowed to choose even a "Terminated" EC2 instance while attempting to create a snapshot. Further it incorrectly shows an EBS volume belonging to another EC2 instance which is running(not terminated) for the terminated EC2 chosen for snapshot generation. First of all it is a bug to allow a terminated instance to choose from a list of EC2 instance to create an EBS snapshot and then showing an EBS volume of other EC2 instance is second bug.
How to migrate only postgres data using EBS volumes
Our application stores metadata in postgres database. We are using AWS ebs volumes for postgres data for persistent storage. We attach and detach this EBS volumes to AWS instance when needed. AWS instance is destroyed when not needed and will create new one when needed. EBS volume will be attached when new instance is created. The problem is, when ebs volume is detached postgres version is 9.x. While attaching EBS volume to new instance, postgres version in the new instance is 11.x. How to migrate the postgres data from 9.x to 11.x in the ebs volumes where new instance has 11.x version postgres version installed.
Instance upgraded from t2 to t3 is not booting up
Hi, The instance in question is t3.medium instance in eu-west-1b region. The instance has been upgraded from T2 to T3 a couple weeks ago. It is set to start and stop daily but in the last 2 weeks - it happened the 2nd time already it is not able to boot. This problem is not daily but I would say weekly. The instance was fine yesterday but today it got stuck. It passes the network check but instance status check fails, it is showing as Running but I cannot remote to it. It's a RHEL8.4 instance created from AWS AMI RHEL_HA-8.4.0_HVM-20210504-x86_64-2-Hourly2-GP2 (ami-0d81e223398b63904) It must be a rather random issue because as I said the instance was starting and stopping fine in the previous days but from time to time a glitch happens. Is this something to do with ENA or NVME or both? Please advise
Understanding RDS throughput limits
I have trouble understanding what throughput limit(s) my RDS instance is supposed to have. Based on this [blog post](https://aws.amazon.com/blogs/database/making-better-decisions-about-amazon-rds-with-amazon-cloudwatch-metrics/): > An Amazon RDS instance has two types of throughput limits: Instance level and EBS volume level limits. > You can monitor instance level throughput with the metrics WriteThroughput and ReadThroughput. WriteThroughput is the average number of bytes written to disk per second. ReadThroughput is the average number of bytes read from disk per second. For example, a db.m4.16xlarge instance class supports 1,250-MB/s maximum throughput. The EBS volume throughput limit is 250 MiB/S for GP2 storage based on 16 KiB I/O size, and 1,000 MiB/s for Provisioned IOPS storage type. If you experience degraded performance due to a throughput bottleneck, you should validate both of these limits and modify the instance as needed. My RDS instance is of db.r6g.8xlarge type, which according to https://aws.amazon.com/rds/instance-types/ has 9000 Mbps (= 1125 MB/s) EBS dedicated bandwidth. On the other hand, according to https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html the underlying gp2 volume (5TB size) has a 250 MB/s throughput limit. So how are these two limits applied? Should I be able to reach close to 1125 MB/s or am I restricted to 250 MiB/s because of gp2 volume limit? In CloudWatch, during bulk write operations I have observed Total (Read + Write) Throughput momentarily reach ~ 1000 MB/s but mostly it was steady around 420 MB/s, i.e. somewhere in between the two limits.
Data Transfer charges for creating volumes from another availability zone
Consider this scenario: If I have a snapshot of a volume in us-east-2a and I modify its permissions such that it would be possible to create volumes from said snapshot in another account. If I create a volume from it in us-east-2c (same region, different availably zone), would that incur AWS data transfer charges?
launch template suddenly stopped working
Hi, I have a simple launch template that fires up an instance based on an AMI built through Image Builder, which also distributes the ami to the template as a new version. All was working fine until yesterday when a colleague tried to launch an instance and it wouldn't proceed unless I put a value in for IOPS on the gp3 root volume. This is new. Previously it just went with a default for gp3 (3000) - now it has to be specified. I checked previous known good versions of the template, and they also displayed this change in behaviour - this rules out a change on my side. I also checked cIoudtrail to see if anyone else had changed anything - they hadn't. I have got my stuff working again, by removing 'gp3' as a volume type, but this seems to be an undocumented breaking change that I only picked up due a bit of ClickOps. What gives?
Accessing AWS ENRON dataset
I am trying to access and use this enron dataset for academic research: https://aws.amazon.com/datasets/enron-email-data/. I tried to create an EBS volume and connect it with the dataset using the snap id listed on the page. However, I am not able to find this snap id when I try to create the EBS volume. I am not sure whether I am doing it the right way or whether there are other ways to access the dataset. Please guide me.
SSH broken as of 1st March
We have an automated codepipeline that builds packer images based on amazon linux AMI updates. This pipeline has worked flawlessly for several years. Yesterday however it broke with : ==> amazon-ebs: Waiting for instance (xxxxxxx) to become ready... ==> amazon-ebs: Using ssh communicator to connect: xx.xx.xx.xx ==> amazon-ebs: Waiting for SSH to become available... ==> amazon-ebs: Error waiting for SSH: ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain We have changed nothing , something in the base AWS Li2 image has broken this we think.
The EBS snapshot policy does not create a tag from the instance
Hi, I have created EC2 instances id-1 and id-2, in which I have created Tags: for: id-1 Name = Instance1, backup_daily = yes for: id-2 Name = Instance2, backup_daily = yes. I have created an EBS snapshot policy: instance Target instances with these tags: backup_daily: yes. Copy tags from source = yes Variable tags: instance-id: $ (instance-id); timestamp: $ (timestamp) Based on this lifecycle policy, a snapshop will be created for both instances. In the case of instance id-2, snapshop tags are created: instance-id: $ (instance-id); timestamp: $ (timestamp) Name: Instance2 In the case of instance id-1, however, only it will be created in tags instance-id: $ (instance-id); timestamp: $ (timestamp). The name = Instance1 tag is not created. Where there may be a problem that the name tag is not created in the snapshot even though I have a Name tag in the instance, the lifecycle has "Copy tags from source = yes" and the same snapshot policy a Name tag in one case and no in the other. Where is the problem? Regards Eduard
Why is there a cost of IOPS-month provisioned for activated ebs on stopped ec2?
Although ec2 was stopped, IOPS-month provisioned continued to be charged. I know that GB-month of Provisioned IOPS SSD is charged because ebs is activated, but I am not sure if IOPS-month provisioned occurs because I am not using the ebs. (Since input and output did not occur, it is correct that iop should not occur, right?) Why is there a cost of IOPS-month provisioned for activated ebs on stopped ec2?
Is there a way to identify an EBS Volume inside a Linux EC2 instance using its volume ID ?
We are working on a use case where we need to map the disk label within the instance to the corresponding Volume ID in EBS. While performing some validations on some AMIs, we found that there is a difference between the behavior for Windows and Linux We have observed that the requirement we need is present in case of Windows (AMI Used: Windows_Server-2016-English-Full-Containers-2022.01.19) The following query yields the required result. Here the serial number of the disk is mapping to the EBS volume id The device driver for this instance was the AWS PV Storage Host Adapter ``` PS C:\Users\Administrator> Get-WmiObject Win32_DiskDrive | select-object -property serialnumber,index serialnumber index ------------ ----- vol0b44250cf530aa7f3 0 vol0f38be626e3137975 1 vol0bdc570ca980fb5fb 2 ``` However in case of Linux instances (AMI Used: amzn2-ami-kernel-5.10-hvm-2.0.20220121.0-x86_64-gp2) we are seeing that the EBS volume ID is not present within the disk metadata. We checked the following points inside the Linux: 1. Directories within /dev/disk: For the above AMI, the disk serial number is not being exposed in the /dev/disk/by-id directory. In the /dev/disk/by-path directory, there are entries present in the following format xen-vbd-51712 -> ../../xvda . Is it possible to map the string xen-vbd-51712 to the EBS volume ? 2. udevadm info <disk_label>: This is yielding the following information attached below, however the volume id is not present in the below. ``` P: /devices/vbd-51712/block/xvda N: xvda S: disk/by-path/xen-vbd-51712 S: sda E: DEVLINKS=/dev/disk/by-path/xen-vbd-51712 /dev/sda E: DEVNAME=/dev/xvda E: DEVPATH=/devices/vbd-51712/block/xvda E: DEVTYPE=disk E: ID_PART_TABLE_TYPE=gpt E: ID_PART_TABLE_UUID=08cf25fb-6b18-47c3-b4cb-fea548b3a3a2 E: ID_PATH=xen-vbd-51712 E: ID_PATH_TAG=xen-vbd-51712 E: MAJOR=202 E: MINOR=0 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=34430 ``` As per https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/device_naming.html, the device name which is provided when the EBS volume is attached to the instance is not guaranteed to be the same which is visible inside the instance. ``` "When you attach a volume to your instance, you include a device name for the volume. This device name is used by Amazon EC2. The block device driver for the instance assigns the actual volume name when mounting the volume, and the name assigned can be different from the name that Amazon EC2 uses" ``` Since our use case can involve frequent addition/removal of EBS volumes on an instance, we wanted to find a deterministic method to identify a volume inside a Linux instance. Could you please let us know that if there is a route by which we can relate the disk within EC2 instance with the corresponding EBS volume id ?
How does hibernation impact snapshots within EC2?
Under the limitations page for hibernation within EC2 []( https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-hibernate-limitations.html), it is mentioned that: "If you create a snapshot or AMI from an instance that is hibernated or has hibernation enabled, you might not be able to connect to the instance.". Could anyone clarify the meaning of this statement. Does it mean: - You might not be able to connect to the instance whilst the snapshot or AMI creation is in progress - You might not be able to connect to the instance after restoring the snapshot or launching a new instance from the AMI - Something else 1. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-hibernate-limitations.html