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.
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.
I've set up 2 instances of Windows Server 2008 on EC2. I want one to act as the database server and the other as the client. For the client app to work it needs to be able to connect to the server instance with ALL of these things:
IP address of the database instance
access through a given UDP port
server name e.g. \\MyServer
an actual physical path through to its database e.g. \\UNC\SharedFolder\MyDatabaseFolder
I'm a complete novice with EC2. Is there anyway I can set this up?
Many thanks
At least three of the four are completely possible and I have worked with similar setups. Maybe someone else knows more about the UDP bit.
IP address of the database instance
That is standard on EC2. All instances have two network interfaces, one EC2 internal and one to the outside world. For communication between instances use the internal one. Data traffic over these interfaces is free.
Access through a given UDP port
I have never tried UDP communication in EC2, but if it works you should probably keep it within a local network of your own, i.e. a virtual private cloud (VPC).
Server name e.g. \MyServer
This kind of host name lookup does not need a name server, although you certainly could run one (preferably within a VPC). If you put the server name and (internal) IP into your hosts file (%systemroot%\system32\drivers\etc\hosts) you don't need a name server, though.
An actual physical path through to its database e.g. \UNC\SharedFolder\MyDatabaseFolder
Folder sharing should work the same as with any other Windows machine, but even that should probably be kept within a VPC.
Setting up a VPC can be a little steep to start with, but the documentation is good and the hard bits are often not needed (such as VPN tunnels). Have a look at the example scenarios and follow the one best matching your needs.
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)
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)?