Does the ELB's IP Ever Change once setup, or will it always access instances from the same location during its lifetime no matter what might be going on with it behind the scenes at Amazon?
ELB's IP address keeps changing. You should instead use the DNS name provided to you.
http://developer.amazonwebservices.com/connect/thread.jspa?threadID=32280
The short answer: Yes, ELB's IP addresses (both the ones that are publicly distributed to clients of your service, and the internal IPs from which ELB sends traffic to your instances) dynamically change.
The long answer: See my article about how ELB works for more info:
http://shlomoswidler.com/2009/07/elastic-in-elastic-load-balancing-elb/
I understand this question has been already answered but I found the article "Best Practices in Evaluating Elastic Load Balancing" on the AWS site that explains why the ELB's IP addresses keep changing.
By default, Elastic Load Balancing will return multiple IP addresses
when clients perform a DNS resolution, with the records being randomly
ordered on each DNS resolution request.
...and the importance to ask to the DNS the actual IPs to use
If clients do not re-resolve the DNS at least once per minute, then
the new resources Elastic Load Balancing adds to DNS will not be used
by clients.
http://aws.amazon.com/articles/1636185810492479
Note: originally ELB (Elastic Load Balancer) referred to an L7 balancer what is now called ALB (Application Load Balancer), which indeed has changing IPs.
But there's an other kind of ELB, the L4 NLB (Network Load Balancer), which by default uses static IP addresses (and you can stick Elastic IP as well, if you want flexibility of moving the ElasticIP around).
So it is important to distinguish which ELB we are talking about - ALB or NLB.
Related
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]
Say I deploy an API, the database etc. to a t2.micro EC2 instance to serve traffic for the period of prototyping and beta testing. Let's say the domain pointing to the API is api.exampleapp.com.
Now traffic begins to grow beyond the instance's limits and we deploy the API to a bunch of instances that we want to stand behind a load balancer. After setting the fleet up, how do we make api.exampleapp.com point now to the load balancer's IP address so that traffic is served by the newly launched instances without any downtime? Is this possible at all? Or with minimal downtime? Or is this approach of starting up with a new API itself faulty?
I assume you either don't need auto-scaling or have it already configured.
start the LB and attach your first EC2 to it. The instance still work, can be directly accessible via its IP (thus, accessible from the World).
check the LB hostname, try to access the instance using LB, make sure it works
switch DNS to the LB using either CNAME or ALIAS record type (if ALIAS is supported by your DNS server)
add another instances to the LB.
Done!
Using Amazon VPC, what is the best possible way to attach multiple instances to a single ip address?
My company needs the ability to open/shutdown instances upon request and traffic. All instances created must have the same ip address attached, as the service I try to connect to allows only certain IPs that I can define every once in a while.
You want to use Elastic Load Balancer (ELB). It was built specifically for the purpose of balancing a large number of requests to the same IP across several EC2 instances.
http://aws.amazon.com/elasticloadbalancing/
If you want to whitelist the IPs of your instances to some other third party service, then you would have to use elastic IPs in that case. You can not associate one IP to more than one instance.
However, if you want only one endpoint for your service, you can very well use load balancer as also suggested above.
Is there any way to make new instances added to an autoscaling group associate with an elastic IP? I have a use case where the instances in my autoscale group need to be whitelisted on remote servers, so they need to have predictable IPs.
I realize there are ways to do this programmatically using the API, but I'm wondering if there's any other way. It seems like CloudFormation may be able to do this.
You can associate an Elastic IP to ASG instances using manual or scripted API calls just as you would any other instance -- however, there is no automated way to do this. ASG instances are designed to be ephemeral/disposable, and Elastic IP association goes against this philosophy.
To solve your problem re: whitelisting, you have a few options:
If the system that requires predictable source IPs is on EC2 and under your control, you can disable IP restrictions and use EC2 security groups to secure traffic instead
If the system is not under your control, you can set up a proxy server with an Elastic IP and have your ASG instances use the proxy for outbound traffic
You can use http://aws.amazon.com/vpc/ to gain complete control over instance addressing, including network egress IPs -- though this can be time consuming
There are 3 approaches I could find to doing this. Cloud Formation will just automate it but you need to understand what's going on first.
1.-As #gabrtv mentioned use VPC, this lends itself to two options.
1.1-Within a VPC use a NAT Gateway to route all traffic in and out of the Gateway. The Gateway will have an Elastic IP and internet traffic then whitelist the NAT Gateway on your server side. Look for NAT gateway on AWS documentation.
1.2-Create a Virtual Private Gateway/VPN connection to your backend servers in your datacenter and route traffic through that.
1.2.a-Create your instances within a DEDICATED private subnet.
1.2.b-Whitelist the entire subnet on your side, any request from that subnet will be allowed in.
1.2.c Make sure your routes in the Subnet are correct.
(I'm skipping 2 on purpose since that is 1.2)
3.-The LAZY way:
Utilize AWS Opsworks to do two things:
1st: Allocate a RESOURCE Pool of Elastic IPs.
2nd: Start LOAD instances on demand and AUTO assign them one elastic ip from the Pool.
For the second part you will need to have the 24/7 instances be your minimum and the Load instances be your MAX. AWS Opsworks now allows Cloud Watch alarms to trigger instance startup so it is very similar to ASG.
The only disadvantage of Opsworks is that instances aren't terminated but stopped instead when the load goes down and that you must "create" instances beforehand. Also you depend on Chef solo to initiate your instances but is the only way to get auto assigning EIPs to your newly created instances that I could find.
Cheers!
I want to use the Amazon Web Service free micro-instance for my different projects for testing and personal purpose. But I required some static-public IP on which I can run my server.
Is that possible? From where I can buy just IP and use it with my AWS?
EC2 Elastic IP Addresses
Elastic IPs are tied to an account, not an instance.
You need to look at AWS VPC for this.
Whilst VPC is free outside of the usual instance pricing, it doesn't work with Micro instances (the cheapest ones).
When not using VPC, you're assigned IP addresses through DHCP. When the DHCP lease expires, or you restart, your IP is released back to the pool.
VPC lets you use private IP addressing, you can use it with Elastic IPs and is much easier to integrate with a physical infrastructure setup.
If you're only testing/investigating AWS and have little or no budget to use anything other than a Micro instance, I'd just suck it up and deal with the changing of IPs.
If you've got a budget that lets you use instances other than Micro, then go for VPC.
Also, if you're doing more than testing/investigating I'd recommend starting with VPC straight away as trying to migrate from a non VPC to a VPC infrastructure is a massive PITA.
For every AWS account, 5 free elastic ips are provided. You have to just allocate them to required instance. But make sure that the allocate address(newly created elastic ip) in in use, because you will billed if the Elastic ip is not in use.
Looks like they have configured ARP statically so you can only use the IP address on an instance that was bound to that instance through the EC2 management console.
I just configured one of my instances to use a static IP address other than the one assigned through the management console and rebooted the instance.
I'm still receiving ARP responses on the old address but not receiving ARP responses on the new address at all.
Unfortunately for me, I have a not responding instance (NFS File Server) stuck in a stopping state while I attempt to terminate it.
The IP Address bound to that instance cannot be re-assigned to a replacement instance so now I have to reconfigure
On the whole pricing delima: When you come to think of it, there is a limited amount of static IPs so there must some pricing (supply and demand). This pricing is two fold: 1) for upto a limited number (5 per account) you don't have to pay. 2) if you created one you need to use it if you don't you'll be billed (to prevent every user to get 5 static IPs)