I'm preparing for AWS Certificate Associate. Have some concept questions about AWS VPC.
For Elastic Network Interfaces (ENI), the main text in the study guide says and I quote:
It’s possible to attach additional ENIs to an instance. Those ENIs may be in a different
subnet, but they must be in the same availability zone as the instance. As always, any
addresses associated with the ENI must come from the subnet to which it is attached.
while in the summary of this chapter, still in study guide says:
Any
additional ENI you attach to an instance must be in the same subnet as the primary ENI.
1.1 Are the bold parts in the above two statements contradictory? Because one says ENIs should be in the same subset while the other says in the same AZ, which one is right?
1.2 How to interpret the relationship between the bold part and the italic part in the first statement? Is it like the ENI can be located in other subnets, but the address should point to the instance that it has been attached to? Sounds kind of weird.
About difference between NAT Gateway and NAT Instance.
The book states NAT Instance can connect to instances that don't have public IP, while NAT Gateway cannot. Just want to clarify, does this "instance" means the destination instance in the Internet, instead of the sourcing instance within VPC? Since the reason to adopt NAT devices (no matter gateway or instance) is because the sourcing instance in private cloud doesn't have public IP?
Thanks!
An instance can have multiple ENIs, each in a different subnet (within the same Availability Zone). I recommend that you try it yourself to confirm. In fact, that is good advice for everything you do in AWS because the Certification is meant to prove that you have the knowledge and experience (rather than just having read a Study Guide).
All you'll need to know about NAT in a VPC is:
A NAT Gateway is a managed service that resides in a single subnet and AZ. An Elastic IP address is assigned to the NAT Gateway and all traffic coming from it to the Internet will 'appear' to be coming from that Elastic IP address.
A NAT Instance is an EC2 instance configured as a NAT. It can be assigned an Elastic IP address, or a normal (random) public IP address.
Again, I highly recommend you create both types, then configure and use them in a VPC. That way, you are actually increasing your own knowledge that would be useful for a future employer (rather than just getting a certification).
Related
For example, when I deploy two AWS EC2 instances in same VPC and same subnet, that two instances connect through internet using public IP?
I already know that traffic flows referring to route table and my current route table sends all traffic except between private IP to internet gateway.
By the way, I wonder if those "all traffic except between private IP" includes AWS public IP.
In this situation, Does AWS automatically route traffic just inside VPC or not??
Yes, all traffic between the EC2 instances within the same VPC will be routed using internal, private IP obtained from the private DNS.
You can find more in the VPC international DNS here https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-viewing
Best, Stefan
The question is a little confusing, but I think I understand. Quick rephrasing:
How does traffic route for EC2 Instances.
If traffic has to go to the internet, then it will. There are techniques where this is done on purpose, such as hairpinning, and if this is your intention, there shouldn't be any problem with doing something like this.
AWS has a 'Backend' (Sometimes called a backbone) network. All communication to EC2 Instances, or Amazon Services in General, should be routed on the AWS Backbone.
I had a little trouble locating a doc with the exact wording, but this doc covers it a bit. Please remember that the AWS Backbone is fast, so it is a good thing to use it.
https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html
I created 2 private subnets PRIVATEA and PRIVATEB in a custom VPC. These subnets are in different availability zones. Added an EC2 instance in PRIVATEA. The instance already has an ENI eth0 attached to it. Next I created an ENI in the other PRIVATEB subnet and attached it to EC2 instance in PRIVATEB subnet. The setup is successful. Basically I followed a blog tutorial for this setup. It said that secondary interface will allow traffic for another group i.e. Management.
But I am not able to relate any use case with it. Could anyone please explain when do we use such a setup ? Is this the correct question to ask in this forum here ?
Thanks
An Elastic Network Interface (ENI) is a virtual network card that connects an Amazon EC2 instance to a subnet in an Amazon VPC. In fact, ENIs are also used by Amazon RDS databases, AWS Lambda functions, Amazon Redshift databases and any other resource that connects to a VPC.
Additional ENIs can be attached to an Amazon EC2 instance. These extra ENIs can be attached to different subnets in the same Availability Zone. The operating system can then route traffic out to different ENIs.
Security Groups are actually associated with ENIs (not instances). Thus, different ENIs can have different rules about traffic that goes in/out of an instance.
An example for using multiple ENIs is to create a DMZ, which acts as a perimeter through which traffic must pass. For example:
Internet --> DMZ --> App Server
In this scenario, all traffic must pass through the DMZ, where traffic is typically inspected before being passed onto the server. This can be implemented by using multiple ENIs, where one ENI connects to a public subnet to receive traffic and another ENI connects to a private subnet to send traffic. The Network ACLs on the subnets can be configured to disallow traffic passing between the subnets, so that the only way traffic can flow from the public subnet to the private subnet is via the DMZ instance, since it is connected to both subnets.
Another use-case is software that attaches a license to a MAC address. Some software products do this because MAC addresses are (meant to be) unique across all networking devices (although some devices allow it to be changed). Thus, they register their software under the MAC address attached to a secondary ENI. If that instance needs to be replaced, the secondary ENI can be moved to another instance without the MAC address changing.
I am not an expert in networking, so I want to get a clearer image. I have an AWS running instance, and its local network is 172.31.16.0/20 with address. I know that Amazon uses 172.31.0.0/16 CIDR to manage private addresses.
If someone does a scan on 172.31.0.0/16, could he/she discover my instance?
I tried to do it with another instance of mine and it detects it, but I am not sure if it works, for instance, I don't own because of this notion of VPC that I don't really understand.
Simply no. This CIDR is for a VPC, and your VPC is different from another AWS user's VPC.
To allow another AWS user to access your VPC network, you need to share it manually, so if you do not share it, it is not possible for other users to detect your instance by a brute force query.
For public IP addresses, you definitely can be discovered.
For intern IP addresses, to the extent I know, it is a virtual network, and it is isolated from other VPCs.
Traffic for private RFC1918 addresses is not routable over the Internet. No one can hit your 172.31 address across the Internet. Not from outside AWS and not from another VPC (yours or anyone else's).
VPCs are per account and are isolated from each other. You can, however, share subnets of your VPC with another AWS account within the same AWS Organization, if you choose to. You can also peer VPCs, if you choose to.
Other instances within your VPC can reach an instance in the same VPC, of course, assuming the default routing and NACLs, as can anyone on your VPC's extended network, for example if you have a VPN connection into your VPC (but I assume that's not relevant here).
We have a Lambda function in an account and we would like to access an EC2 instance (via HTTP) in another VPC which has a public IP attached. I was wondering what would be the best way to perform this communication. I am new to Lambda and I just got to know of the VPC lambdas. Which CIDRs do I need to open on the Security Group on the EC2 instance? Can I have a specific set of public IPs being picked in the source VPC - this way I can whitelist that range in the SG?
Does VPC peering seem like an overhead for this case or the only possible solution?
It all Depends on your requirements.However, Peering those VPCs is the best way to have the traffic remaining in your trusted Private Subnets which are located in the Internal Trust Boundaries which satisfies Security best practices (Threat/Security Models and Cloud/Network Architecture).
If there is an enterprise policy with strict rules that communication shall not be routed via DMZ/Public Internet and is a must to keep things within the Trusted Boundary of Internal Routes, I don't see any other choice but to go with the VPC peering : https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/peer-with-vpc-in-another-account.html
However, if requirements are less strict and you can use Public Internet to forward your Traffic out via DMZ, it is possible to achieve this with out sacrificing too much of Security (assuming that your EC2 with public IP on other account is providing service over SSL/TLS where your lambda can communicate with it over an Encrypted Communication Channel while validating the EC2's certificate).
This could be achieved by having Lambda associated with an Internal Subnet of your VPC to talk to the EC2 of other account with Public IP. https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html
Yes, You still can have your Lambda remaining inside the Internal Subnet. But you need a NAT GATEWAY and update the Routing Table for Lambda's Internal Subnet to point to the NAT GATEWAY (which should be assigned with an EIP) i.e. it will subsequently point to your INTERNET GATEWAY. By this you will make sure that your LAMBDA which, located in your private subnet of VPC can talk with outside i.e. with the EC2 instance, located in another account's with a Public IP. Therefore you can whitelist one IP in the SecurityGroups of your EC2 in Other Account which is the EIP of your NATGATEWAY which Lambda or any other Internal Components in that subnet will use to find their way out to the Internet.
While creating NAT Gateway an Elastic IP Address is created in AWS. The AWS documentation (1) also mentions the same. Why is an Elastic IP Address required for NAT Gateway?
Simply stated, the EIP is required because that is the way the NAT Gateway feature was engineered.
It wouldn't make sense to have a dynamic address on a NAT device -- if the address changed, that would be guaranteed to break any sessions in progress... and the only way to allocate a static address is by allocating an Elastic IP address (EIP).
It's also common to have external vendors whitelist your servers (for access to their servers) by providing them with the EIP of your NAT Gateway, in which case a dynamic address from the public pool would be unacceptable.
There may also be internal, proprietary reasons related to the way EIPs function that made this requirement a necessity... but that is not documented, so such an assertion would be mere speculation. An example of this: the public pool addresses (like those auto-assigned to EC2 instances configured with a public IP address from the pool, not an EIP) might be engineered to the specific availability zone, or even a subset of a single availability zone (they do, after all, change, when an instance is stopped/started, implying that they might be dedicated to specific server bays within an AZ), while EIPs can migrate anywhere from one zone to another within a region. This strongly implies different internal topologies.
This requirement (constraint?), to me, seems insignificant: you shouldn't be charged for this EIP, and if you need to increase the maximum allowed number of EIPs in a region, you can submit a support request at no charge, describing your use case, to request a limit increase.
The EIP requirement is rather arbitrary. Having a static IP makes coding the NAT easier (it doesn't have to check the WAN Interface for upstream address changes) but NATs that support a dynamic upstream address are very common - almost every home served by a major ISP has one. Sure, there's a risk the external address might change and break the current connections, but the ISPs know this and try hard NOT to change the address. Generally it changes only when you reboot the router, and at that point all your connections are broken anyway.
On AWS there there are many similar scenarios where you don't care if your NAT gateways external address changes, especially if your VPC does not contain any public servers. I have a lot of these, and I'm trying to run them on free accounts - it annoys me that they force me to burn through my short supply of static IPs.
As others observed this is a small expense, and AWS is still way cheaper than any other way I know to get this kind of cloud power; but that EIP is not strictly required.
No insignificant at all, you are only allowed to have 5 EIPs, so having 2 or 3 apps in two availability zones will hit that threshold.
As of June 2021, the AWS NAT Gateway does not require an ElasticIP (if you choose "Private" mode):
A private NAT Gateway, or NAT Gateway with connectivity type set to private, does not require EIP and you do not need to attach an internet gateway with your VPC.
https://aws.amazon.com/about-aws/whats-new/2021/06/aws-removes-nat-gateways-dependence-on-internet-gateway-for-private-communications/
I think what the answers here are missing is that the NAT Gateway (NATG) traffic is still being routed through an Internet Gateway (IGW), which performs static (one private IP to one public IP) NAT. As the image in the question indicates, the Elastic IP (EIP) is an association. It is the IGW that is translating the NATG's private IP to its associated public EIP.
This EIP requirement is therefore consistent from an AWS implementation perspective for any resource (e.g. EC2 instance) in a public subnet accessing the internet through an IGW.
Let's say you have private network instances, how will they connect to internet? That's when NAT comes in. NAT ip is public. And private subnets can be associated with NAT. So in that way, the instance in private subnet can connect to internet using NAT. This is very useful when you have server to whitelist your ip. Just give them the NAT EIP and problem solved.