Amazon EC2 - What is private DNS and private IP? - dns

The details of Amazon EC2 mentions Public DNS, private DNS and private IP. I know public DNS can be used to reach the instance after configuring the security group.
I am not able to understand
What is private DNS?
What is private IP?
Why do we need these number these two when we have public DNS to reach the instance?

EC2 instances are connected to a private local area network and given IP addresses on that network. Those are the 10.x.x.x addresses you see as the "private IP". Amazon provides a DNS service that associates names with those private IP addresses. That's the private DNS.
Unless you are on a VPC, Amazon also connects those private IP addresses to regular routable IP addresses, and gives DNS names that resolve to those public IPs. As near as I can tell, this is pretty much just like an Elastic IP address except that each time you shut the machine down and restart it, you'll get a different one instead of the same one each time.
A neat trick with the public DNS is that the same name will resolve to different addresses depending on who is asking. Machines on Amazon's private network (that is, other EC2 machines in the same AZ, maybe the same region) will have the public DNS resolve to the private IP. That way, traffic between machines inside EC2 stays inside EC2. Machines on the regular internet will have the public DNS resolve to the public IP.

Related

Azure virtual machine scale set agents public IP

I was following this article - Azure virtual machine scale set agents. Everything is good and I am able to run my custom images to perform builds and deployments.
One thing that is missing there - what if agent needs to access some IP restricted resource? Previously (with a simple VM running as agent) it was easy to whitelist public IP of a given agent. With those scale sets (and --load-balancer "") I am not sure how to get them to use a static IP (preferably only 1 outgoing public IP for all VMs in a set)
Any suggestions?
When you use a Load Balancer in front of the VMSS with only one static public IP address, then all the VMSS instances only can access outside through that one static public IP address. It's easy to achieve it, you just need to configure the public IP address as static. Then you put that public IP address in the whitelist for the restricted resource.
In this way, all the instances access the restricted resource via the static public IP address and it's in the whitelist.

Sticky Elastic IP on AWS EC2

A specific 'Elastic IP' is always associated with the EC2 instance launched from one of my custom AWS AMI.
ubuntu#ip-:~$ sudo ip addr show lo
inet 157.XX.XX.235/32 scope global lo
It is also persistent across server restarts. Can't find any configuration for the elastic IP in /etc/network/interfaces.
Is this setting coming from EC2 instance metadata and cloud-init? Couldn't find anything in /var/log/ as well. There is no user supplied user_data.
Elastic IP addresses exist within the VPC networking layer and are used by Internet Gateways.
When traffic enters a VPC with an Elastic IP address as the destination, the Internet Gateway performs a reverse NAT and translates the public IP address into a private IP address within the VPC. The EC2 instance receives the request on its public IP.
When traffic sent from an instance with an Elastic IP, the traffic comes 'from' the private IP address, but it is translated into the public IP address when it goes through the Internet Gateway.
So, an Amazon EC2 instance is never actually aware of its public IP address. It only sees traffic via its private IP address. This has the benefit that the Elastic IP address can be reassociated with another EC2 instance and no configuration changes are required on the old or new instances. It's magic!
I'm not familiar with the command you are using. When I run it on an Amazon Linux instance that has an Elastic IP address, the command does not show the public IP address of the instance. Perhaps this is different on Ubuntu, so somebody has configured it somewhere on the instance (which they should not do, since it could change through reassociation).

Outgoing ip using ACI in a VNET

