2022-02-11 Chapter 9 - Virtual Private Cloud (VPC) Networking

service-vpc-001; A VPC can be thought of as a {{c1::virtual data center}} in the cloud i.e. a logically isolated part of the {{c1::AWS Cloud}}.

service-vpc-002; A typical three tier architecture would have web servers in a {{c1::public subnet}} (i.e. {{c1::internet accessible}}), application servers in a {{c1::private subnet}} (i.e. not {{c1::internet accessible}}) speaking to web/database tier and database servers in a {{c1::private subnet}} which can only talk to the {{c1::application layer}}.

service-vpc-003; CIDR.xyz is a useful tool for understanding {{c1::IP address ranges}}.

service-vpc-004; VPCs comprise {{c1::internet}} gateways (or {{c1::virtual private}} gateways), {{c1::route}} tables, {{c1::network access control}} lists, s{{c1::ubnets}} and s{{c1::ecurity}} g{{c1::roups}}.

service-vpc-005; When you provision an AWS account it comes with a default {{c1::VPC}}. All subnets in the default {{c1::VPC}} are {{c1::public}} and each EC2 instance in the VPC has a {{c1::public}} and {{c1::private}} {{c1::IP address}}.

service-vpc-006; One subnet in a VPC is always in {{c1::one availability zone}}. A subnet cannot {{c1::span multiple availability zones}}.

service-vpc-007; AWS reserves {{c1::five}} I.P. addresses (the first {{c1::four}}, and the {{c1::last one}}) per subnet CIDR block for internal use.

service-vpc-008; You can only have one {{c1::Internet Gateway}} per VPC.

service-vpc-009; A network address translation (NAT) gateway is a means of enabling instances in a {{c1::private}} subnet to connect to {{c1::the internet}} or other {{c1::AWS services}} while preventing {{c1::the internet}} from initiating a connection with those instances.

service-vpc-010; NAT Gateways are redundant inside the {{c1::Availability Zone}}.

service-vpc-011; NAT Gateways start at {{c1::5}} Gbps and scale to {{c1::45}} Gbps.

service-vpc-012; Users don't have to {{c1::patch}} NAT Gateways as AWS manages this.

service-vpc-013; NAT Gateways are not associated with {{c1::security groups}}.

service-vpc-014; NAT Gateways are automatically assigned a {{c1::public IP address}}.

service-vpc-015; Security groups are {{c1::stateful}} i.e. if you send a request from an instance, the response traffic for the request is {{c1::allowed to flow in}} regardless of inbound rules. Conversely, responses to {{c1::allowed}} inbound traffic are {{c1::allowed to flow}} out regardless of outbound rules.

service-vpc-016; A network access control list (ACL) is an optional layer of security for your VPC that acts as a {{c1::firewall}} for controlling {{c1::traffic}} in and out of one or more {{c1::subnets}}.

service-vpc-017; A VPC automatically comes with a default network ACL which {{c1::allows all outbound and inbound traffic}} by default.

service-vpc-018; Users can create custom network ACLs. By default, each custom network ACL {{c1::denies all inbound and outbound traffic}} until you add {{c1::rules}}.

service-vpc-019; Each subnet in a VPC must be associated with a {{c1::network ACL}}. If a user doesn't create an explicit association, then the subnet is automatically associated with {{c1::the default network ACL}}.

service-vpc-020; Users can block {{c1::specific IP addresses}} using network ACLs (not {{c1::security groups}}).

service-vpc-021; You can associate a network ACL with multiple {{c1::subnets}}, however a {{c1::subnet}} can be associated with {{c1::only one network ACL}} at a time. When you associate a network ACL with a subnet, the previous association is {{c1::removed}}.

service-vpc-022; Network ACLs contain a numbered list of rules that are evaluated {{c1::in order}}, starting with {{c1::the lowest numbered rule}}. Lower numbered rules {{c1::override conflicting higher numbered rules}}.

service-vpc-023; Network ACLs have separate {{c1::inbound}} and {{c1::outbound}} rules and each rule can either {{c1::allow}} or {{c1::deny}} traffic.

