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
Related
I'm using the Amazon MQ managed service and have a question as to how MQ behaves on a reboot.
Will the private IP of the broker change or is it static?
I'm using Amazon MQ inside of a VPC.
Assuming you're using a single instance broker it will most likely stay the same. I couldn't find a direct documentation reference for this, but Amazon MQ broker nodes are managed EC2 instances. An EC2 instance by default retains the private IP inside a VPC over its lifecycle.
The problem is that you don't control the lifecycle of the instance. If the instance is broken beyond repair, Amazon MQ may set up a new instance for you, which will get a different private IP address inside the VPC, but that should be rare. After a simple reboot that would be very unlikely.
If you're using an active/standby cluster what I said concerning the IPs of the individual nodes should still be true, but the whoever the active node is may change.
If you need a hard guarantee that the IP addresses don't change, you can set up a private Network Load Balancer in front of your cluster. From the docs (emphasis mine):
When you create an internal load balancer, you can optionally specify one private IP address per subnet. If you do not specify an IP address from the subnet, Elastic Load Balancing chooses one for you. These private IP addresses provide your load balancer with static IP addresses that will not change during the life of the load balancer. You cannot change these private IP addresses after you create the load balancer.
For most services in AWS you want to use the DNS name or CNAME to a service instead of any IP address unless there's a static IP address attached to it.
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.
I have created an EC2 instance behind an ELB and the hostname is
mysubdomain.domain.com
The instance is reachable via the internet from my local workstation (have opened all connections from My IP --> to the instance in the security group it belongs to);
However, when performing
curl mysubdomain.domain.com
from within the instance, it times out;
Do I need to assign a public (I assume I want it to be elastic so that I don't have to change it every now and then in my security group inbound rules) and add an allow rule in my security group (that the instance belongs to) from that specific IP?
Is there another way to go about it, given that I have reached the limit of Elastic IPs?
For an Amazon EC2 instance to access the Internet, it must either be:
In a public subnet with a public IP address, or
In a private subnet with a NAT Gateway or similar NAT service
By default, security groups allow all outbound traffic, so you will not need to modify the security groups.
Even if you have reached the limit of your Elastic IP addresses, you can launch the EC2 instance with a Public IP address via Auto-assign Public IP — this is different to an Elastic IP address, in that it is assigned when the instance is Started and might change when the instance is Stopped/Started. However, it will work perfectly fine to obtain Internet access.
If an instance is behind a load balancer, there is no reason to want to reach that instance directly from the Internet. Thus, there is no need for an Elastic IP address. In fact, in best-practice architectures, the instances should be in a Private Subnet so that they are better protected from the Internet. This will then require a NAT Gateway or NAT Instance to enable the instance to access the Internet.
I have an Amazon EC2 instance that I have been using for production and for some weird reason I did not use an Elastic IP.
Now that I want to use an Elastic IP, it seems AWS doesn't allow connection on the old IP. In my use case I need the instance to be accessible through both IPs. Is this really possible?
No. You cannot use the old public IP once you associate an elastic IP. Remember you have only one network interface, you cannot have 2 public (routable) IPs associated with it.
From Elastic IP Address Basics
If you associate an Elastic IP address with the eth0 network interface
of your instance, its current public IP address (if it had one) is
released to the EC2-VPC public IP address pool. If you disassociate
the Elastic IP address, the eth0 network interface is automatically
assigned a new public IP address within a few minutes. This doesn't
apply if you've attached a second network interface to your instance.
What is difference between two terminologies, having a public subnet vs assigning elastic IP address to an instance of VPC over AWS ?
Instances created in VPC public subnets will be automatically assigned a public, routable IP address and a corresponding publicly-resolvable DNS entry of the form ip-<dash delimited address>.<region>.compute.amazonaws.com. Any ports allowed in the instance's security groups will be accessible over the Internet. The automatic address cannot be chosen. These public addresses are not persistent; when the instance is terminated, the IP address is lost.
Elastic IP addresses, by contrast, are associated with an AWS account. They can be attached to an instance. When the instance is terminated, the elastic IP can be associated with a new instance. They are persistent until manually released.
You may find the AWS docs on VPC public addresses useful. Also note that EIPs have some small cost associated in some cases; see the section on Elastic IP Addresses in the EC2 pricing docs.