I m looking for a way to communicate (https requests) from a vpc A to another vpc B.
VPC A is behind an Elastic load balancer (ELB) with 3 EC2
VPC B has one server for the moment and not behind an ELB
On my ELB, when i try to add a new rule with the new target group i created ,I can't select it in the list. It's probably because it s on other VPC isn't it?
I tried by a peering connection like this:
ASk : VPC A
Acceptor : VPC B
I check both dns resolutions (from A to B and B to A )
The peering connection is active.
I change my routable tables :
I added on VPC A routage the peering connection with the public ip
of a server VPC B
I added on VPC B routage the peering connection with the public ip
of a server(master) VPC A
No difference i can t select it on my ELB rules
What i miss ?
Could you help me please?
Cheers
You are not able to use a target group in one VPC, within the load balancer from another VPC.
There is functionality to allow an instance from another peered VPC (assuming that it is in the same region) however. If you create an IP based target group (in the VPC with the ALB) you can specify the IP address of the instance in the peered VPC.
More information about this is available in: New – Application Load Balancing via IP Address to AWS & On-Premises Resources | AWS News Blog
Related
I have configured VPC peering connection between VPC A and VPC B (they are in different accounts but in the same region), and when I try to resolve the domain name of a service (e.g. sometest.com) that is in the VPC B from an instance VPC A, it is supposed to point to a private IP but it resolves to the public IP. The route tables for both VPCs have corresponding entries for peer connection, also security groups allow traffic from/to the peered VPC, and both VPC have "Enable DNS resolution/hostnames enabled.
I'm not sure why it resolves to the public IP - what am I missing?
you need to have vpc-association-authorization established between 2 VPC's and private zones to be able to resolve private hosted zone addresses from 1 vpc in one region/account to another vpc in another region/account
you can follow this step to step guide : https://aws.amazon.com/premiumsupport/knowledge-center/route53-private-hosted-zone/
I have an EKS cluster with worker nodes in private subnet. The worker nodes can access internet via the nat gateway. I have a Route53 hosted zone record routing traffic (alias) to a load balancer.
When I try to access the url (route53 record) from a pod within the EKS cluster, it times out. I tried allowing the worker nodes security group in the inbound rules of the load balancer security group but it does not work. Only thing that works is if I allow the public IP of the nat gateway in the inbound rules of the load balancer security group.
I am sure this setup is very common. My question is, is the solution of allowing the nat gateway public ip in the inbound rules of the LB SG the correct way or is there a better cleaner way to allow the access?
based on what you have described here, it seems like you have a internet facing load balancer and trying to access it from the pod. In this case, the traffic needs to go out to internet(through nat gateway) and come back to the load balancer, that is why it only works when you add the public IP of nat gateway to load balancer's SG.
Now, in terms of the solution, it depends on what you are trying to do here:
if you only need to consume the service inside the cluster, you can use DNS name created for that service inside the cluster. in this case the traffic will stay inside the cluster. you can read more here
if you need to make the service available to other clusters but same VPC, you can use a private load balancer and add the security group of worker nodes to the load balancer SG.
if the service needs to be exposed to internet, then your solution works but you have to open the SG of the public load balancer to all public IPs accessing the service.
I have two instances in public subnet of 2 different VPCs.
To allow communication between them, I have to add public IP of one instance to the other.
If one of the server is changed, I need to add the IP again to other servers security group.
If I just add security group of one VPC to other or even all the allowed IPs of VPC, it does not work.
So I am looking for a workaround to not add IP each time .
Facing this issue because both servers are in public subnet.
VPC peering is already present bwteen both VPCs. issue is communication between public subnets in different VPCs
There should be no need to use the public IP address of the instances. The instances should communicate with each other via their private IP address across the VPC Peering connection.
The best way to do this is:
Create a security group (SG-A) and assign it to Instance-A
Create a security group (SG-B) and assign it to Instance-B
SG-A should permit inbound connections from SG-B
SG-B should permit inbound connections from SG-A
There is no need to reference specific IP addresses. Referencing the other security group will automatically enable communication on the chosen port(s).
See: Updating Your Security Groups to Reference Peer VPC Groups - Amazon Virtual Private Cloud
A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them privately. Instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, with a VPC in another AWS account, or with a VPC in a different AWS Region.
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html
https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html
We have two AWS accounts:
Account A have a VPC with 172.31.21.0/16 subnet.
Account B have 3 VPCs:
VPC 1 : 172.31.0.0/16 Default
VPC 2 : 172.32.0.0/16
VPC 3 : 172.30.0.0/16
We have an EC2 on Account A's VPC, that needs to talk to RDS(MySQL) on Account B's VPC 2 but I cannot connect the RDS from EC2 on Account A.
Is the problem caused by Account B's VPC 1 which is using the same subnet as Account A's VPC?
If so, how can we resolve the issue?
Do you have 172.31.21.0/16 or 172.31.21.0/24? Having the first scenario is useless. Did you set up the VPC peering connection and tried to add routes? I believe you will have problem with network range overlapping. Also VPC peering connection will work if you're using the same region in both accounts.
presumably you already have a peering connection ( a pcx ) for A -> B
So either
1) alter the addressing on Account B VPC 1 so that it doesn't overlap with Account A VPC
2) add an explict route for Account B VPC 2 route table sending 172.31.21.0/16 to the pcx. But in this case routing to Account B VPC1 from VPC2 will be broken for some addresses
If only 1 server connection is required, you can setup a EC2 instance and attach to EIP. Then use that EC2 as SSH tunnel that connect to the RDS. Then another VPC can connect to the EC2 secure tunnel.
(Background info)
VPC are virtually isolated, Even within the same AWS account.
Connecting VPC A to VPC B is NOT POSSIBLE, unless you
i. Setup AWS VPC PEER. or
ii. assign EIP to the resource you want to connect, then everyone connect through the public IP, or
iii. Create some sort of VPN routing.
However, in case of i,iii because both your account A and B using 172.31.X.X/16, VPC peering will NOT works, even VPN setup will failed due to same IP network subnet used.
Nevertheless, you may use NAT to share particular resources using VPN, but it will be a "limited VPN".
In addition, you cannot use AWS NAT gateway features for NAT, because that services is only mean for NAT connection from VPC private network to internet.
You can checkout AWS this link for example of multiple VPC peer connection.
I'm putting the instances behind the aws loadbalancer, I have configured the routable and attached the IGW to it, created the loadbalancer and added this instance to the aws loadbalancer every things work well, the endpoint URL of the AWS loadbalancer able to load the HTTP pages
Now i have removed the IGW from the route table and tested it again, the AWS loadbalalncer endpoint URL not able to load the page, but the instace status shows in AWS loadbalancer as inService
Why the IGW is required when loadbalancer is configured over private subnet, it technically Mean it's a public subnet, which is blocking me to create a NAT inatance
A subnet without a default route pointing to the igw-xxxxxxxx Internet Gateway object is, by definition, a private subnet. If you remove the igw from a public subnet, you now have a private subnet.
Placing an Internet-facing load balancer (ELB) in such a private subnet is incorrect.
It sounds as though you are making a commonly-made -- but incorrect -- assumption that the ELB should be configured in the same subnets as the instances behind it. This is also incorrect.
Provision the ELB in public subnets, without regard to the subnets the instances behind it were placed in.
In summary:
Internet-facing ELB requires a public subnet for placement.
NAT instance requires a public subnet for placement.
The instances that use these services (NAT and ELB) belong in different -- private -- subnets, different subnets than the ELB and NAT instances.
ELB and NAT can be placed together in the same subnets, or separately, as long as the subnets are public (have the IGW as their default route) and are in the same availability zones.
I believe you cannot do anything without the IGW attached to the routing table where the subnet is attached to.
Another way to do this is to spin off a NAT instance(can be found in AWS marketplace) in the public subnet, add it to your private route table where your original instance is on (0.0.0.0/0 - instanceid) all the traffic will be routed through the NAT instance.
Here mainly we have to see two things, provided subnet for the elasticloadbalancer is public or private.
Every VPC should have one IGW to connect to the public, every trafic should go through the IGW only. If VPC connected to the IGW, IGW distribute internet to the all instance which are in that VPC, if route table changed to the particular rt, internet traffic can send to only that instance. Here in ELB instance is in service because both are in the same VPC and can communicate each other means checks the status. This IGW will work main role when we are using the NAT.
Always we provide ip range for the IGW or rt as 0.0.0.0/0, it represents as public.
The following link will explain more : http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html
This small explanation might be helpful for someone.
Let me cover your two questions
the AWS loadbalalncer endpoint URL not able to load the page, but the instace status shows in AWS loadbalancer as inService
This is the default behaviour of load balancer , since internally load balancer and your instance may be in the same VPC so they are able to communicate that is why loadbalancer is showing inService status.
Second question Why the IGW is required when loadbalancer is configured over private subnet, it technically Mean it's a public subnet, which is blocking me to create a NAT inatance
You need IGW if you want to access any resources especially EC2 , Loadbalancer from internet. however if you put your load balancer in private subnet it means IGW is not associated with the subnet having loadbalancer in it and hence this load balancer is not accessible outside your VPC that is reason that you were not able to load your page.
NAT instance is usually used when you want your private subnet instances should be able to initiate request over internet and has nothing to do with normal load balancing setup unless and untill you want dont want to install any updates from internet to your instance.
You are trying to access webpage publicly and removing the route entry IGW from the loadbalncer subnet.
The Subnet without IGW will become Private, Hence you can't access it.
First, a subnet with route table that route traffic via the internet gateway (IGW) is a public subnet. An IGW is required because the subnets created in AWS VPC are internal IPs and as internal IPs are not routable via the internet, traffic to and fro EC2 instances that belongs to an internal IP needs a way to complete these request. This is where an IGW comes into play. The IGW allows your EC2 instance to make outbound request to the internet and allows other user/client to make inbound request to your ec2 instance.
A public subnet are group of IPs (called subnets) in your VPC that allows internet traffic to and fro your ec2 instance. A subnet without an Internet gateway is a private subnet. As you already guess no traffic is allowed in or out.
That said, instances in VPC which are in Private subnet still need to initiate an outbound request to the internet to download software or perform update. In this case you have to create and attach a NAT gateway or NAT instance to the private subnet. NAT Gateway and NAT instance only allow outbound traffic to the internet but not the the other way round. In some cases you might want your production EC2 to be in the private subnet and ELB in public subnet for security reason.
ELB usually belong to the public subnet so it reachable from the internet as is your case as well.
TO answer some of your question - when you deleted the IGW from the route table, your ELB automatically becomes a private subnet as such your web page stops loading.
Also, you could still see the ec2 instance behind the ELB as InService even when you deleted the IGW because the ELB and EC2 instance can communicate via the internal IP as they are in same network or VPC.
The ELB needs a route to the internet in order to send you the response over internet.. As simple as that.
Configure your ELB in public subnet, regardless of where your instances are present.
Basically there are two types of load balancers.
1)Internal
2) External
Internal load balancers are those which are launched in a private subnet which will be accessible only internally by the instances on same vpc of the internal elb
External load balancers are which are accessible over the internet which should be launched in a subnet which has internet gateway attached to it and which has route table configured properly to route the requests.
If you attach an internet gateway to a subnet it becomes a public subnet.Also if you create a load-balancer which you need to be accessible from internet it should be a External load balancer and aws will not allow it launch in a private subnet.The instances are showing in service because its communicating internally using private ip-address.