Networking and VPC in AWS - vedratna/aws-learning GitHub Wiki

VPC

  • On creation of any custom VPC; Route table, Network Access Control List (ACL) and Security Group is created by default.
  • Subnet can be associated to only one Network ACL. However one Network ACL can have multiple subnets associated with it.
  • Network ACL and Security Group can be deployed inside VPC, they can not span across multiple VPC.
  • Default Network ACL created during VPC creation allows all inbound and outbound traffic by default. But Custom Network ACL denies all inbound and outbound traffic by default.
  • Internet facing Application Load Balancer needs at least two public subnets.
  • VPC Flow Logs is a feature that enables you to capture information about all ip traffic going to and from your all network interfaces within the specified VPC.
  • VPC Flow Logs data is stored using Amazon Cloudwatch Logs. Once you create your Flow Logs, data can be retrieved and read in Amazon Cloudwatch Logs.
  • You can not create Flow Logs for the VPC that peered with your VPC until that VPC is from the same Account of your current VPC.
  • You can not tag the Flow Logs.
  • Once Flow Logs is created, you can not change it's configuration. For example you can't associate different IAM role after creation.
  • VPC Flow Logs doesn't record following ip traffics.
  1. Traffic generated when your instances sends request to Amazon DNS server. If you have your own DNS server then all request would be recorded.
  2. Traffic from Windows Instances for Windows License Activation.
  3. DHCP traffic.
  4. Traffic to and from 169.254.169.254 for instance metadata.
  5. Traffic to reserved ip addresses for default VPC router.
  • When you create a VPC using Amazon VPC, Route 53 Resolver automatically answers DNS queries for local VPC domain names for EC2 instances (ec2-192-0-2-44.compute-1.amazonaws.com) and records in private hosted zones (acme.example.com). For all other domain names, Resolver performs recursive lookups against public name servers.
  • You also can integrate DNS resolution between Resolver and DNS resolvers on your network by configuring forwarding rules. Your network can include any network that is reachable from your VPC, such as the following:
  • The VPC itself
  • Another peered VPC
  • An on-premises network that is connected to AWS with AWS Direct Connect, a VPN, or a network address translation (NAT) gateway
  • VPC sharing allows customers to share subnets with other AWS accounts within the same AWS Organization. This is a very powerful concept that allows for a number of benefits:
  • Separation of duties: centrally controlled VPC structure, routing, IP address allocation.
  • Application owners continue to own resources, accounts, and security groups.
  • VPC sharing participants can reference security group IDs of each other.
  • Efficiencies: higher density in subnets, efficient use of VPNs and AWS Direct Connect.
  • Hard limits can be avoided, for example, 50 VIFs per AWS Direct Connect connection through simplified network architecture.
  • Costs can be optimized through reuse of NAT gateways, VPC interface endpoints, and intra-Availability Zone traffic.
  • If you have a VPC peered with multiple VPCs that have overlapping or matching CIDR blocks, ensure that your route tables are configured to avoid sending response traffic from your VPC to the incorrect VPC. AWS currently does not support unicast reverse path forwarding in VPC peering connections that checks the source IP of packets and routes reply packets back to the source.
  • Visit this https://docs.aws.amazon.com/vpc/latest/peering/peering-configurations-partial-access.html#one-to-two-vpcs-instances for better understanding of below example
  • For example, VPC A is peered with VPC B and VPC C. VPC B and VPC C have matching CIDR blocks, and their subnets have matching CIDR blocks. The route table for subnet B in VPC B points to the VPC peering connection pcx-aaaabbbb to access the VPC A subnet. The VPC A route table is configured to send 10.0.0.0/16 traffic to peering connection pcx-aaaaccccc. In the scenario, traffic originating from any host within VPC B that has an IP address other than 10.0.0.77/32 (e.g. 10.0.0.66/32) could get inadvertently routed to VPC C since their IP addresses fall within the range of 10.0.0.0/16 (which is the size of the VPC B & VPC C). To solve this, we have to isolate the networks for VPC B and VPC C destinations within the VPC A routing table. Now, the IP range in VPC B will be 10.0.0.0 - 10.0.0.255 The IP range in VPC C will be 10.0.1.0 - 10.0.1.255 Since we've defined a more specific CIDR block for both target VPCs, the VPC A router would now be able to distinguish the correct traffic destination for each request.