For what reason would an elastic IP disassociate from a running Instance without any API calls being made?
I am experiencing an odd situation where my running AWS instance is being disassociated from the elastic IP address without any action on my part.
I tried allocating a new address and associating the instance with the new Elastic IP, but the same situation occurs where the IP address is "automatically" disassociated from the instance.
The only thing I haven't tried is stopping and restarting the instance (to move it to new hardware) but I'd rather not lose my internal IP address.
Has anyone else experience such an issue?
It seems that there is currently an issue with Elastic IP address that requires an Instance stop/start in order to ensure that the Elastic IP address "sticks"
https://forums.aws.amazon.com/thread.jspa?threadID=84952&tstart=0
We've noticed this happening to our instances also... I think the problem is a result of the internal IP changing because they are dynamic. When the internal IP changes, the elastic IP drops and you have to associate it again. It's happened to us during a reboot we initiated and it happened on an amazon reboot d
Related
As far as I know, if you create an image from a running instance, it would by default reboot the instance. Do correct me if I am wrong on this.
For my situation, my free elastic ip are all used up and I need to do some heavy modification on the instance operating system. Before proceeding with those modifications, I would like to at least do a complete backup on everything. Which means I need to create an AMI and do snapshot on the EBS before proceeding. Problem is, I can't afford to lose the public and private IP address of that instance because it would take me more work to update all other softwares in different servers that would connect to it (unless of course if I mess it up and had to use the backup created AMI image after all).
So my questions are:
If I just simply create an image from that instance that is still running without stopping it. It will reboot by default, but would it change it's public and private IP addresses? I noticed that a normal "reboot" when you right click the instance does not change those IP address. Is it the same kind of "reboot" when you create image without stopping the instance?
Is it safer that I stop the instance first before creating an image or creating the image while it's running is safe enough? Consider data integrity.
Thank you
The default reboot during AMI creation will just do a normal reboot. It will not change IP addresses.
The Private IP address will never change.
The Public IP address might change if the instance is stopped.
Best practice is to either use an Elastic IP address (free if attached to a running instance, and you can request more if you need them) or use a DNS Name that resolves to an IP address. That way, if the IP address changes, simple update the DNS entry without needing to change any references.
Why doesn't AWS allocate elastic IP's to all the servers being spawned? They allocate public IP by default to all the servers, which gets lost after a reboot of EC2 instances.
What's the logic behind not allowing elastic IPs automatically?
TL;DR Because Elastic IP (EIP) addresses are not needed for all/most use cases.
There is a limited supply of routable IP addresses. If every server on a public subnet received one, those IP addresses would remain allocated even when the servers were off. If the server was terminated it would be unclear if the use of that IP was concluded or is still necessary for other use. Which brings up the real reason for Elastic IP's.
An Elastic IP address is a static IPv4 address designed for dynamic cloud computing. An Elastic IP address is associated with your AWS account. With an Elastic IP address, you can mask the failure of an instance or software by rapidly remapping the address to another instance in your account. [1]
The take away from this is if you're not using EIP's for dynamic cloud computing you're probably using them incorrectly. This is a good example of a correct use case.
If you require a persistent public IP address that can be associated to and from instances as you require, use an Elastic IP address instead. For example, if you use dynamic DNS to map an existing DNS name to a new instance's public IP address, it might take up to 24 hours for the IP address to propagate through the Internet. As a result, new instances might not receive traffic while terminated instances continue to receive requests.[2]
I have a EC2 micro instance(ubuntu) running with tomcat and apache installed .
I am confused what happens if the system crashes , or shuts down. or If i stop it.
Will i have to install and configure all the packages(tomcat,apache) again on the instance , or will the instance on restart or reboot will have all these packages in the pre-stop state?
I know micro instance uses EBS for storage. And I assume on stop it maintains the state (i.e. it is not deleted). is it?
So on restart only the IP address changes right?
Or do i need to configure the instance again.
You are pretty much spot on with all your assumptions:
All EBS backed instances retain their installation state and configuration, which under normal circumstances shouldn't ever have any parts located on the (often called ephemeral) instance store volume(s), if any (see Root Device Storage Concepts for a detailed explanation of the differences between EBS and instance store backed AMIs).
Given the Amazon EC2 Instance Type t1.micro is EBS storage only indeed, this is guaranteed in your case.
Interestingly EBS storage only also applies to the newest regular instance types m3.xlarge and m3.2xlarge btw., so AWS might be slowly moving away from instance storage eventually.
Likewise, on restart only the IP address changes, be it a default public one or an Elastic IP address, see e.g. the FAQ Do I need one Elastic IP address for every instance that I have running?:
No. You do not need an Elastic IP address for all your instances. By
default, every instance comes with a private IP address and an
internet routable public IP address. The private address is associated
exclusively with the instance and is only returned to Amazon EC2 when
the instance is stopped or terminated. The public address is
associated exclusively with the instance until it is stopped,
terminated or replaced with an Elastic IP address. [...] [emphasis mine]
Please note that EC2 instances started within an Amazon VPC slightly differ here, insofar they don't have get a default public IP address and do retain an Elastic IP address (if any) throughout a stop/start cycle.
Initially my issue was "How do I RDP into an EC2 instance without having to first find its ip address". To solve that I wrote a script that executes periodically on each instance. The script reads a particular tag value and updates the corresponding entry in Route53 with the public dns name of the instance.
This way I can always rdp into web-01.ec2.mydomain.com and be connected to the right instance.
As I continued with setting up my instances, I realized to setup mongodb replication, I will need to somehow refer to three separated instances. I cannot use the internal private ip addresses as they keep changing (or are prone to change on instance stop/start & when the dhcp lease expires).
Trying to access web-01.ec2.mydomain.com from within my EC2 instance returns the internal ip address of the instance. Which seems to be standard behaviour. Thus by mentioning the route53 cnames for my three instances, I can ensure that they can always be discovered by each other. I wouldn't be paying any extra data transfer charges, as the cnames will always resolve to internal ip. I would however be paying for all those route53 queries.
I can run my script every 30 secs or even lesser to ensure that the dns entries are as uptodate as possible.
At this point, I realized that what I have in place is very much an Elastic IP alternative. Maybe not completely, but surely for all my use cases. So I am wondering, whether to use Elastic IP or not. There is no charge involved as long as my instances are running. It does seem an easier option.
What do most people do? If someone with experience with this could reply, I would appreciate that.
Secondly, what happens in those few seconds/minutes during which the instance loses its current private ip and gets a new internal ip. Am assuming all existing connections get dropped. Does that affect the ELB health checks (A ping every 30 secs)? Am assuming if I were using an Elastic IP, the dns name would immediately resolve to the new ip, as opposed to say after my script executes. Assuming my script runs every 30 secs, will there be only 30secs of downtime, or can there possibly be more? Will an Elastic ip always perform better than my scripted solution?
According to the official AWS documentation a "private IP address is associated exclusively with the instance for its lifetime and is only returned to Amazon EC2 when the instance is stopped or terminated. In Amazon VPC, an instance retains its private IP addresses when the instance is stopped.". Therefore checking nevertheless every 30s if something changed seems inherently wrong. This leaves you with two obvious options:
Update the DNS once at/after boot time
Use an elastic IP and static DNS
Used elastic IPs don't cost you anything, and even parked ones cost only little. If your instances are mostly up, use an elastic IP. If they are mostly down, go the boot time update route. If your instance sits in a VPC, not even the boot time update is strictly needed (but in a VPC you probably have different needs and a more complex network setup anyways).
Another option that you could consider is to use a software defined datacenter solution such as Amazon VPC or Ravello Systems (disclaimer: our company).
Using such a solution will allow you to create a walled off private environment in the public cloud. Inside the environment you have full control, including your own private L2 network on which you manage IP addressing and can use e.g. statically allocated IPs. Communications with the outside (e.g. your app servers) happens via the IPs and ports that you configure.
Has anyone experienced your elastic IP going bananas?
I set up an elastic IP and it just went crazy so my instance was unavailable, in the end I had to terminate it...
I couldn't get hold of any logs och reports, feels very very strange...
Thanks!
An EIP (Elastic IP) address is nothing more than a reserved address which is assigned to your EC2 account, and which you can allocate to any running VM you own.
There isn't anything to 'go crazy' with an EIP, since it is an inert object - when not assigned to a VM it does nothing but cost you a tiny amount of money, and, when assigned, its' cost drops to zero and the VM switches its' default address out and assumes the EIP instead.
The IP cannot go "bananas". Look the AWS console for the public DNS of the server. Try connecting using that instead of the elastic IP. If connecting using that fails then it is the instance itself that is that problem.
If that works, then how long did you leave between attaching the IP and trying to connect (i.e. what are the timescales on this problem)?