It's probably a silly question, but I can't understand the difference between these 2 amazon linux 2 amis:
ami-7105540e amzn2-ami-hvm-2.0.20180622.1-x86_64-ebs
ami-b70554c8 amzn2-ami-hvm-2.0.20180622.1-x86_64-gp2
Judging by this article, isn't gp2 just another ebs instance type?
The question isn't silly at all. In fact AWS's lack of documentation explaining the actual difference between the two is a bit surprising
TLDR;
If you're planning on switching to a faster SSD root volume at some point in the future but want to use Magnetic for now it would be better to use the gp2 version of the AMI and then change the root volume to SSD sometime later
Some more Explanation
ami-b70554c8 amzn2-ami-hvm-2.0.20180622.1-x86_64-gp2 - The recommended root volume type is General Purpose SSD (gp2)
ami-7105540e amzn2-ami-hvm-2.0.20180622.1-x86_64-ebs - The recommended root volume type is Magnetic
However this isn't set in stone so you can still interchange between them (I've used the gp2 version with a Magnetic storage in the past without any issues)
I couldn't find any official documentation as to the actual difference between the two AMI versions but the gp2 version most likely has SSD related optimizations added already to the OS
So if you envision switching to SSD at some point in future but want to start with a Magnetic volume it might be better to just use the gp2 optimized AMI right from the start. It probably has some optimizations not relevant to Magnetic volumes but it might be more future proof in case you want to have a faster root volume later
The took the AMI in two types of Volumes.
amzn2-ami-hvm-2.0.20180622.1-x86_64-ebs - ami-7105540e. This has Magnetic Volume type for its root volume.
ami-b70554c8 amzn2-ami-hvm-2.0.20180622.1-x86_64-gp2. This has SSD Volume type for its root volume.
How can we identify this?
Go to EC2.
Launch Instance
Select the mentioned AMI
Select any instance Type.
Choose the VPC, subnet and etc.
Next it'll show the Boot Disk size, there you can see its in SSD or Magnetic.
To learn about Volume tyes: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html
Related
Once I stopped our instance and modified the size of one of the EBS volumes. Then, that EBS is stopping at in 'in-use - optimizing (60%)' status. I suppose it can sometimes happen to take long time for optimizing up to 24hours. But we need to start our EC2 instance as soon as possible.
I'm just wondering if it is possible to start EC2 instance, one of the EBS in optimizing status not completed yet.
That EBS is not root volume, but the important volume contains database files.
Any advice would be appreciated.
Yes you can run the EC2 instance even whilst the EBS volume is optimising.
Whilst it is occuring you might find that the performance varies between both modifications however, it will never be lower than the minimal performance of either previous or new configuration.
While the volume is in the optimizing state, your volume performance is in between the source and target configuration specifications. Transitional volume performance will be no less than the source volume performance. If you are downgrading IOPS, transitional volume performance is no less than the target volume performance.
More information available in the documentation.
I am preparing for AWS certification and I found following question in mock test.
The Question is as mentioned in below image :
And they have mentioned EBS volume in the question, I selected to choose "Provisioned IOPS SSD Volume" to implement scalable and high throughput.
But the correct answer was EFS with the following justification.
But, I think EBS volume can only be mapped with one EC2 instance at a time. Can we map one EBS volume with feet of multiple EC2 instance ?
No, you can't map an EBS volume to more than one instance at a time.
But EFS doesn't use EBS, and an EFS filesystem had no meaningful limit on the number of EC2 instances that can access it simultaneously.
The question isn't a very good one. In fact, it proposes an initial scenario that you would never use.
EBS volumes attached to members of an auto-scaling group would never be used to store CMS documents uploaded by users, because those volumes will ether be destroyed or left attached to nothing when the cluster scales in and some of the instances are terminated due to the decreased load.
The giveaway to the correct answer lies in the fact that the question asks for a scalable, high-throughput, POSIX-compliant filesystem and this is pretty much the definition of Amazon EFS. EFS will scale larger than the largest provisioned IOPS EBS volume.
I am currently using a gp2 elastic volume and i wanted to upgrade to io1 volume in AWS for high iops for a few days now i wanted to know once i upgrade it then after a few days will i be able to downgrade it back to gp2 and if it is possible,is their any loss of data or any such scenario possible please help.
I know how to upgrade the volume but i am not sure about downgrading it so if anyone has ever tried it please help.
current volume: gp2
i used this command to upgrade:
aws ec2 modify-volume --volume-type io1 --iops 10000 --size 200 --volume-id vol-1
what should be the appropriate way to downgrade it.
Although changing from gp2 to io1 might seem like an upgrade and changing back from io1 to gp2 might seem like a downgrade, the truth is more nuanced, because each volume type¹ has certain use cases where it is the best choice.
As a rule, you can change from any volume type to any other volume type, with only one class of documented volume type-related exceptions, due to mounting and size constraints on st1 and sc1 volumes.
So changing from one type to another type is generally a non-issue, but the same thing is not true of size. It is not possible to make an EBS volume smaller. They can only be made larger.
EBS volume modifications are a safe operation, and can even be done "hot" with the disk still in use... but as a matter of best practice, you should always take an EBS snapshot before attempting a modification.
¹each volume type except standard. I can't think of any case where a standard volume would be the best choice.
Cant Modify or Resize Amazon EBS Volume. In us-east-1d N. Virginia. The instance it's connected to is t2.medium CentOS 7.
Any help would be appreciated.
Update: the answer below was correct when written, but was subsequently superceded by this announcement on June 28, 2018:
Starting today, Elastic Volumes extends support to Amazon Elastic Block Store (EBS) magnetic (standard) volume type. You can now dynamically increase capacity or change the type of magnetic (standard) volumes with no downtime or performance impact using a simple API call or a few console clicks.
https://aws.amazon.com/about-aws/whats-new/2018/06/amazon-ebs-extends-elastic-volumes-to-support-ebs-magnetic--standard--volume-type/
The issue that originally triggered this question should no longer occur.
In the screen shot, the volume type shows standard.
That's a previous generation magnetic volume.
The previous generation Magnetic volume type is not supported by the volume modification methods [...]
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/limitations.html
Those can't be resized, so the option is grayed out. Your new instance from the AMI probably has a gp2 SSD volume, which does support resize.
Stop the instance that the EBS volume is attached to.
Then the modify option should be available for use.
If that doesn't work then try detaching the volume.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-expand-volume.html
As #michael-sqlbot says, you are using magnetic "standard" EBS volume, you can convert to ssd "gp2" volume following these steps:
Create snapshot of your EBS volume
Create new PIOPS/General Purpose SSD volume from your EBS
snapshot
Detaching existing attached magnetic volume from the
instance
Attach new PIOPS/General Purpose SSD volume
More info: https://n2ws.com/blog/how-to-guides/how-to-change-your-ebs-volume-type
I have an EBS volume that displays a state of "in-use - optimizing(%)". What does this mean? What are the optimizations that AWS is performing? This is on a 300gb encrypted gp2 volume attached to a Windows Server 2012 R2 EC2 instance.
The in-use - optimizing state relates to EBS volume resizing.
in-use indicates that this volume is attached to an EC2 instance.
optimizing is the volume's modification state.
According to the AWS documentation on volume modifications:
An EBS volume being modified goes through a sequence of states. After you issue a ModifyVolume directive, whether from the console, CLI, API, or SDK, the volume enters first the Modifying state, then the Optimizing state, and finally the Complete state.
...
While the volume is in the optimizing state, your volume performance is in between the source and target configuration specifications. Transitional volume performance will be no less than the source volume performance. If you are downgrading IOPS, transitional volume performance is no less than the target volume performance.
And finally, from the introductory blog post for Volume Modifications:
The volume’s state reflects the progress of the operation (modifying, optimizing, or complete):
If you modified the volume, most likely it will show like that. The performance will be degraded during this time since AWS EBS server needs to sync data.
EBS Volumes are in this state after modifying the volume (e.g. resizing). It can take some time (can be stuck at 99% for hours) but eventually will go away.