AWS Memoires #4: VPC - Virtual Private Cloud

Let's learn something about VPC today!

What is VPC?

VPC (Virtual Private Cloud) lets you provision a logically isolated section of the AWS cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways. You can also create a hardware Virtual Private Network (VPN) connection between your corporate datacenter and your VPC and leverage the AWS cloud as an extension of your corporate datacenter.


You can easily customize the network configuration of your VPC. For example, you can create a public-facing subnet for your webservers that have access to the internet, and place your backend systems such as databases or application servers in a private-facing subnet with no Internet access. You can leverage multiple layers of security, including security groups and network access control lists (NACLs), to help control access to amazon EC2 instances in each subnet.


Every VPC is created within a specific AWS account and region. It’s a regionally resilient service - it can span across multiple availability zones (AZs).


There are 2 types of VPC inside each region:

  • custom VPCs - these are the ones that you create; you can have multiple custom VPC inside one region; they are private and isolated by default (but you can change that by applying relevant configuration)
  • default VPC - each region comes with a default VPC (created by AWS); it is always configured in the same way (and this configuration is managed by AWS only).


By default, all VPCs inside specific region are isolated from each other (no traffic between them is allowed) but you can change this if required.

Default VPC

Each AWS region can have only one default VPC. Its configuration is 100% managed by AWS and cannot be altered. It can be deleted and recreated later (recreation can be done in AWS console; in the past you’d have to reach out to AWS support and ask for recreating the default VPC).


Default VPCs are always configured with 172.31.0.0/16 CIDR range and will have a single subnet in every AZ of the region.


You can add resiliency to your system by deploying resources in different subnets. Be aware though that if the whole region fails, all resources inside this region become unavailable.


Each subnet of the default VPC is x.x.x.x/20 size.

Default VPC comes with:

  • Internet Gateway (to allow communication between VPC and public internet).
  • Default Security Group which references itself as a source and allows all traffic (inbound allows for everything that comes from any resources with this default security group attached to it, outbound traffic is fully opened).
  • Default Network ACLs that do not block anything.


Default VPC’s subnets by default assign public IPv4 addresses to all resources deployed inside them.

Custom VPC

Similarly to default VPCs, custom VPCs are a regional service and can span between multiple AZs inside the region.

By default, they are isolated from each other (unless you explicitly configure them otherwise).


Custom VPCs are much more flexible compared to default ones. You have full control over subnets architecture and security rules.


VPC can use both private and public IPv4 CIDR blocks (private are used by default)


Primary IPv4 CIDR block has to be assigned when creating VPC (x.x.x.x/28 at minimum and x.x.x.x/16 at maximum).


Additionally, you can add:

  • secondary IPv4 CIDR blocks (currently there’s a soft limit of 5 of such)
  • single IPv6 /56 block


All IPv6 ranges used by AWS public by default (there’s no concept of private IPv6 address).


DNS services for VPC are handled by Route53 service.


With appropriate configuration, custom VPCs can become an extension of your corporate network.

Default/Dedicated Tenancy

When creating a custom VPC, you’ll be asked to choose the tenancy option (default vs dedicated). Dedicated tenancy means that all the resources (that you deploy into VPC which has this option enabled) are run on a hardware that is dedicated only to you (no other customers can have resources deployed on such host). This might be sometimes required when working in heavily regulated environments.


Remember that dedicated tenancy comes with additional cost.


When VPC’s tenancy attribute is set to Dedicated but you try to launch an instance with default tenancy, your preference will be ignored and it’ll be deployed into a dedicated host anyway.


Your preference will be taken into account only when VPC’s tenancy attribute is set to Default.

VPC Subnets

VPC subnets are AZ resilient. They are deployed into specific AZ and if whole AZ fails, all subnets deployed inside it fail as well.


A subnet can be deployed within one AZ but single AZ can have multiple subnets inside (or none at all).


Subnet’s IP range has to be always a subset of the whole VPC’s range.


No overlap between subnets IP ranges is allowed.


Optional IPv6 CIDR can be assigned.


By default, subnets within a single VPC can communicate with each other.


Each subnet has 5 addresses reserved by AWS (remember about this especially when designing small subnets). Let’s show this on the example of the default VPC inside Ohio region (us-east-2). VPC CIDR block would be 172.31.0.0/16 and the first subnet (deployed in us-east-2a AZ) would have 172.31.0.0/20 range.


