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)
Related
I'm just looking for advice, I can do most of my own research, but I'm not sure where to start. Here's the situation:
I want to be able to deploy 3 vms that have 2 nic's a piece. 1 nic will have a standard IP that AWS provides. The second nic will have a pre-configured internal static IP. Let's say, 192.168.0.100, 101, and 102. That way each vm can talk to each other automatically without needing to know what the external IP is. The purpose of this is so that I can have a small cluster already configured and I won't have to do a lot of work every time I deploy the cluster.
I want this to be repeatable. Let's say I want this for a classroom. Each student has the identical set of clustered VMs. All they need to do is power them on and start working.
So, I think I can do this with Terreform. I don't know if AWS has it's own tooling that can do this also. If it has, I haven't been able to find it yet.
Any suggestions would be greatly appreciated!
In general, every VM gets a private IP, if the VM is public you can assign a public IP which makes the VM accessible from external and also provides internet access, this is be done by source/destination NAT.
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
As long as they are part of you VPC CIDR and available you can specify the IP addresses on instance launch. This can be done via AWS Console, API, CLI, CloudFormation and also with Terraform. The AWS native tools for doing it at scale / repeatable is CloudFormation or maybe also a script that runs AWS CLI commands would work.
https://awscli.amazonaws.com/v2/documentation/api/latest/reference/opsworks/create-instance.html
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-network-interface-privateipspec.html
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.
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 have two EC2 instances from an Ubuntu image, they are located in different regions.
I just want to ask, whether they can communicate over the private IP addresses?
I have opened the required ports with a security group. I use netcat to test the communication, but it only works, when I use the public IP addresses.
It is not possible to communicate between Amazon EC2 regions via the private IP addresses (except if you setup a VPN and respective routing for this, see section VPN Solution below), traffic between regions is in fact passing the public internet and is not distinguishable from any other internet traffic, see e.g. the following FAQs from the Region and Availability Zone FAQ:
Can instances use group-based firewall rules across Regions? - No. Group-based firewall rules only work within a Region. If you need instances to communicate with each other across Regions, you should use CIDR based firewall rules. [...]
What is the cost for data transfer between Regions? - Data transferred from one Region to another is charged at both sides at the Internet data transfer rate.
This applies to an Amazon VPC as well, see e.g. the FAQ Can Amazon EC2 instances within a VPC in one region communicate with Amazon EC2 instances within a VPC in another region?:
Yes, as long as all communication takes place over the Internet
Gateway of each VPC and uses the Elastic IP addresses assigned to the
instances in each VPC. Please note: security groups cannot span
regions. All traffic filtering between instances in one VPC and
instances in another VPC must use the Elastic IP addresses as the
specified source or destination address. [emphasis mine]
VPN Solution
AWS has meanwhile released two walkthroughs describing a solution for Connecting Multiple VPCs with EC2 Instances based on either IPsec or OpenVPN:
Connecting Multiple VPCs with EC2 Instances (IPSec)
please note that this tutorial facilitates Openswan, but you can achieve the same with strongSwan (or even the Linux IPsec stack built in as of kernel 2.6+, see e.g. IPsec L2TP VPN server)
Connecting Multiple VPCs with EC2 Instances (SSL)
Now you can do it with AWS VPC peer connection.
It enables the resources in two VPCs that are in different regions, even in different accounts, to be able to communicate with the private IP address, just like in the same LAN.
One thing you need to know is the CIDR blocks you choose for your both VPCs, they must not be in conflict. Otherwise, the peer connection can't be made successfully.
See the official doc about VPC peer connection.