I am new to AWS and tried to create an EC2 instance.
I have a domain and ready to modify the A record to the associated EC2 instance.
I found an article that said an elastic IP is required for associating a production domain.
But AWS provides a public IP and it is accessible on the public internet too (i know it changes after restart, just assuming its okay to modify the A record after the machine is restarted - actually it is not restart very often).
In this case, is it a must that to assign an elastic IP to the instance (this instance contains no load balancing, it is only a simple single instance)?
If yes, why is it necessary?
An Elastic IP (EIP) is not necessary provided that you understand the limitations of public IPs. You may not reboot your instance, but AWS might for any number of reasons. This means that the public IP address could change when you are not expecting it.
When an EIP is assigned to a running EC2 instance, there are no charges for the EIP e.g. it is free. Therefore why go thru the hassle of needing to monitor your public IP address.
Related
I have a scenario where I want to setup an haproxy cluster with keepalived. I saw this blog post https://www.peternijssen.nl/high-availability-haproxy-keepalived-aws/ and its pretty detailed and easy to follow, but for my scenario I need the elastic IP's to be private. Is this doable ? As from AWS documentation Elastic IP's are only public IPs.
I need a floating IP which will act as a floating cluster IP. What can I use if Elastic IP is not an option.
An elastic IP within AWS is actually a static public IP address. This functionality is required as by default a public IP address is not reserved by an account, and when enabled limits the total IPv4 addresses you can keep.
For private address ranges however, your instances can be assigned any private IP address that is within any of your VPCs CIDR range(s).
In fact for this reason you can select almost any IP address found within your VPC when launching a new instance, in addition the IP addresses that are attached to an EC2 instance are static and will be attached to that instance until it is terminated.
Therefore as long as you don't terminate the instances the private IP(s) will be maintained. However, in the event the instance fails and is not recoverable you would still need to launch a new instance and use that IP.
It might be more beneficial using a DNS record to resolve the IP just in case of an emergency, or failing that use a load balancer to distribute traffic.
For this case you can provision an Elastic Network Interface (ENI) with a static private IP address which you can attach/re-attach to EC2 instances. As long as you don’t delete the ENI, it will retain the I as p address. Find out more here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html
We all know that we can assign a Elastic IP associated with EC2 instance. However, when we rebuild the environment in ElasticBeanstalk the IP still changes since the old instance is terminated and a new instance is created. Is there any way we can assign a "real" static IP so that it wouldn't change even if it's rebuilt in ElasticBeanstalk? Thanks in advance.
From Using Elastic Beanstalk with Amazon VPC:
For single-instance environments, Elastic Beanstalk assigns an Elastic IP address (a static, public IP address) to the instance so that it can communicate directly with the Internet.)
For Load-balancing, autoscaling environments, you should always communicate via the Elastic Load Balancer, which is referenced by DNS Name.
If you require a fixed IP address for whitelisting, there are a few choices:
Route outbound traffic to the remote service via a NAT Gateway -- it can use a fixed Elastic IP address
Route traffic via a proxy in your VPC -- again, it can use a fixed Elastic IP address
Given that you have an auto-scaled environment, it doesn't necessarily make sense to allocate IP addresses to each individual instance. However, if you know the maximum number of instances that will be created, you could create Elastic IP addresses for your EC2 instances and re-associate them to instances when they are re-created. (You could potentially do this via a startup script.)
I agree with John. But just in case if you any way need EIP ( probably to ssh to the server ) : One workaround is Go to EC2 --> Elastic IPs --> Allocate new address . This way you are buying a fixed EIP for your account. Now you can manually associate this EIP with any of your EC2 instance.
Problem with this approach is that you have to always MANUALLY associate EIP.
I have a windows EC2 instance running a production website and DNS is configured to have my domain name point to its public IP. There is currently no Elastic IP (EIP) associated with the instance. I would like to start using a Elastic IP and have my domain name point to it instead of the public IP (which can change if I ever have to change the instance).
Reading the documentation I find this statement troubling:
When you associate an EIP with an instance, the instance's current
public IP address is released to the EC2-Classic public IP address
pool.
My fear is this:
I assign an EIP to the instance and the public IP is released.
Now my website no longer works, because the domain name points to the public IP, which is no longer associated with my EC2 instance.
I must then point DNS records to the EIP. But this could take up to 48 hours for propagation to take place (i.e. my site may be be unreachable for up to 48 hours).
How can I do this without having to live through DNS propagation?
If your EC2 instance is in a VPC, you can add a second network interface onto your EC2 instance. You can associate your Elastic IP address with that second network interface. This way, your EC2 instance could respond to both IP addresses.
Instructions
Create a new Network Interface in the same subnet as your EC2 instance.
Allocate a new Elastic IP for your VPC (if you haven't done so already).
Associate the Elastic IP address with your new Network Interface (eni).
Attach your new Network Interface to your EC2 instance.
Do not change your DNS yet.
You may need to RDP/SSH into your EC2 instance to make some configuration changes to ensure your EC2 instance responds correctly to the new IP address.
Modify the hosts file on your local computer to test connecting to your website via the new IP address.
When that works, do the DNS switch and restore your hosts file.
48 to 72 hours before your pre-determined switch-over time, reduce the time-to-live (TTL) on your DNS entry to 300 seconds (5 minutes).
At your designated switch-over time:
Attach the Elastic IP address
Update your DNS entry to point to your Elastic IP address
Doing this, your effective "downtime" is reduced to 5 minutes.
You can have two identical EC2 instances. One with the old public IP where DNS record is pointing to. One with the EIP assigned. Requests should be able to access anyone of the two instances without noticing it. Your application must be able to scale horizontally. Then you change DNS record to point to EIP. Eventually, when DNS is updated, all requests to your domain will end up going to the EC2 instance with the EIP. At that moment you can stop or terminate the old EC2 instance.
Other possibility if your application cannot scale horizontally and if it is a web application, the web server in the old EC2 instance can redirect requests to the EIP. It would redirect to an IP address but it's a possibility.
If you don't use EC2-Classic instances, you can freely move the Elastic IP to any other EC2 instance without losing the EIP.
aws ec2 associate-address --region us-east-1 --allocation-id eipalloc-xxxxxxxxxxx --allow-reassociation --network-interface-id eni-xxxxxxxxxx
where eipalloc-xxxxxxxxxxx is the id of the Elastic IP and eni-xxxxx is the id of the target EC2 instance.
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-recover-ip-address/
Elastic IP addresses
It's a best practice to use an Elastic IP address. Elastic IP addresses are allocated to your account, instead of to the instance. You can associate your Elastic IP addresses to and from instances as needed.
If you release the Elastic IP address that was allocated to your account, you might be able to recover it. For more information, see Recovering an Elastic IP address.
All instances except EC2-Classic instances retain their associated Elastic IP addresses when stopped. AWS continues to bill for Elastic IP addresses associated with a stopped instance.
Note: Elastic IP addresses associated with EC2-Classic instances aren't recoverable.
We have a setup where 3 ec2 instances each are associated with an elastic ip on its primary network interface eth0 so incoming requests can be served by these instances.
Each of these instances has a secondary network interface eth1 where in the event of a failure/ crash/ reboot of an instance, the elastic ip associated with that instance would be associated to one of the remaining running ec2 instances on that interface. This is some sort of failover mechanism as we always want those elastic ips to be served by some running instance so we don't lose any incoming requests.
The problem I have experienced is specifically on reboot of an instance. When an instance reboots, it cannot get back the public ip it had where this public ip is that of the elastic ip that is now associated with another instance. Thus this instance cannot access the internet unless I manually re-assign the elastic ip back to this instance.
Is it possible to automatically reclaim/re-associate the elastic ip it once had onto its eth1 interface on reboot? If not, do you have suggestions for a workaround?
Reboot is necessary as we would be doing unattended upgrades on the instances.
Update:
Also note that I need to use these elastic ips as they are the ones allowed in the firewall of a partner company we integrate with. Using ELBs won't work as its IP changes over time.
So here's how I finally solved this problem. What I missed out on was that Amazon only provides a new public IP to an instance under two conditions.
Its elastic IP is detached
It has just one network interface
So based on this, on startup, i configure the instance with two instances but i detach the secondary eth1 interface. Hence this makes the instance eligible for getting a new public IP (if for any reason it reboots).
Now for failover, once one of the running instances detects an instance has gone offline from the cluster (in this case, lets say it rebooted), it will then on the fly attach the secondary interface and associate the elastic IP to it. Hence, the elastic IP is now being served by atleast one of the running instances. The effect is instant.
Now when the failed instance comes back up after reboot, amazon already provided it a new non-elastic public IP. This was because it fulfilled the two conditions of having just one network interface and also its elastic IP was disassociated and re-associated to another running instance. Hence, this rebooted instance now has a new public IP and can connect to the internet on startup and do the necessary tasks it needs to configure itself and re-join the cluster. After that it re-associates back the elastic ip it needed to have.
Also, when the running instance that took over the elastic IP detects a new instance or the rebooted instance has come online, it detaches the secondary interface again so it would be eligible to get a new public ip as well if it rebooted.
This is how i handle the failover and making sure the elastic ips are always served. However this solution is not perfect and can be improved. It can scale to handling N failed/rebooted instances provided N network interfaces can be used for failover!
However if the instance that attached secondary interface(s) during failover reboots, it will not get a new public IP and will remain disconnected from the cluster, but atleast the elastic IPs would still be served by remaining live instances. This is only in the case of reboots.
BTW, atleast from all that i read, these conditions of getting a new public ip wasn't clearly mentioned in the amazon docs.
It sounds like you would be better served by using an elastic load balancer (ELB). You could just use one ELB and it would serve requests to your 3 application servers.
If one goes down, the ELB detects that and stops routing requests there. When it comes back online, the ELB detects that and adds it to the routing group again.
http://aws.amazon.com/elasticloadbalancing/
So, I don't understand what is going on here... I have (3) Micro EC2 Instances which are launched (without elastic ip)
I then go to Network Security->Elastic IPs and click associate IP address. I chose a running EC2 instance, that instance then uses the elastic ip.
If I stop, then start this SAME ec2 instance, it doesnt have the same previous elastic IP address and is instead some completely new IP address. This is messing up scripts that then depend on the previously associated elastic ip to that EC2 instance.
Why is this happening and why cant i get any of the (3) instances to adopt and keep this assigned elastic ip?
If you create a VPC and then re-provision the 3 micro instances under the VPC, EIPs you associate will remain associated during stop/start cycles. You won't be able to reuse your existing EC2 instances or EIPs; you'll have to recreate them under the new VPC.
Elastic IPs become disassociated with EC2 instances (in EC2-Classic) when you stop them. You will need to re-associate them again on startup, which can be done through the API (via AssociateAddress), CLI (via ec2-associate-address), or via the AWS Console.
Here's what the Elastic IP documentation has to say on the matter:
When you associate an EIP with an instance, the instance's current
public IP address is released to the EC2-Classic public IP address
pool. If you disassociate an EIP from the instance, the instance is
automatically assigned a new public IP address within a few minutes.
In addition, stopping the instance also disassociates the EIP from it.
We solve this at work by tagging our dev instances (which are turned off overnight) with the desired elastic IP and run a script in the morning to first turn them on, and then re-associate the elastic IP.
If you are willing to pay for NAT gateway (per hour charge + per GB traffic processed) , you can create a NAT gateway to make Elastic IP attach to your VPC private Subnet(you need to create route for subnet , point to nat-gateway, and modify your default route point to igw-id).
Any EC2 instance restart will have effect on the Elastic IP afterwards.