For such case, reserved addresses would be:

  • first address of subnet range - 172.31.0.0 - Network Address
  • second address (‘Network +1’) - 172.31.0.1 - reserved for VPC Router
  • third address (‘Network +2’) - 172.31.0.2 - reserved for DNS
  • fourth address (‘Network +3’) - 172.31.0.3 - reserved for AWS future use
  • last address - 10.16.31.255 - Broadcast Address

Same rule is applied to all subnets: first 4 addresses and the last one cannot be used by the customer.

'Auto Assign Public IPv4' and 'Auto Assign IPv6' are subnet-level parameters and can be changed by the user.

DHCP Options set

DHCP (Dynamic Host Control Protocol) is a configuration object that is applied to a VPC (only one object at a time) and is a standard for passing configuration information to hosts on a TCP/IP network. Subnets inside VPC inherit this configuration. If you’d like to introduce any changes to VPC’s DHCP config object, first you’ll have to create a new DHCP config and then make VPC’s allocation pointing to that new object (you can’t just edit the currently assigned version).

VPC Routers

Each VPC has a router, which is a highly available device that takes care of the traffic routing between VPC subnets, other VPCs (if you have a VPC peering connection created), and the public internet. Traffic rules are contained within route tables; each subnet has a route table assigned (always only one at a time). One route table can be associated with multiple subnets at the same time.

VPC Router checks the destination of an IP packet and performs a search within route tables. Route table will always have at least 1 local route (for IPv4 and optionally for IPv6). Local routes match the CIDR block of VPC they’re associated with. They will always take precedence when evaluating available routes. Thanks to this, communication between VPC’s subnets is possible.

If destination IP is not matched against a local route, then remaining routes are checked. If IP matches multiple remaining routes, then the most specific one will be chosen (with higher prefix - for example 3.21.1.152/32 will be chosen instead of 3.21.1.152/20 since the latter represents range of IPs while first one is a single IP and is more specific).

Internet Gateway

An internet gateway is a horizontally scaled, redundant, and highly available (regionally resilient) VPC component that allows for communication between your VPC and the internet. One internet gateway handles all AZs inside the region.


Internet Gateway handles the traffic between VPC and public internet or AWS Public Zone.


Steps for implementing Internet Gateway inside VPC:

  • Create new Internet Gateway (or use any existing one if it is currently in a detached state)
  • Attach Internet Gateway to your VPC
  • Create route table and associate it with subnets
  • Inside a route table, create a route that matches 0.0.0.0/0 destination and set the target to Internet Gateway
  • Set subnet-level parameter ‘Auto-assign public IPv4 address’ to ‘Yes’

Above mentioned steps make all the resources deployed within such subnet publicly routable from the internet + give them outbound access to the public internet.


Important note: if you deploy an EC2 instance into a public subnet, the instance itself doesn’t know anything about its public IP. It is the internet gateway that stores the record of a relationship between such instance’s private and public IP. So whenever an EC2 instance sends a data packet that is supposed to reach some place in the public internet, this packet will go through the Internet Gateway first, where its source (currently holding private IP) will be replaced with public IP and finally it will be forwarded to the destination address.


Similar things will happen with the packets that are being sent back from the destination server. Internet Gateway again becomes an intermediary that has the link between EC2 public and private IPs; the packet's destination address is changed from public to private IP and it gets routed to EC2 instance.

NACLs (Network Access Control Lists)

