It's possible to copy an unencrypted EBS snapshot to an encrypted EBS snapshot. So the following process can be used:
Stop your EC2 instance.
Create an EBS snapshot of the volume you want to encrypt.
Copy the EBS snapshot, encrypting the copy in the process.
Create a new EBS volume from your new encrypted EBS snapshot. The new EBS volume will be encrypted.
SSD are faster because there's no network latency, but it is ephemeral and you can't detach it from an instance and attach it to another. As you can see, it is available to more powerful instances.
EBS are more flexible, since you can attach and detach it from instances, but is a little bit slower, as more suitable for general purpose.
Now, in Step 4, you ...
Answer is very easy,
when you "Attach Volume" again set parameter:
WARN! If you haven't own "Elastic Network Interface (ENI)" beware change of address on "Instance Start".
Pieced this procedure together based on other comments on https://github.com/kubernetes/kubernetes/issues/68737. I tested this on kubernetes 1.14:
kubectl edit pvc <name> for each PVC in the StatefulSet, to increase its capacity.
kubectl delete sts --cascade=orphan <name> to delete the StatefulSet and leave its pods.
kubectl apply -f <name>...
EBS volumes can be attached and detached from EC2 instance.
If you have an EC2 instance that crashes for some reason, you can move the root volume to another EC2 intance.
Launch a new EC2 instance.
Stop that EC2 instance.
Detach the root volume from the new instance. Make note of the device name that it was attached as (such as /dev/sda1).
Detach the root ...
The amount of time it takes EC2 to build a snapshot is directly proportional to the number of modified blocks that volume has seen since the last snapshot. In the case of your journal, that sees a lot of write/delete operations, so it's not surprising that it would take a long time to snap.
Keep in mind that these are truly block devices. They know nothing ...
I can literally delete all but the most recent with impunity
Assuming you don't need any data that was already deleted or overwritten on the volume when you took the most recent snapshot, that's true.
EBS snapshots are logically incremental -- not physically incremental. Here's the cleverness that explains the difference:
Snapshots of EBS volumes don't ...
They do exactly the same if you select the no reboot option when creating the AMI directly from EC2. This basically creates a snapshot that can potentially be in a inconsistent state. For example, you are risking more having an inconsistent state if you are doing a lot of disk writes when creating the snapshot.
If you want to create a snapshot in a "...
None of the other solutions will work if the volume is used as a root (bootable) device.
The newly created disk is missing the boot partition, so it would need to have GRUB installed and some flags set up correctly before an instance can use it as a root volume.
My (as of today, working) solution for shrinking a root volume is:
Background: We have an ...
From the AWS documentation
The physical block storage used by deleted EBS volumes is overwritten
with zeroes before it is allocated to another account.
From an AWS rep on their forums.
I can confirm that when any customer volume is terminated (be it EBS
or an instance storage volume) it is completely wiped before being
made available for use by ...
In addition to the other answer, you can take a Snapshot of the volume, which stores the data in S3, a cheaper storage option. You can then restore the snapshot to an EBS volume in the future when you want to access the disk.
See Amazon EC2 terminology - AMI vs. EBS vs. Snapshot vs. Volume for more info on the specifics.
You can simply right-click the EBS ...
Ephemeral and ebs devices can take just about any lettered device file name, so do not solely rely on the device name. The device name is important to making a determination if it is ephemeral or not, however, as I will outline below. Relying on a mount point name with the words 'ephemeral' or 'ebs' is likewise not reliable.
Though some of this can be ...
The answers here seem to be missing a few steps prior to re-sizing specially for people who are changing their EBS volume size. If you have used a snapshot to create the EBS or with certain AMIs you will need to extend the disk (xvda), extend the partition (xvda1), then extend the filesystem (/).
If I'm reading this correctly, your disk looks like this:
IMO, you can try to do it like this (I do something similar but with Elastic Network Interfaces). This assumes either a knowledge of AWS CloudFormation service or AWS CLI:
Create an EBS volume
Create a bare AutoScaling group of min/max size set to 1. This will ensure that the only instance when it gets unhealthy will be replaced by a new and healthy one.
To use a EBS volume attached in the EC2, you need first mount the volume.
Connect to your instance using SSH.
Use the lsblk command to view your available disk devices and their mount points.
[ec2-user@ip-172-31-86-46 ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
xvdb 202:16 ...
How can I figure out how long it will take to create the new EBS volume?
And then, try using it. Continue using it over a period of hours and days, and note what you observe.
The first answer to your question is that it actually only takes a few seconds.
The problem with that answer is that it doesn't tell the whole story:
New volumes ...
I answered this same question on Stack Overflow.
s3fs is indeed a reasonable solution, and in my case, I've coupled it with proftpd with excellent results, in spite of the theoretical/potential problems.
At the time I wrote the answer, I had only set this up for one of my consulting clients... but since then, I've also started drinking my own kool-aid and ...
The volumes IDs are not available from the metadata. The virtual devices are available under block-device-mapping/
You will need to use the AWS CLI (or script, program, etc.) to get the volume IDs assigned to an instance.
With the CLI:
aws ec2 describe-volumes
The output will include the instance ID that a volume is attached to.
Once you know the ...
Just to provide some clarification on the initial point here: you cannot add an EPHEMERAL drive to an instance AFTER initial creation. Ephemeral drives are a part of the base instance configuration which is only written on instance creation, and is non-modifiable.
Another point to bear in mind, though you may already know this, is that ephemeral drives are ...
First of all, be aware of the difference between a root volume, an EBS and an EC2 instance store.
The root volume is what hosts the EC2 instance's operating system and it's almost always an EBS volume (some older AMIs may still use EC2 instance store). You can also add volumes to be used to store data and you can specify whether they should be backed by ...
When you delete any EBS snapshot, if there's a later snapshot for the same volume, every block in the first snapshot that wasn't included in the later snapshot (because it didn't change) is logically rolled forward (in a sense) into the later snapshot, so the later snapshot is still perfectly valid when any or all earlier snapshots are deleted.
Is S3 a proper choice to keep live linux user home directories?
Amazon has announced their EFS service, which is exactly what you need for this. Either use EFS or roll your own NFS server for home directories.
AWS don't provide a way to download or extract the actual block device that makes up an EBS volume. The standard way to grab a copy is to use rsync, but as you're after a block level way of doing this, this article might be of some use.
In short (and in case the link above disappears), use netcat and dd at both ends, e.g;
On the sender (your EC2 instance ...
AWS EBS volumes are already stored in multiple copies behind the scenes. So there is no need to add extra redundancy by way of RAID setup on the instance.
Amazon EBS volumes are designed to be highly available and reliable. At no additional charge to you, Amazon EBS volume data is replicated across multiple servers in an Availability Zone to prevent the ...
In AWS Console:
Stop the instance you want to resize
Create a snapshot of the active volume and then create a "General Purpose SSD" volume from that snapshot.
Create another "General Purpose SSD" volume to the size you want.
Attach these 3 volumes to the instance as:
/dev/sda1 for the active volume.
/dev/xvdf for the volume that is the target size.
Here's how to do it.
First ssh into the eb instance.
Then un the following command
sudo /opt/elasticbeanstalk/bin/get-config environment --output YAML
Alternatively --output YAML can be --output json.
Or if you want you can pipe the variables into a node command like this:
var strings =