I've created an EC2 instance inside a public subnet (so that I can access it from my home network) and I have created some Lambda's inside the private subnets of my VPC.
My 1st lambda can freely access the internet (through a NAT Gateway) and do its job. Which is to fetch a file from the internet and upload it to S3, once per day.
My 2nd lambda is supposed to retrieve this file from S3 (which it does without issue) read the file & then upload the data to MySQL running on the EC2 instance. It is unable to connect to the Database (using either the EC2's public or private IP's) and the Cloudwatch logs show that the session times out, making me think this is a networking issue.
I have a 3rd lambda that will also need to interact with the EC2/DB instance.
My security group allows for all incoming traffic from my home network IP, the NAT gateway & the VPC IP range. All outbound traffic is allowed.
I appreciate its not usual to have an EC2/DB set up this way, in a public subnet, but its my preference to interact it with it this way from home using Sequel Pro.
However, is my set up even possible? Eg can my private subnet lambdas interact with a public subnet ec2 instance? if so, does anybody have any ideas how I can make this happen?
It appears that your situation is:
An Amazon EC2 instance running in a public subnet, with MySQL
The EC2 instance has a Security Group allowing all incoming traffic from your home network IP, the NAT gateway and the VPC IP range
An AWS Lambda function connected to a private subnet of the same VPC
A NAT Gateway allowing private subnets to connect to the Internet
The Lambda function is unable to connect with the MySQL database running on the EC2 instance
The normal security configuration for this scenario would be:
A Security Group on the Lambda function (Lambda-SG) that allows all Outbound access (no Inbound required)
A Security Group on the EC2 instance (EC2-SG) that allows inbound access from Lambda-SG on port 3306, plus whatever inbound permissions you want for accessing your instance via SSH, etc.
Given that your Security Group includes "the VPC IP range", this should be sufficient to permit inbound access.
The Lambda function should reference the EC2 instance via its private IP address to keep traffic within the VPC. By default, all subnets within a VPC can communicate with each other unless the Network ACLs have been modified (and they should generally be left at default values).
This means that the only remaining explanation would be that the MySQL database is not accepting traffic from the VPC IP range. (I'm not a MySQL person, but I know that PostgreSQL requires incoming IP ranges to be defined, so this might be true for MySQL too.)
To diagnose what might be happening in your network, I recommend:
Launch another Amazon EC2 instance in the public subnet
Connect to the new instance and try to connect to the MySQL database via the private IP address
If that works, repeat the process but from an EC2 instance in the private subnet. To use this you will need to connect to the 'public' EC2 instance, and from there connect to the 'private' EC2 instance. Then, try and connect to MySQL from that private instance.
These steps will progressively let you identify where the network problem might lie. Let us know what you find!
I have an EC2 instance that hosts a Ruby on Rails App which in turn connects to a RDS instance. Everything is working fine for several months until the rails app encountered an issue wherein the connection to the RDS database times out.
It turns out that when I checked the EC2 instance in the dashboard, the private IP address of the EC2 instance is not part of the inbound restriction of the security group that I'm using. I'm sure that I didn't remove the security group entry of this instance. However, I didn't record the private IP address of this instance until the issue happened.
So my question is, is it possible that an EC2 instance will change its private IP at any given time? If yes, is there a way to always allow this instance to access my RDS instance? I already tried using the public IP instead for the security group but it didn't work.
No. An EC2 instance will always retain the same Private IP address. (The Public IP address can change after a stop/start, but the Private IP address will never change.)
Regardless, rather than putting an IP address in a security group, you should reference another security group.
For example:
Create an App Security Group:
Associate it with the EC2 instance
Open ports required by your application (eg HTTP port 80)
Create a Database Security Group:
Associate it with the RDS database
Open the database port, with Source = App Security Group
This means that any EC2 instance that is associated with the App Security Group will be permitted to communicate with the database -- this will work for multiple instances and there is no need to specify any specific IP addresses.
No. The private IP is associated with the EC2 instance for life of the instance. Until you terminate the instance, the private IP remains with the IP.
It will never change.
Someone may have modified the security group to allow a different set of IPs. If you know how to check CloudTrail, you can find out the reason for this new behavior.
We have two AWS instances (Instance A and Instance B) which are running in the same VPC. There is an internet facing service on Instance A which is restricted (via security group) to a subset of IP addresses. Instance A has a DNS entry so the service can be accessed via someservice.example.org.
When trying to access the service from Instance B it works correctly if we used the VPC internal IP address however we cannot seem to get the correct security group configuration to allow this instance access via the public DNS.
We have added the 'default' VPC security group to Instance A but we're still unable to access this service directly. We also have the same problem trying to configure access to Instance A from other VPCs.
I know that we can create a private DNS for the VPC which could solve the problem when we are in the same VPC but this doesn't get around the problem when running in another VPC.
This sounds like a DNS resolution issue. If you are using Route53 for DNS the easiest way to fix this is to create a private Route53 DNS zone for your VPC and add something like:
CNAME 'someservice.example.org' that points to the instance's internal IP address.
Note that you really want to use the internal private IP address whenever possible. It will keep the network traffic within your VPC, which will be much faster and more secure. It may also be cheaper for you, at least if the instances are also within the same availability zone. You can read more about that on the EC2 pricing page in the Data Transfer section.
Also note that you can't open up the security group to allow only instances from your VPC/security group to access something via the public IP. This is because the traffic hitting the public IP is seen as coming "from the internet", not from your VPC. You would have to grant access to the servers via their public IP addresses instead of their security groups.
You mention also using a second VPC, but that would be a separate problem that could be addressed via VPC Peering.
A guy I work with gave me the EC2 credentials to log onto his EC2 console. I was not the one who set it up. Some of the instances show a public dns name and others have a blank public DNS. I want to be able to connect to the instances that have a blank public DNS. I have not been able to figure out why these show up as blank.
I had the same problem an solved it. Have a look at the step-by-step instructions:
Go to console.aws.amazon.com
Go To Services -> VPC
Open Your VPCs
select your VPC connected to your EC2 and
select Actions => Edit DNS Hostnames
---> Change DNS hostnames: to YES
There is a actually a setting in the VPC called "DNS Hostnames". You can modify the VPC in which the EC2 instance exists, and change this to "Yes". That should do the trick.
I ran into this issue yesterday and tried the above answer from Manny, which did not work. The VPC setting, however, did work for me.
Ultimately I added an EIP and I use that to connect.
Sounds like the instance was launched in VPC and while doing so, the check-box for Automatically assign a public IP address to your instances was not checked. Hence the instance does not have a public IP
You can assign an Elastic IP to this instance and then log in using that IP.
In my case I found the answer from slayedbylucifer and others that point to the same are valid.
Even it is set that DNS hostname: yes, no Public IP is assigned on my-pvc (only Privat IP).
It is definitely that Auto assign Public IP has to be set Enable.
If it is not selected, then by default it sets to Use subnet setting (Disable)
This is the tip provided to resolve the issue which does not work:
Tip - If your instance doesn't have a public DNS name, open the VPC console, select the VPC, and check the Summary tab. If either DNS resolution or DNS hostnames is no, click Edit and change the value to yes.
Assuming you have done this and you are still not getting a Public IP then go over to the subnet in question in the VPC admin screen and you will probably discover "Auto-Assign Public IP" is not set to yes. Modify that setting then, and I know you don't want to here this, create a new instance in that subnet. As far as I can tell you cannot modify this on the host, I tried and tried, just terminate it.
Go to AWS Console.
Go to Services and select VPC
Click on vpc.
select the instance and click on Action.
Select Edit DNS Host name click on yes.
At the end you will get your Public dns.
For me problem was in subnet settings.
Open https://console.aws.amazon.com/vpc
Go to subnets in left menu
Choose your subnet
Modify auto-assigning IP settings to enable
It is related to the VPC's feature called "DNS Hostnames". You can enable or disable it. Go to the VPC, under the Actions menu select the "Edit DNS Hostnames" item and then choose "Yes". After doing so, the public DNS of the EC2 instances should be displayed.
Here I will summarize the most common issues that occur:
When you create a custom VPC, if you want aws resources such as ec2 instances to acquire public IP addresses so that the internet can communicate with them, then you first must ensure that the ec2 instance is associated with a public subnet of the custom VPC. This means that subnet has an internet gateway associated with it. Also, you need to ensure that the security group of the VPC associated with ec2 instance has rules allowing inbound traffic to the desired ports, such as ssh, http and https. BUT here are some common oversights that still occur:
1) You must ensure that DNS hostnames is enabled for the VPC
2) You must ensure the public subnet linked to the EC2 instance has its 'auto-assignment of public ip' flag enabled
3) If the instance is already created, then you might need to terminate it and create a new instance for the public IP and public DNS fields to be populated.
Just launch another instance (and also delete the one in question if it has no use) and make sure this time you check "Autoatically assign a public IP address to your instance". If not then as slayedbylucifer suggested; assign an Elastic IP (EIP) to the instance and then log in using that IP. Be careful though, if you are running the free AWS tier, an EIP will cost you money-- that's a whole 'nother topic..
First of all, there can be two reasons for this:
You have created your own VPC and forgot to enable Public DNS.
To solve this :
i) Go to AWS VPC console and select the VPC you have created.
ii) Then click on Actions and then enable DNS Resolution.
OR
You have not enabled public ip-assign option in EC2 configuration.
Here you cannot change the setting; so create an ami image and then recreate the instance from that.
After verifying VPC and Subnet settings, my EC2 instance still didn't have a public DNS. After a day of searching for a resolution, I finally figured it out.
I had to create a new Elastic IP address, then associate it to my instance.
From the EC2 Dashboard:
Go to Elastic IPs from the sidebar.
Click Allocate new address, then Allocate.
Go back to the EC2 Dashboard. Go to Network Interfaces.
Select the EC2 instance without a public DNS. Then Actions - Associate Address.
The Address field, select the new elastic IP address.
The Associate to private IP address field, select the private IP address with no public DNS.
Click Associate Address.
Your EC2 instance should now have a public DNS.
Go to VPC
Select your VPC
Click actions and choose Edit DNS hostnames
Tick Enable for DNS Hostnames
Click save changes
The problem is that the DNS Host name in your VPC is dropped. You can easily enable it like this:
Go to your instance in the console, then click your VPC ID.
In your VPC, select the Edit DNS Host names option
Set it to enabled and save your changes.
Now, in your EC2 instance window you can find the DNS:
The change to the DNS Hostnames setting can also be done using the AWS CLI:
aws ec2 modify-vpc-attribute --vpc-id $vpc_id --enable-dns-hostnames '{"Value": true}'
(Where $vpc_id is the ID of the VPC that your instance is attached to.)
As soon as the VPC is updated the instance will gain a public DNS.
For those using CloudFormation, the key properties are EnableDnsSupport and EnableDnsHostnames which should be set to true
VPC: {
Type: 'AWS::EC2::VPC',
Properties: {
CidrBlock: '10.0.0.0/16',
EnableDnsSupport: true,
EnableDnsHostnames: true,
InstanceTenancy: 'default',
Tags: [
{
Key: 'env',
Value: 'dev'
}]
}
}
If the instance is in VPC, make sure both "DNS resolution" and "DNS hostnames" is set to "yes". You can do this in the Aws console UI. HTH!
Go to VPC console, select your VPC, and click ACTIONS menu, select Edit DNS Hostnames - select Yes. That should fix it.
I tried to fix the 'no public DNS'
once the EC2 was up and running, I couldnt add a public DNS
this is even after following the above steps making mods to the VPC or the Subnet
so, I had to make modifications to the subnet and the vpc, before starting another instance, and THEN start up a new instance.
the new instance had a public DNS. That is how it worked for me.
For those who are using Terraform.
To enable the DNS hostnames, use the following line in your VPC like this:
resource "aws_vpc" "app_vpc"
{
enable_dns_hostnames = true # Add this line
cidr_block = var.vpc_cidr
tags = { Name = "mostafa_vpc" }
}
You don't have to assign public ip address to your instance.
you can use NAT instances or NAT Gateway.
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html
For the public IP / DNS first, you must have a running EC2 Service ( That can be Instance / Docker / Lightsail. for any of the services you will have two different IPs ( Private & Public ) also the security group available under the security Tab once you selected actively Instance.
STEP-1:
You can enable according to the port Usage like if you wanted to host a website using HTTP & HTTPS Ports
EC2->Security Group -> Edit Inbound Rules -> Added or Remove required ports.
like 80,443,22 etc and traffic source for the port ( if you want to make the port open for all select anywhere or if you want to open the application for the selected IPs- Enter IPV4/IPV6 manually.
once you are done with the above configuration, Create Elastic IP and attached it to your Running EC2 instance. Once you attached the IP with the instance your Public IP will be the Elastic IP
STEP-2:
AWS offers you one more service called Route53. Here you can create Hosted Zones and enter the domain name without www after creation, you will get the Name Server value for the hosted zone.
for more info about Route53 https://aws.amazon.com/route53/