NACLs stands for Network Access Control Lists. They are a set of security rules around the subnets. All subnet’s ingress and egress traffic will be evaluated against NACLs. They will not be applied though when 2 instances created inside the same subnet talk to each other (since traffic is fully contained inside the subnet in such a situation; it never leaves the subnet's boundary).


NACLs provide 2 types of rules: Inbound and Outbound. Inbound rules are applied when something outside of a subnet tries to reach a resource inside the subnet. Outbound rules are applied when a subnet's resources try to reach something outside of the subnet.


NACLs rule consist of 6 fields:

  • Rule # - integer from 1 to 32766 range. Manages the order of rules processing.
  • Type - the type of traffic you’d like to control. Choosing any predefined types will pick appropriate protocol and port range for you. It also allows for custom type that will use protocol and port range of your choice
  • Protocol - defines the protocol of the traffic (for example TCP, UDP or many others)
  • Port Range - what ports are affected by your custom rules
  • Source (for Inbound rules) and Destination (for Outbound rules) - defines the CIDR range of incoming (source) or outgoing (destination) traffic that will be affected by the rule.
  • Allow/Deny - whether a particular rule should allow or deny the traffic that matches the rule.

Rules are processed according to the ‘Rule #’ field (in an ascending order). Rules with lower numbers will be processed first. Whenever matching rule is found, the matching process stops and remaining rules (with ‘Rule #’ higher than the matched rule) are not evaluated anymore.


Each NACLs has always a catch-all rule implemented (with ‘Rule #’ equal to “*” and explicit DENY). You can’t delete or edit this one - if no other rules were matched, the traffic will be always evaluated against this rule and denied. This is valid for both inbound and outbound rules.


Default NACL associated with VPC is configured in a way that allows for any traffic inside and outside of the subnet. This is because of the fact that controlling the traffic with NACLs is difficult and may quickly become hard to maintain. When controlling any kind of traffic, you need to remember about both initiation and response parts (so you have to create 2 rules: for inbound and outbound). NACLs are considered to be stateless.

Security Groups

Security groups are sets of security rules that are applied to AWS resources’ network interfaces (unlike NACLs, which are only applied to subnets). The other major difference between NACLs and security groups is that the latter are stateful (initiation and response are treated as one thing).


To show this on example: you need to allow HTTP/HTTPS web traffic to your application deployed into EC2 instance). When defining NACLs, you’d not only have to create an inbound rule for TCP 80/443 traffic (which would take care of initiation part), but also an outbound rule (for the response part sent on ephemeral ports) should to be created on top of that. With some more advanced architecture, managing traffic rules with NACLs would quickly become difficult.


Allowing for the same kind of traffic with security groups would require creating only one rule - inbound rule opening 80 or 443 ports. Initiation and response are both handled with this single rule.


Security group’s ‘Source’ field can refer to both IP CIDR blocks and AWS resources themselves, which allows for easier maintenance and flexibility in terms of the network's security architecture.


Unlike NACLs, they do not allow for creating ‘explicit deny’; the rules you’re creating are explicit allows. SGs have hidden implicit deny - if the incoming traffic doesn’t match against any SG rule, it is denied by default. If you need to implement blacklisting of some traffic sources (explicit deny), then you’ll need to use NACLs for this. Other use case for NACLs would be products that do not work with SGs (i.e. NAT gateways). For anything else, think of security groups as a default option.

NAT Gateway

NAT Gateway makes your private subnet resources able to reach out to hosts located in the public internet (while the instances themselves remain unroutable from the public internet).


NAT Gateway performs remapping of source/destination IPs (depending on it being inbound or outbound). It’s a service managed by AWS. It requires EIP (elastic IP).


To make this work, you need to deploy NAT Gateway into a public subnet (it needs a public IPv4 address and has to have a public internet route opened). Private subnet should have a custom route table that will route non-local traffic to the NAT Gateway. This way, when a private instance sends a packet, it reaches NAT Gateway first, NAT Gateway remaps its source private IP address to NAT Gateway’s public IP address; forwards altered packed to the Internet Gateway and finally the packet reaches the destination. When the destination sends some data back, NAT gateway, upon receiving it, will forward the data to the original private resource that has started the whole thing.


NAT Gateways by default blocks all incoming traffic that has been initiated from the internet.


AWS provides redundancy for NAT Gateway (on an availability zone level). If regional resilience is required, you’ll have to deploy a separate NAT gateway in each AZ and update subnets routes table accordingly.


A NAT gateway supports 5 Gbps of bandwidth and automatically scales up to 45 Gbps. If that’s not enough for you, you can split resources among different subnets and route the traffic from each subnet to a NAT Gateway that is dedicated solely to this subnet.


NAT charges consist of two parts: hourly charge + data processing charge + the data transfer charge of underlying EC2 instance.


NAT services used to be handled by NAT instances (EC2 instances with NAT process running). This is not the desired way to handle NAT anymore.


When you could consider using NAT instances?

  • They might be cheaper that NAT Gateway (but they do not scale well)
  • NAT instance is basically an EC2 instance with special configuration, so you could use this instance for other purposes as well (in case of NAT gateway, it’s totally AWS-managed service and you don’t get any access to its operating system)

If you decide to go with NAT instance, make sure that source/destination check option is disabled (by default, EC2 instance will drop any traffic that doesn’t include its IP in either source or destination field).

VPC Flow Logs

VPC Flow Logs is a feature that enables you to capture information about the traffic going from and into network interfaces in your VPC. Logs can be pushed to either CloudWatch Logs or Amazon S3.


Flow Logs capture packets’ metadata (NOT their contents).


They can be applied on a different level of your VPC:

  • VPC level - if applied on VPC level, it captures the traffic of all interfaces inside whole VPC
  • Subnet level - only interfaces in chosen subnet are tracked
  • Network Interface level - when applied directly on a network interface, it catches the data only from this particular interface

When choosing the subnet level, be aware that you have to choose the subnet explicitly (if your VPC has 2 subnets or more and you pick just the first subnet for logs capturing, the traffic of the second subnet will not be recorded.


Flow Logs are not a real-time feature - there is a small delay required for publishing the logs to the chosen destination place.


Some of the most useful fields captured by Flow Logs include source & destination IP addresses, source & destination ports, protocol and information whether action was accepted or rejected.


Not all information is captured though - instance metadata (169.254.169.254), time sync service (169.254.169.123), DHCP, Amazon DNS Server, Amazon Windows licensing server calls are not included in the logs.


In case of NACLs logs, you will see 2 records (initiation and response). Security group will be kept as one record (they are stateful).

Egress-Only Internet Gateway

All IPv6 addresses in AWS are public by default. If you’d like to make your IPv6 instances unroutable from public internet, but keep their access to internet at the same time (for example to be able to reach update servers), then you need to implement Egress-Only Internet Gateway.


It’s highly available among all availability zones by design and scales along with the traffic.


After attaching it to VPC, you’ll need to add a route in subnets’ route tables that will move ::/0 destination to Egress-Only Internet Gateway target.

VPC Gateway Endpoints (GE)

VPC Gateway Endpoints enables your private instances to securely access public AWS services such as S3 and DynamoDB.


Gateway Endpoints are highly available across all AZs in a region by default.


Thanks to endpoint policies, you can control what kind of access is possible through gateway endpoints.


Only resources within the same region can be accessed with GE.


Gateway Endpoints with appropriate endpoint policy applied can make your S3 bucket more secure as you can allow access only through the gateway endpoint and deny everything else (which makes your bucket fully private and protects it from being ‘leaky’).


When you deploy a gateway endpoint into your VPC, AWS adds a prefix list to route tables that you select. They include addresses of S3/DynamoDB service endpoints (this list is fully managed by AWS, not the customer). Thanks to the prefix list, all traffic destined for S3 or DynamoDB will be routed to Gateway Endpoint and from there, going through a secure tunnel, will finally reach the service itself.


With such architecture in place, your instances still remain fully private (unroutable from the public internet) but are able to connect to S3 or DynamoDB services.


If you have an already-running application that is running in a public zone, uses S3 or DynamoDB and you’ like to secure it by moving into private subnet, leveraging Gateway Endpoints won’t require any changes within your app - once correctly implemented, it’ll access these services in the same way as before.

Interface Endpoints

Similarly to Gateway Endpoints, Interface Endpoints provide private access to AWS Public Services (except for S3 and DynamoDB - which are exclusively handled by Gateway Endpoints).


Interface Endpoints are added to specific subnets so they are not highly-available by default. If your architecture leverages multiple subnets and AZs, then having HA interface endpoints requires deploying them in every AZ separately (you can choose 1 subnet per each AZ).


Network Access for Interface Endpoints is controlled with Security Groups.


It’s possible to create an Endpoint Policy for granular control over the endpoint.


At the moment, Interface Endpoints support only TCP and IPv4.


Under the hood implementation of Interface Endpoints is handled by injecting required services to your private VPC using AWS PrivateLink.


Endpoints provides a new service endpoint DNS that allows for accessing public AWS services. It can be a regional DNS (one address that can be accessed from all AZs inside a region), zonal DNS (resolves into a specific address inside one availability zone). Instances in private subnets can use the newly created private endpoint hostname; instances in public subnets can choose between default DNS name or private endpoint hostname.


If taking an example of the already running application into account (see the end of Gateway Endpoint paragraph), using Interface Endpoints could require changes to the application (correcting services addresses to either Regional or Zonal ones for instances within private subnets).


To overcome this problem, PrivateDNS feature has been introduced (and is used now as a default option). When it’s enabled and your application tries to call the service with its default DSN name (for example sns.us-east-1.amazonaws.com), it will be replaced with service private endpoint for you (i.e. vpce-123-xyz.sns.us-east-1.vpce.amazonaws.com), so you don’t need to change endpoints addresses in your application’s code.

VPC Peering

VPC Peerings allows for creating a direct, encrypted network link between two VPCs (VPC are isolated from each other by default). Such link can be established inside a single region, between two regions, inside a single AWS account, between two different AWS accounts.


Optionally, resolving Public Hostnames to private IPs can be enabled.


If done inside the same region, you can reference security groups existing in both VPCs.


VPC Peering is not transitive - so when you establish a peering connection between VPC A and VPC B, and then between VPC B and VPC C, this does not mean that VPC A -> VPC C is established as well. To make it fully working between these 3 VPCs, you’ll have to add a separate peering connection between VPC A and VPC C.


In order to implement VPC peering, your VPCs cannot have overlapping CIDR blocks.


The flow for creating VPC peering connection:

  • Create VPC peering connection, choose which VPC is a requester and which one is accepter (if you’re doing this inside same AWS account, you’ll be able to accept the peering connection, otherwise it will have to be done on the accepter account)
  • Once request is accepted, update route tables in both VPCs (in VPC A route table, create a route with VPC B CIDR as a destination and peering connection as a target; repeat similar action for VPC B route table replacing the destination field with CIDR block of VPC A)
  • Make sure that the traffic you’d like to establish is allowed within NACLs and Security Groups

Exam essentials

  1. VPC - regionally resilient, logically isolated section of AWS cloud that gives you full control over its networking environment
  2. Each region has a default VPC (cannot be edited but can be deleted or created if needed).
  3. Every default VPC is configured in an exactly same way: 172.31.0.0/16 CIDR range, default 172.31.0.0/20 subnet per each AZ inside a region, default security group and default NACL
  4. Custom VPC is more flexible than the default one. It gives you full control over environment architecture and configuration
  5. Default VPC - 0 or 1 per region
  6. Custom VPC - you can create multiple VPCs inside same region
  7. Min. size for custom VPC - /28, max. Size: /16
  8. VPCs by default are isolated from each other (unless you explicitly configure them otherwise)
  9. VPCs by default uses IPv4 CIDR block, but single IPv6 can be optionally added as well
  10. DNS services for VPC are handled by Route 53 service
  11. When creating VPC, the tenancy type needs to be chosen. When picking `Default` - all deployed instances will be using a shared host underneath (shared with other AWS customers). In case of `Dedicated`, all instances will be deployed on a host that will be used only by your AWS account (it will always happen, even if you choose the default tenancy when creating such instance).
  12. There’s an additional charge associated with dedicated tenancy.
  13. Subnet is part of your VPC with CIDR block being a subset of the whole VPC’s range.
  14. Subnet is placed within a specific availability zone. You can leverage this to spread your instances among subnets in multiple AZs to achieve high-availability and failure isolation.
  15. There cannot be any IP overlapping IP ranges between VPC’s subnets.
  16. Each subnet has 5 IP addresses reserved: first four in the subnet (network address, VPC router, DNS, potential future use) and the last one (broadcast address).
  17. Only one DHCP option set can be applied to VPC at a time. If changes are required, new object has to be created and then associated with VPC. No `in-place` edit is possible.
  18. VPC Router is highly-available by design. It handles traffic routing for the VPC.
  19. Traffic rules are stored in route tables.
  20. Every subnet has to always have a route table assigned (only one at a time).
  21. Each route table has a local route (into the VPC of which it is a part of) that cannot be edited/deleted.
  22. Local route always take precedence over other routes (this makes intra-VPC communication possible).
  23. Single route table can be associated with multiple subnets.
  24. If multiple routes are matched for specific traffic, the most specific route will be always chosen (the one with the highest prefix).
  25. Internet Gateway is a horizontally scaled and highly-available VPC component which enables communication with the public internet.
  26. You need to deploy one IG per region - it’ll handle all AZs.
  27. Subnet without a route to Internet Gateway is considered private and cannot be routed from the public internet.
  28. When VPC has an IG attached and subnet has a route pointing to Internet Gateway, resources deployed into such subnet with public IPs can both reach the internet and accessed from the internet as well.
  29. Automatic assignment of public IPv4 and IPv6 addresses is a subnet-level attribute.
  30. EC2 instance does not know anything about its public IP on the OS level, it is the Internet Gateway that keeps track of IPs association.
  31. NACLs are stateless security rules around subnet boundaries.
  32. Any traffic inside the subnet (i.e. traffic between 2 instances within the same subnet) is not evaluated against them.
  33. NACLs control both inbound and outbound traffic.
  34. When creating them, you define a rule #, type, protocol, port range, source or destination, allow or deny.
  35. Rule # define an order of rules evaluation - rules with lower numbers are processed first.
  36. Each rule has a catch-all record (with rule # == ‘*’), which can be deleted, and it denies everything.
  37. Default NACLs by default pass through all traffic.
  38. Controlling the traffic with NACLs might be cumbersome (as you need to create separate rules for initiation and response parts).
  39. Security Groups are security rules that are applied to AWS resources.
  40. They are stateful (there’s no need for creating separate rules for initiation and response).
  41. Security Groups, beside IP ranges, can reference other AWS resources (even themselves) as a source.
  42. Security Groups have explicit allow and implicit deny (traffic gets denied when no rule is matched).
  43. They don’t have the ability to create an explicit deny (it has to be done with NACLs).
  44. NAT Gateway allows your private instances to reach out to the public internet (at the same time blocking all the traffic that is initiated from the public internet).
  45. Requires EIP (elastic IP) to work.
  46. There are 3 charges coming with it: hourly charge, data processing charge, EC2 data transfer charge.
  47. NAT Gateway is redundant within AZ - you deploy it into public subnet and update appropriate private subnets’ route tables to point to it.
  48. NAT instances are EC2 instances (with disabled ‘Source/Destination Check’ option) that do the similar thing as NAT gateways.
  49. When using NAT instances, you’ll have to manage scaling & redundancy yourself.
  50. Flow Logs allows for capturing traffic metadata inside VPC or a subset of it.
  51. Logs can be stored either in CloudWatch Logs or S3.
  52. Not a real-time feature - small delay exists.
  53. Logs can be captured on VPC level (all network interfaces inside VPC are tracked), subnet level (captures all network interfaces inside subnet) or network interface level (captures only the data originated from this particular interface).
  54. Things that are tracked, amongst others, are source & destination IP address and ports, protocol, action state (accepted/rejected).
  55. NACLs will generate two separate records for initiation and response, Security Groups will log it in one record.
  56. Not all information is logged (for example instance metadata calls).
  57. Egress-Only Internet Gateway is IPv6 equivalent of NAT gateway architecture - allows IPv6 instances to reach the public internet, but deny all traffic initiated from the public internet (which makes instances behind EOIG unroutable).
  58. Egress-Only Internet Gateway is highly available by design.
  59. Requires adding a rule in route table to route all ::/0 traffic to EOIG.
  60. VPC Gateway Endpoints allows private instances to access AWS public services (S3 and DynamoDB).
  61. Highly available across all AZs in the region.
  62. Allows for restricting access with setting endpoint policy.
  63. When created, a prefix list containing service addresses is automatically added to routing tables (it’s fully managed by AWS).
  64. GE doesn’t require any changes in S3/DynamoDB endpoints within your application.
  65. With GE, your private instances remain unroutable from the internet.
  66. Interface Endpoints provides similar functionality as Gateway Endpoints (private access to AWS public services).
  67. IE allows accessing public services other than S3 and DynamoDB.
  68. They’re also not high-available by design (to achieve HA, you’ll need to deploy them in each subnet).
  69. It’s also possible to implement endpoint policy for IE.
  70. IE traffic is controlled through Security Groups.
  71. When creating IE, an elastic network interface is injected into the chosen subnet. Instances can call its address to access service behind the endpoint.
  72. Since it creates a private DNS hostname, changes in your application could be required. To make it easier, PrivateDNS is now the default option when creating IE. It allows you to call the service by its default hostname, but underneath the endpoint will be replaced with private DNS address for you (since it happens automatically, you don’t need to change the code of your application to include any new service hostnames).
  73. VPC peering allows for communication between VPCs.
  74. Besides single region/account communication, it enables cross-region/cross-account link as well.
  75. One VPC is the requester, the second one is the accepter. If both VPCs are inside the same account, you’ll be able to accept peering request using a single AWS account.
  76. Once peering connection is established, you’ll need to update route tables of both VPCs as well as NACLs & security groups for allowing traffic.
  77. VPC peering is not transitive: connection between VPC A and VPC B + connection between VPC B and VPC C does not imply that you can communicate between VPC A and VPC C. It would require its own peering connection to be created.
  78. No IP range overlap is allowed for VPC peering.

See you in the next post,
Kuba