Wanted to know more about internals of AWS when we autoscale an instance from one tier to another. Does AWS creates an image and spins up new instance and restores the image ? or what exactly happens inside. ?
Amazon EC2 Auto Scaling will either Launch a new instance or Terminate an existing instance. This is known as horizontal scaling. No instance is "upgraded".
In fact, it is not possible to "upgrade" an Amazon EC2 instance. Instead, you need to Stop the instance, change the Instance Type, then Start the instance again. This will launch the instance on a different host, which is dedicated to running the new Instance Type.
The disks used on Amazon EC2 are (typically) Amazon Elastic Block Store (EBS) volumes. These are network-attached volumes that exist separately to the EC2 instance. Thus, the disks are preserved when the instance is stopped and they are automatically reattached to the instance when it is started again.
Related
When I create an EC2 instance store, I'm not able to stop the instance through the console. But AWS documentation mentioning that " if you stop or terminate an instance, any data on instance store volumes is lost." There is no option available to stop the instance store EC2 instance. Can anyone Explain why AWS talking about the Stop operation which is not possible?
From the AMI Types documentation: Instances launched from Instance Store-Backed AMI cannot be stopped -- instances are either running or terminated. Instances launched from EBS-backed AMIs have a persistent root volume, thus they can be stopped.
The point of confusion is that instances can still use instance store volumes (if so designed) even though the instance is launched from an EBS-backed AMI. In this case, when the instance is stopped, the data on the instance store volumes is lost, but since the root volume (and possibly other volumes, if so configured) is safely persisted in EBS, the instance can be started again with the data on the EBS volumes intact. Instance store volumes will again be attached, but they will be empty -- all data on those volumes is lost if the instance is stopped.
I am deploying Wordpress site using LAMP AMI on EBS-backed EC2. Wordpress database will be stored in EBS.
Amazon keeps on updating base configuration of EC2 for better performance & security.
If I have to upgrade my EC2 then my EBS will get deleted.
How can I ensure that my EC2 gets updated without affecting my EBS?
EBS Snapshot is not of any help as new EC2 already has a EBS attached.
Do I have to always migrate my Wordpress site using backup & do this upgradtion?
Amazon EC2 instances use EBS volumes as their disk volumes. They are populated from an Amazon Machine Image (AMI) when the instance is launched.
When AWS releases updated AMIs, any new instance launched from the AMI will contain the updated disk content. However, existing EC2 instances will not be changed (since they have a copy of the AMI at the time that the instance was launched).
You can also change the Instance Type of an EC2 instance, which gives it different hardware (CPU, Memory). This can be done by stopping the instance, changing the type and starting it again. This will not affect the contents of EBS volumes.
If you wish to keep your instance "current", simply run sudo yum update (Linux) or run the Windows Update utility to update your operating system and associated utilities rather than launching a whole new instance.
I had to stop my m3.medium EC2 instance from the AWS console to resize it to m3.large. However, after it stopped, it automatically created a new instance.
Any idea why this is happening? It caused some big troubles for me.
Your AutoScaling group with minimum size = 1 spun up a new instance because there were no instances in the 'running' state available to respond to requests, particularly health checks. Your instance was deemed 'unhealthy' and replaced by the ASG.
If your instance storage was ephemeral, I'm afraid it is gone forever unless you recently saved an AMI. If your instance storage was backed by EBS, you can recover it by attaching the EBS volume to a new instance.
In the future, consider configuring your autoscaling group's launch configuration to have everything you need ahead of time, by either bootstrapping the instance or by baking an AMI.
For 'bootstrapping' an instance:
Create a new launch configuration with a standard AMI avaialble from Amazon.
Add user data to the launch configuration to handle installation and configuration of your desired programs.
For 'baking' an AMI:
Install your desired programs and configuration on a new EC2 instance.
Take an image (AMI) of that EC2 instance.
Use that image in your new launch configuration.
Manually working on an instance within an ASG and expecting the instance to persist indefinitely is dangerous, as you've just discovered.
Further Reading:
EC2 Documentation - AutoScaling Health Checks
EC2 Documentation - Amazon Machine Images
I have a requirement of setting up Apache Tomcat on Amazon EC2 instance.
I have heard that EC2 is ephemeral and anything we put in may not survive restarts. So if I add a Tomcat in EC2 and restart the instance will it be deleted or removed.
What are the ways to overcome this issue ?
Sorry I am a newbie in AWS.
If what you need is just Tomcat then you can use pre-configured Amazon Beanstalk Tomcat container which does exactly that.
However if you need to build custom EC2 you can install tomcat on EBS linked to EC2, or even better use Amazon EFS to share between multiple EC2.
Ephemeral disk is temporary storage that it is added to your instance and sized according to instance type. The larger the instance, the more temporary storage.
For some instances like c1.medium and m1.small they use instance storage automatically as SWAP as they have a limited amount of memory, while many others are automatically formatted and mounted at /mnt.
You can take snapshots of your EC2 instances while they are running. Snapshots allow you to create AMI's from your current machine state, which will contain everything in your ephemeral storage. When you launch a new instance based on that AMI, it will contain everything as it was in the snapshot.
An Amazon Machine Image (AMI) provides the information required to launch an instance.
Take note that there is a big difference between stop and terminate. If you stop an instance that is backed by EBS, the information on the root volume will still be in the same state when you start the machine again. If you terminate the machine without taking a snapshot, even if it is backed by EBS, the storage inside the ephemeral disk will be lost forever.
All AMIs are categorized as either backed by Amazon EBS or backed by instance store. The former means that the root device for an instance launched from the AMI is an Amazon EBS volume created from an Amazon EBS snapshot. The latter means that the root device for an instance launched from the AMI is an instance store volume created from a template stored in Amazon S3. For more information, see Amazon EC2 Root Device Volume.
The above answers should provide a good idea about what you can and cannot do with ephemeral disks, but I advise all (myself included) to learn more about ephemeral disks and their primary use cases.
Here are some good use cases for ephemeral storage that I know of:
Temporary backup
Re-format the original instance storage and use part of it for SWAP
RAID 10 with 6 disks (4 EBS and 2 Ephemeral disks) to improve overall performance and provide HA
Application cache, logs, any other random data
You are save as long as you not store it on ephemeral partition which is a part of your instance check this to have more info
http://www.heitorlessa.com/working-with-amazon-aws-ec2-ephemeral-disks/
basically you need to mount elastic drive to your instance and install Tomcat and all your software there, ephemeral storage is for swap or caching
You only need storage to keep your information, EBS or S3. EC2 instances are virtual machines and will not lose your information if restarts with storage.
Get all information you need at https://aws.amazon.com/es/ec2/
We are facing two problems with EC2 and RDS instances:
We are loosing existing data, when the existing EC2 instance is terminated and new EC2 instance is created automatically. Once we create Elastic Beanstalk and upload our application files, its creating one EC2 instance and running. And then next if we upload any files to the existing EC2 instance and in case its going down/terminated, one more new instance is getting created and loosing the data from the old EC2 instance.
If we add the EC2 instance ip address to the RDS inbound security group to restrict others from accessing RDS instance from other ips, we are facing problem to access RDS, when the old EC2 instance is terminated and new EC2 instance is created or any other new ec2 instance is created based on load.
Kindly suggest some solution for the above issues.
Any data you store in EC2 is going to get lost if/when the instance is terminated. You need to design your solution so that it is not dependent on ephemeral subsystems.
Exactly how, will depend on what you are doing, but for example, if you are hosting a web server and the user can upload images, better to store them on S3 instead of directly in the EC2 instance. Data should be stored in a database also not on the EC2 instance, so in an RDS instance or DynamoDB both of which will survive an EC2 termination and restart.
For the access problem, you create a security group (call it sg-1234 for example), and then make each of your new instances created with that security group when they start.
Also create an RDS security group (call if db-1234 for example) and in the DB-1234 security group create a rule that allow Sg-1234 as a source.