Is there a way to get instance root volume id in CloudFormation template? Instance was created from AMI image. I want to specify volume id for Cloudwatch Alarm. Fn::GetAtt function can't return it, after reading documentation a lot i found only one way to do it: "custom resource", but it's too complicated.
You should try creating the volume first (http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-ebs-volume.html) and then attaching it to /dev/sda1 (http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-ebs-volumeattachment.html).
Although the doc doesn't rule this out, I'm not completely confident it will work. I assume you will at least need the right snapshot ID from the desired AMI.
If it happens to work, the example under the second link shows how to then reference and get the volume id. And to suggest an alternative, I do believe instance metrics provide aggregate IO for ephemeral disks (see EC2 under http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ec2-metricscollected.html).
I realize you're not asking for ideas in reengineering your stack... but depending on what this disk IO actually represents, you might realize additional benefits by switching to instance store (free and very fast) or additional EBS (many down-the-road benefits when e.g. mounted for data directories for databases). Both of these would also solve your immediate problem.
Related
I wanted to know is it possible to automate the creation of AMI in AWS without downtime and data loss, if possible how can we achieve it.
I have use system manager-> maintenance window in which i have set the reboot to true for data integrity, but i need a way so that the data is not lost.
Any help will be appreciated.
Thank-you.
Answering it as per comments discussion, question is somehow still vague to me
You have EBS right now. I'm not sure if your Instances are in Same AZ or not. If they are in same AZ then you can use EBS multi attach feature (available for IO volumes only) to share same storage with all of them.
Regarding backup you can choose EBS snapshots
Ideally my suggestion to you would be create a launch template, use EFS that can be mounted to multiple instances in same region, if you want it across regions then create mount targets. EFS is natively integrated with AWS backup.
Whenever any failover happens or your EC2 crashes for any reason and it goes less than your target capacity, auto scaling would automatically provision a new instance using launch template which would be using same EFS
but i need a way so that the data is not lost.
if you want to achieve this, then According to Docs, you need to ensure that application or os is not writing to ebs, which can be managed by either a script or a custom logic.
You can take a snapshot of an attached volume that is in use. However, snapshots only capture data that has been written to your Amazon EBS volume at the time the snapshot command is issued. This might exclude any data that has been cached by any applications or the operating system. If you can pause any file writes to the volume long enough to take a snapshot, your snapshot should be complete. However, if you can't pause all file writes to the volume, you should unmount the volume from within the instance, issue the snapshot command, and then remount the volume to ensure a consistent and complete snapshot.
if you achieved the above then you can automate the creation, retention, and deletion of EBS snapshots and EBS-backed AMIs it using Data Lifecycle Manager
I haven't tried this but I think exporting VM to S3 and then automating the entire pipeline with Ec2 image builder should do the trick, you can customise your further images with build components
Refers importing and exporting vm's
Unfortunately there is not of box solution other than compromising data integrity but you can try above mentioned which can ensure data integrity and automation
I am having trouble fully understanding the differences between EBS Snapshots and AMI's in AWS. I understand how to create them and the terminology (Snapshots are backups of Volumes or the disk attached to an EC2 Instance and AMI is the backup of the full EC2 instance with snapshots at given time). But, I'm not sure what exactly is saved in the snapshot.
Assume I have an EC2 instance with LAMP stack installed on it and some data from the database. I understand the snapshot will save all my data and website files. When I create the new EC2 instance and attach the volume backed by my snapshot, do I then have to install Apache, MySQL, and PHP again? Or is that all saved in the snapshot? I am not worried about having to redo the security settings, instance type, etc for the new EC2 instance, but am worried all the configuration files are lost unless I have an AMI.
I understand how to create them and the terminology (Snapshots are backups of Volumes or the disk attached to an EC2 Instance and AMI is the backup of the full EC2 instance with snapshots at given time)
This is kinda correct, but not exactly. A better understanding of the concepts may help you in general, so here it goes.
A snapshot represents the state of an EBS volume at an exact point in time, taken atomically, that you can use to create other EBS volumes from. Those new EBS volumes, created from the snapshot, will start with the exact same content as the original EBS volume at the time the snapshot was taken. So, kind of a "backup of volumes").
One extremely important thing about Snapshots, though, that you seem to be missing based on the rest of your question, is that Snapshots are immutable. Once create, the contents of a snapshot cannot change, ever.
An AMI is an Image — it's used to create an instance from. It's a bunch of metadata, which includes the type of hypervisor required, accounts allowed to use it, and ultimately it contains a list of EBS Snapshots that should be used to create volumes, and where exactly to attach the volumes created from those snapshots.
So, while "creating an AMI" is indeed a strategy some people use to create a "backup of the full EC2 instance", it's not exactly the same thing.
When I create the new EC2 instance and attach the volume backed by my snapshot [...]
I think you're confusing some concepts here.
When a new EBS volume is created from a snapshot (either by you creating the EBS volume directly and selecting a snapshot, or by using an AMI, which implicitly means that EBS volumes are going to be created from the Snapshots as specified in the metadata that the AMI represents), there's no relationship between that snapshot and the new volume anymore. Any changes made to the volume are completely independent of the original snapshot. Remember: snapshots are immutable.
So, this notion of "the volume backed by my snapshot" may be quite unhelpful: there's no link between them.
Hoping this is clear, let's move on...
When I create the new EC2 instance [...], do I then have to install Apache, MySQL, and PHP again? Or is that all saved in the snapshot?
The software that will come pre-installed in the EC2 instance is defined by the contents of the snapshots used when the EBS volumes attached to the instance were created.
In other words, if you create an EC2 instance from a standard AMI (not one that you create) that doesn't come with the software pre-installed, then the software won't be installed.
If you create an AMI from your instance before you install the software you want, then the AMI (or, more precisely, the snapshots referenced by the AMI) won't have the software, so any instances created from that AMI won't come with the software.
Now, here's what you are probably looking for:
If you (1) create an instance, then (2) install the software, and only then (3) you create an AMI, in this order, then any new instances created from that AMI will come with the software pre-installed.
The easiest way to fully and truly understand this is to remember that (A) Snapshots are immutable, and (B) AMIs are immutable references to Snapshots.
All that said, while creating a custom AMI is indeed a completely valid and popular approach to the problem you are dealing with, there's another approach that's also completely valid and popular, but that is more flexible, and could be worth investigating.
Instead of having to create and manage AMIs (*), what you could do is use a user data script.
Essentially, what it does is it allows you to have a script, that will execute as root, on the first boot of a newly created instance. This script is often used to install software, update packages, download configuration files, etc.
This way, if you need to change versions of software, or change configuration files, etc, you don't need to go through all the complexity of managing AMIs. Instead, you simply update the script.
For more info on user data, check this out: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html
(*) "manage AMIs": remember that an AMI is an immutable set of metadata which includes reference to Snapshots, which are also immutable. So if you ever need to change some settings, or have new versions of the software be installed, you will need to create new AMIs. This could become something quite complicated and time-consuming. In fact, there's a ton of tools out there, some by AWS, some by other companies, that try to simplify the process of creating and managing AMIs. So just be aware that, while doable, valid, and popular, it's an approach that can get messy!
Is there a convenient way to roll-back an EC2 instance to a previously saved snapshot in the same manner that you can do so with VMWare and other virtualisation platforms. In my investigations so far, it seems you have to deploy a new instance and select the snapshot as the starting volume.
I am doing a lot of testing with new EC2 instance initialisation scripts at present, and having to configure and deploy a new instance for every test is tedious and costly. If I can roll-back to a snapshot of the initial state of the system quickly, this would save a lot of time and effort.
The answers by John and Stefan are both correct. There's no way to trigger a simple "Roll this EC2 instance back to an earlier snapshot" feature on AWS.
There is a way to "roll back" an instance's filesystem to a snapshot by restoring the snapshot to a new EBS volume, detaching and deleting the old one, and attaching the new one.
And, of course, AWS is eminently automatable. You could definitely write your own automation to make that happen.
Having said all of that, if you're trying to test instance creation scripts, I have to agree with John, tearing down and rebuilding the instance is the most reliable way to make sure you're testing it accurately, and shouldn't really be more costly than restoring to a snapshot.
The other path you might consider, particularly if you want the instance to start in a known state that doesn't match a particular predefined AMI, is to build an AMI of your own (e.g. w/ Packer) and use that as the basis for your test. Then instead of restoring to a snapshot, you're creating a new instance from an AMI you've prepared.
No. There is no concept of "roll-back" with Amazon EC2.
If you are using Amazon Linux, deploying a new instance shouldn't be costly. It is charged per-second. You can script it so it isn't so tedious.
Simple answer is no.
If your EC2 instance is backed by an EBS volume however you could create a new volume from the snapshot, detach the old volume and reattach the new one.
I am trying to clean up some old AWS accounts to reduce costs, and need to get rid of unnecessary EBS volumes that are not attached to anything.
aws ec2 describe-volumes --volume-ids "blah" "blah"
does return a list of volumes, but doesn't provide info on which VM it might have been attached to.
Before I delete a whole bunch and we lose data that might be needed, I was wondering if there is a good approach to get that info?
Looked into cross referencing with Snapshot Id's and seeing what was there, but almost all have been deleted. Only one volume so far has tags that describe the old VM.
I do have a free micro instance on AWS and quite often my CPU is throttled making it very hard to use.
I do want to know if there is any way to test a bigger instance so I see which one would be ok.
Side questions:
Can I go back to the free micro if I want?
Can I limit the cost of the testing, or do an estimate on it? I don't want to endup with a surprise bill as the result of the testing.
You can of course launch a new instance of a larger size, run your tests, then terminate the instance. It will not effect your running micro instance in any way at all.
AWS publishes their pricing data, so you can either calculate the cost manually or use the cost calculator: http://calculator.s3.amazonaws.com/calc5.html
There is no way to "cap" your AWS spend.
Mike Ryan's answer is correct as such, but there might be a better way to achieve your goal, because it is possible to upgrade your Amazon EC2 t1.micro instance in place. This process (and the few constraints) are summarized in Eric Hammond's article Moving an EC2 Instance to a Larger (or Smaller) Instance Type:
When you discover that the entry level t1.micro instance size is
simply not cutting it for your growing application needs, you may want
to try upgrading it to a larger instance type, perhaps an m1.small or
even a c1.medium.
Instead of starting a new instance and having to configure it from
scratch, you may be able to simply resize the existing instance by
asking Amazon move it to better hardware for you. Of course, since
this is AWS, you don’t have to actually talk to anybody—just type a
few commands and the job is done automatically.
Eric describes how to achieve this via the command line, but the same can be done via the AWS Management Console as well if your prefer, the instance menu features a respective command Change Instance Type (only enabled when the instance is stopped).
Alternatively you might also want to get acquainted with the ease of duplicating an EBS-Backed EC2 instance by means of an Amazon Machine Image (AMI), which allows you to start any number of exact duplicates of your current instance - this process is outlined in Creating Amazon EBS-Backed AMIs Using the Console for example.