I'm using the ACI in a private VNET. My problem is, the outgoing ip from this container is not my public IP used in Azure Gateway, is some random ip.
There's some way to fix somehow this outgoing ip from some container using ACI?
OBS: I tested with a public container, I had a public ip to incoming, but for outgoing was different :|
Thanks!
For your issue, when you create the ACI in the VNET, you just can access the resources inside the VNET and the outgoing IP is a private IP of the VNET, so the IP is static if you do not delete the ACI.
When you create a public ACI, it can access the Internet. This time, as I think, the ACI has two public IP, one is the public IP or the FQDN of the ACI to access from the Internet. And another is the public IP of the host machine that the ACI deploy in. When you access the ACI from the Internet, you need to use the public IP or the FQDN which Azure provide you. But when you access the Internet inside the ACI, the outgoing IP is the host machine's public IP. You cannot decide which host machine you can use, so does public IP of the host machine.
If you need to decide the outgoing IP and must be a static one. You can install the docker server in the VM with a static public IP, then create containers in the VM. Then the outgoing IP is the public IP of the VM.
Or you can use the AKS, create the pod and associated with a service that uses the Load Balancer type. Then the outgoing IP is also static and it's the service public IP.

Source security group isn't working as expected in AWS

I have an EC2 node, node1 (security group SG1) which should be accessible from another EC2 node, node2 (security group SG2) on port 9200. Now, when I add an inbound rule in SG1 with port 9200 and specify SG2 as source in Custom IP section, I can't access node1 from node2. On the other hand, if I specify an inbound rule in SG1 with source as 0.0.0.0/0 or IP of node2, it works fine. What is wrong in my approach?
Are you attempting to connect to node1's public or private address? From the documentation:
When you specify a security group as the source or destination for a
rule, the rule affects all instances associated with the security
group. For example, incoming traffic is allowed based on the private
IP addresses of the instances that are associated with the source
security group.
I've been burned on this before by trying to connect to an EC2 instance's public address... sounds very similar to your setup, actually. When you wire up the inbound rule so that the source is a security group, you must communicate through the source instance's private address.
Some things to be aware of:
In EC2 Classic, private IP addresses can change on stop/start of an EC2 instance. If you're using EC2 classic you may want to look into this discussion on Elastic DNS Names for a more static addressing solution.
If you set up your environment in VPC, private IP addresses are static. You can also change security group membership of running instances.
Reason: Inter security-group communication works over private addressing. If you use the public IP address the firewall rule will not recognise the source security group.
Solution: You should address your instances using the Public DNS record - this will actually be pointed at the private IP address when one of your instances queries the DNS name.
e.g. if your instance has public IP 203.0.113.185 and private IP 10.1.234.12, you are given a public DNS name like ec2-203-0-113-185.eu-west-1.compute.amazonaws.com.
ec2-203-0-113-185.eu-west-1.compute.amazonaws.com will resolve to 203.0.113.185 if queried externally, or 10.1.234.12 if queried internally. This will enable your security groups to work as intended.
This will enable you to use an elastic IP as you simply use the Public DNS entry of the elastic IP. Also, having the DNS resolve to the internal IP means that you are not incurring bandwidth charges for your data between instances:
Instances that access other instances through their public NAT IP
address are charged for regional or Internet data transfer, depending
on whether the instances are in the same region.
The Public DNS didn't work for me.
What I did instead was create a custom inbound rule using the security group of the other instance.

Using Route53 as private DNS

I would like to use Route53 as private DNS in order to map hosts to AWS private IP addresses.
The hosted zone we are using for testing is not declared in any registrar (company-test.com.).
The ActiveMQ server url is activemq.company-test.com and it maps to (A record) private IP address of the AMQ server. This url is only reachable by other ec2 owned by the same aws account.
My question is how to configure ec2 instances so they could reach the ActiveMQ server WITHOUT having to buy a new domain company-test.com ?
Thank you!
You could assign an Elastic IP to your ActiveMQ instance.
Elastic IP addresses are static IP addresses designed for dynamic
cloud computing. An Elastic IP address is associated with your
account, not a particular instance, and you control that address until
you choose to explicitly release it. Unlike traditional static IP
addresses, however, Elastic IP addresses allow you to mask instance or
availability zone failures by programmatically remapping your public
IP addresses to any instance associated with your account.
Another option is to set up a Virtual Private Cloud (VPC), and launch your ActiveMQ instance there. Your private IP address will not change on reboot. Another feature of VPC is the use of Elastic Network Interfaces (ENI). You can move the interface between different instances if needed.

Resources