service-vpc-024; Network ACLs are {{c1::stateless}} i.e. responses to allowed inbound traffic {{c1::are subject to}} the rules for outbound traffic (and vice versa).

service-vpc-025; A VPC endpoint enables you to {{c1::privately}} connect your VPC to supported {{c1::AWS services}} and VPC endpoint services powered by {{c1::PrivateLink}} without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.

service-vpc-026; Instances in a VPC do not require {{c1::public I.P. addresses}} to communicate with services via VPC endpoints, as traffic between the VPC and the service does not {{c1::leave the Amazon network}}.

service-vpc-027; VPC endpoints are virtual devices which allow communication between {{c1::instances in a VPC}} and {{c1::services}} without imposing availability risks or bandwidth constraints.

service-vpc-028; There are two types of VPC endpoint: 1) an {{c1::interface endpoint}} is an elastic network interface with a private I.P. address that services as an entry point for traffic headed to a supported service and supports a large number of AWS services and 2) a {{c1::gateway endpoint}} is a virtual device you provision, similar to a NAT gateway, and supports connection to {{c1::S3}} and {{c1::DynamoDB}}.

service-vpc-029; VPC peering is a way of {{c1::connecting one VPC to another}} using private IP addresses. By doing this, instances behave as if they are on the same {{c1::private network}}.

service-vpc-030; It's possible to peer VPCs across {{c1::regions}} and {{c1::AWS accounts}}.

service-vpc-031; VPC peering is arranged in a {{c1::star or hub-and-spoke}} configuration e.g. 1 central VPC with 4 others.

service-vpc-032; Transitive (i.e. indirect) VPC peering is {{c1::unsupported}}.

service-vpc-033; Peered VPCs cannot have {{c1::overlapping}} CIDR address ranges.

service-vpc-034; The best way to expose a service VPC to tens, hundreds or thousands of customer VPCs is {{c1::AWS PrivateLink}}.

service-vpc-035; AWS PrivateLink doesn't require V{{c1::PC}} p{{c1::eering}}, r{{c1::oute}} t{{c1::ables}}, N{{c1::AT}} g{{c1::ateways}} or i{{c1::nternet}} g{{c1::ateways}}.

service-vpc-036; AWS PrivateLink requires a {{c1::Network Load Balancer}} on the service VPC and an {{c1::Elastic Network Interface (ENI)}} on the customer VPC.

service-vpc-037; If you have multiple sites, each with its own VPN connection, you can use {{c1::AWS VPN CloudHub}} to connect those sites together. It's similar to VPC peering in that it works on a {{c1::hub-and-spoke}} model.

service-vpc-038; While AWS VPN CloudHub operates over the public internet, all traffic between the customer gateway and the AWS VPN CloudHub is {{c1::encrypted}}.

service-vpc-039; {{c1::AWS Direct Connect}} is a cloud service solution that makes it easy to establish a dedicated network connection from your premises to AWS.

service-vpc-040; AWS Direct Connect allows {{c1::private}} connectivity between AWS and your premises.

service-vpc-041; There are two types of Direct Connect: 1) {{c1::Dedicated Connection}}, a physical ethernet connection associated with a single customer or 2) {{c1::Hosted Connection}}, a physical ethernet connection that an AWS Direct Connect Partner provisions on behalf of a customer.

service-vpc-042; AWS Direct Connect is useful for {{c1::high-throughput}} workloads.

service-vpc-043; {{c1::AWS Transit Gateway}} connects VPCs and on-premises networks through a central hub. This simplifies your network and puts an end to complex {{c1::peering}} relationships. It acts as a cloud router in that each new connection is {{c1::only made once}}.

service-vpc-044; AWS Transit Gateway works with {{c1::Direct Connect}} as well as {{c1::VPN}} Connections.

service-vpc-045; AWS Transit Gateway supports {{c1::IP multicast}}, which is not supported by any other AWS service.

service-vpc-046; If you have resources in multiple AZs and they share a NAT gateway, in the event that the NAT gateways AZ is down, resources in the other AZs {{c1::lose internet access}}. To create an AZ-independent architecture, create a NAT gateway in {{c1::each AZ}} and configure routing to ensure that resources use the NAT gateway {{c1::in the same AZ}}.