I have a fairly simple architecture with only two subnets: Public and private. In the same Public Subnet with Internet Gateway configured, I have two EC2 instances:
Linux EC2 instance (Where I run a REST API)
OpenVPN Access Server
https://i.stack.imgur.com/2MHco.png
The problem is, from the Linux EC2 instance, I cannot
ping for example cnn.com
aws ecr docker login (To pull docker images)
Python scripts sitting on the Linux EC2 instance also need call REST APIs from outside world
Thru trial and errors, I found out if I add a Inbound Rule to allow all traffic from 0.0.0.0/0, then I can ping and do those aws/docker commands. This approach is of course a security hole and less than ideal. Any suggestion please?
Thanks in advance.
I had a running instance, and then I became unable to connect to it via http(80) and ssh(22). I tried to reboot the instance, but nothing went up. This has happened to me twice in the past month.
Why does it happen? Can I do anything to fix and/or prevent it from happening?
If I launch a new instance in same region, and it works.
Things to check when trying to connect to an Amazon EC2 instance:
Security Group: Make sure the security group allows inbound access on the desired ports (eg 80, 22) for the appropriate IP address range (eg 0.0.0.0/0). This solves the majority of problems.
Public IP Address: Check that you're using the correct Public IP address for the instance. If the instance is stopped and started, it might receive a new Public IP address (depending on how it has been configured).
VPC Configuration: Accessing an EC2 instance that is launched inside a Virtual Private Cloud (VPC) requires:
An Internet Gateway
A routing table connecting the subnet to the Internet Gateway
NACLs (Network ACLS) that permit through-traffic
If you are able to launch and connect to another instance in the same subnet, then the VPC configuration would appear to be correct.
The other thing to check would be the actual configuration of the operating system on the instance itself. Some software may be affecting the configuration so that the web server / ssh daemon is not working correctly. Of course, that is hard to determine without connecting to the instance.
If you are launching from a standard Amazon Linux AMI, ssh would work correctly anytime. The web server (port 80) would require installation and configuration of software on the instance, which is your responsibility to maintain.
I launched an Amazon Web Service (AWS) EC2 Instance, t2.micro, which must be launched into a VPC.
The VPC has Auto-assign Public IP set to Yes.
DNS resolution: Yes
DNS hostnames: Yes
But on the EC2 Dashboard, the instance still has a blank Public DNS and Public IP. I have tried to restart the instance several times, but it still has not been assigned a Public IP. The 5 Elastic IPs that came with our AWS account have already been used. Is it possible to get a Public IP assigned to a t2.micro instance without using Elastic IP?
I have read the post: EC2 instance has no public DNS,
but I do not have reputation points to be able to add a comment, so I am posting this as new question.
Rightclick on the VPC row in the VPC management console page and select "EDIT DNS Hostname". Set it to "Yes". It´s necessary to allow all the instances with the same VPC.
When you create the new instance in the "Step 3: Configure Instance Details", you need to enable "Auto-assign Public IP".
That´s it! :-)
The most common cause of no public IP address for your EC2 instance is that you're launching your EC2 instance in a private subnet. A private subnet means that any EC2 instances located in that subnet are not directly addressable from the public Internet. In other words, by definition, EC2 instances in a private subnet cannot have a public IP address.
This would explain why checking "public IP address" has no effect, and why you're unable to assign an Elastic IP address.
You can't just relocate an instance from one subnet to another. If you need to do that, you can create an AMI of your instance (right-click on the EC2 instance and click create image), and then launch a new instance from that AMI in a different subnet.
To determine if your subnet is private, look at the Route Table and see if you have an Internet Gateway route. Go to VPC > Subnets > Select a Subnet > Route Table tab. Look for an entry that has something like igw-***. If you see this, it's a public subnet. If you see something like eni-*** / i-***, it's a private subnet.
Also check:
VPC -> Subnets -> Subnet Actions -> Modify Auto-Assign Public IP
Face the same issue today. My EC2 instance has no public DNS thus I'm unable to connect via ssh.
I tried and success with these steps:
Go to VPC > Internet Gateways: make sure an Internet Gateway is created and attached to the EC2's VPC
Goto VPC > Route Tables, select a VPC route, navigate to Routes tab: add a new rule with
++ Destination: 0.0.0.0/0
++ Target: select the created Internet Gateway
Goto VPC > Subnet > Route Table tab: click edit, change to the Route Table with destination 0.0.0.0/0 above
Done.
Hmm. So many responses. All of them on the order of "you did something wrong."
Newsflash: AWS doesn't always work correctly. I've used AWS for a very long time. I've personally witnessed instances that do not start, instances that do not stop, disk corruptions on deployed instances and network failures on running instances.
I've never seen a case where a public IP was not created. Until this morning. Now I can add that to the list.
For the record - here's what I verified :)
Three identical instances in the cluster
All instances are in the same availability zone
All instances have same VPC
VPC DNS settings are correct (resolution / hostnames enabled)
All instances have same subnet
Subnet has: a) public routing table; b) option enabled to create public IP
Plenty of IP space available in the subnet
Two of the three instances receive a public IP. The third does not.
So for any others in the future getting to this post: No, you are not insane. Yes, it is possible that AWS screws up.
In our case, manually terminating the problem instance and issuing a new cluster up..."fixed" the problem.
And - I upvoted the answer that indicated a "launch more like this" from a STOPPED instance had an impact on public IP. Not because it is the correct answer (it is not) but because it demonstrates an admirable response to an otherwise inexplicable situation: trial and error / experimentation. The good old "Gee, what happens if I try this...". As cloud professionals: If all other standard troubleshooting steps fail and the only alternative is to blow away the instance (or subnet, or Lambda function, or DynamoDb, or SNS queue; whatever the failing resource) then it's wise to think outside the box and try other actions.
In other words: keep an open mind.
Go to VPC -> Subnets
And make sure that the Auto-assign public IPv4 address is set to YES
There are many possible reasons. Check the follow.
You need to have a VPC created.
The DNS resolution and DNS hostnames should be enabled.
Choose your VPC -> Actions -> Edit DNS resolution -> enable
Choose your VPC -> Actions -> Edit DNS hostnames -> enable
Into the VPC maybe you need a private and public subnet.
In the private subnet, you need to have a NAT Gateway associate to this.
In the public subnet, you need to have an Internet Gateway associate to this.
You need to enable the auto-assign IP for your public subnet.
Choose the public subnet -> Actions -> Modify auto-assign IP settings -> enable
Later when you launch a new instance in
Step 3: Configure Instance Details.
You should choose your VPC and your public subnet. And in the "Auto-assign Public IP" section choose "Use subnet setting (Enabled)"
I think that that should solve your problem...
I had the same issue. The reason of my issue turned out to be that I was using a route table which was not associated with a subnet.
enter image description here
After I changed my subnet, my instances were assigned public ips.
After creating a Subnet - make sure the Auto-assign public IPv4 setting is set to Yes or Enabled.
After making sure the above setting is turned on - then launch the EC2 instance.
If the above setting is not enabled after Subnet creation - the EC2 instance will be treated as Private and won't have a public IPV4 address.
When I use "launch more like this" option from a STOPPED instance, I'll get a new instance without a public ip. But if I "launch more like this" from a running instance, the new instance has a public ip.
Most likely, the public subnet has no enabled feature for "Auto-assign IPv4". It is selected as "No". And during your instance creation process the default option is "Use subnet setting (Enabled)". That's why newly issued instances cannot get public IP address.
Go VPC dashboard and click Subnets. Select a public subnet and select Modify auto-assign IP settings from Actions list and check Auto-assign IPv4. After saving your changes, your instances will get public IP automatically.
My big "gotcha" on this was when creating a VPC & Subnets from a CloudFormation stack, my Subnets were missing the Property "MapPublicIpOnLaunch" : true.
My Observation :
You need to enable the auto-assign IP for your public subnet. Choose the public subnet -> Actions -> Modify auto-assign IP settings -> enable
Only after the above is done, then launch an EC2 instance and you will start seeing public IP assigned.
Once an EC2 instance created without above setting enabled, that EC2 will not have public IP assigned even after reboot , it already considered that subnet to be private.
Hope this helps!
My Answer:
Please check if you attached a secondary network interface with the instance.
As per AWS Documentations, If you attach another network interface to your instance, your current public IP address is released when you restart your instance. Please read the third point from below.
You cannot manually associate or disassociate a public IP (IPv4) address from your instance. Instead, in certain cases, we release the public IP address from your instance, or assign it a new one:
We release your instance's public IP address when it is stopped,
hibernated, or terminated. Your stopped or hibernated instance receives a
new public IP address when it is started.
We release your instance's public IP address when you associate an
Elastic IP address with it. When you disassociate the Elastic IP address
from your instance, it receives a new public IP address.
If the public IP address of your instance in a VPC has been released, it
will not receive a new one if there is more than one network interface
attached to your instance.
If your instance's public IP address is released while it has a secondary
private IP address that is associated with an Elastic IP address, the
instance does not receive a new public IP address.
AWS Documentation Link for more reference: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html?icmpid=docs_ec2_console#concepts-public-addresses
I have few EC2 instances across VPC and non-VPC.
VPC Instance
VPC-Dev1
VPC-Dev2
Without VPC
EC2-Dev1
EC2-Dev2
I can access (RDP) all the servers from outside world. I have given RDP access to all (0.0.0.0/0) to ensure that I am not missing out anything.
However, I can't access VPC-Dev1 from EC2-Dev1 or vice-a-versa. Is there any specific firewalls related setup I need do to allow AWS instances to get access to each other?
Any help much appreciated!
If you are trying to make the calls using the private IPs, try using the public IPs.
Amazon only gives you a certain number of static ip address and the local (private) ips of each EC2 instance can change when the machine is restarted. This makes creating a stable platform where EC2 instances depend on each other ridiculously hard to use as far as I can tell.
I've search online a lot about various solutions and so far have found nothing reasonable outside of assigning an elastic ip address on ever EC2 even if its not public facing. Does anyone have any other good ideas that is actually easy to execute on?
Thanks!
See the AWS team's response to question Static local IP:
The internal IP address of EC2 instances is allocated via DHCP. On
instance shutdown, or when the DHCP lease expires, the IP address is
returned to the general EC2 DHCP pool of addresses available for other
instances.
There is no way to guarantee that you will obtain the same DHCP
address across reboots.
Edit: The answer is to use Amazon VPC. There is no downside except a trivial amount of extra setup because now you control the router. It's a world apart from plain old EC2 instance on AWS. It's so necessary in fact that VPC will be enabled for all future AWS setups by default. See this post for more information: http://www.reddit.com/r/aws/comments/1a3n0r/ec2_update_virtual_private_clouds_for_everyone/
The stock answers are:
Use AWS VPC so you have complete control over instance addressing
Use Elastic IPs, which will resolve to the instance's local address (not the public, as you'd expect) when used to communicate between EC2 instances
I stumbled upon third option. There's ec2-ssh by the Instragram folks. It's a python shell script that you install globally and lets you both query the public dns of your ec2 instances by tag name and also ssh in via tag name as well.
The documentation for it is virtually nonexistent. I've written down the steps to install below:
To install ec2-ssh:
sudo yum install python-boto (python wrapper for ec2 api)
git clone https://github.com/Instagram/ec2-ssh
In your ~/.bash_profile set your AWS access key and secret like so:
export AWS_ACCESS_KEY_ID=XYZ123
export AWS_SECRET_ACCESS_KEY=XYZ123
cd into the bin folder of the repo, there will be two files:
ec2-host and ec2-ssh
copy them to your /usr/bin or /usr/local/bin.
Now you can do awesome stuff like:
$ ec2-host ZenWorker
ec2-999-xy-999-99.compute-1.amazonaws.com
and
$ ec2-ssh ZenWorker
Connecting to ec2-999-xy-999-99.compute-1.amazonaws.com.
Note that in your regular shell scripts you can use backticks to call these global tools. I've timed these calls and they take between 0.25 and 0.5 second using an EC2 instance, so that's really the only downside. Perhaps you can live with the delay, or use the fact that public DNS only changes for an instance on reboot to work up a solution.
Note that these two programs are commandline scripts and you don't need any Python knowledge to use them. For PHP fans, or those that also want an easy way to scp files without knowing the changing public DNS, you can checkout ec2dns.
I was in the same situation once. I still dont have the expertise to solve it properly. My ugly solution was to use elb not really for load balancing but just for the endpoint.
But I think a good solution can be obtained by using aws vpc.
Here's another Ruby solution for Updating Route 53 DNS from instance on AWS. You shouldn't reference raw 3rd party system IP addresses in your applications or server configurations.
you can change Ip Address using Elastic Ip:
You Can Do Using C# Code:
var associateRequest = new AssociateAddressRequest
{
PublicIp = your Elastic Ip,
InstanceId = Your Instance Id Which You Assign
};
amazonEc2Client.AssociateAddress(associateRequest);
after That DeAssociate It.
var disAssociateRequest = new isassociateAddressRequest(publicIp.ElasticIpAddress1);
AmazonEc2Client.DisassociateAddress(your Elastic Ip);
your Public Ip Will Change