A virtual private cloud (VPC) is a virtual network dedicated to the AWS account. It is logically isolated from other virtual networks in the AWS cloud. 

VPC needs a set of IP addresses in the form of a Classless Inter-Domain Routing (CIDR) block for e.g, 10.0.0.0/16, which allows 2^16 (65536) IP address to be available  

Allowed CIDR block size is between /28 netmask (minimum with 2^4 – 16 available IP address) and /16 netmask (maximum with 2^16 – 65536 IP address)

CIDR block from private (non-publicly routable) IP address can be assigned 10.0.0.0 – 10.255.255.255 (10/8 prefix), 172.16.0.0 – 172.31.255.255 (172.16/12 prefix) , 192.168.0.0 – 192.168.255.255 (192.168/16 prefix)

It’s possible to specify a range of publicly routable IP addresses; however, direct access to the Internet is not currently supported from publicly routable CIDR blocks in a VPC.

 You can now resize VPC 

We can have 5 VPCs per Region.

Each VPC is separate from any other VPC created with the same CIDR block even if it resides within the same AWS account 

VPC allows VPC Peering connections with other VPC within the same or different AWS accounts 

Connection between your VPC and corporate or home network can be established, however the CIDR blocks should be not be overlapping.

VPC allows you to set tenancy option for the Instances launched in it. By default, the tenancy option is shared. If dedicated option selected, all the instances within it are launched on a dedicated hardware overriding the individual instance tenancy setting.

Deletion of the VPC is possible only after terminating all instances within the VPC, and deleting all the components with the VPC for e.g. subnets, security groups, network ACLs, route tables, Internet gateways, VPC peering connections, and DHCP options.

Private IP addresses are not reachable over the Internet. 

All instances are assigned a private IP address, within the IP address range of the subnet.

Primary IP address is associated with the network interface for its lifetime, even when the instance is stopped and restarted and is released only when the instance is terminated .

Additional Private IP addresses, known as secondary private IP address, can be assigned to the instances and these can be reassigned from one network interface to another.

VPC supports IPv4 and IPv6 addressing, and has different CIDR block size limits for each 

IPv6 CIDR block can be optionally associated with the VPC.

VPC IPv4 CIDR block cannot be modified once created i.e. cannot increase or decrease the size of an existing CIDR block. 

However, secondary CIDR blocks can be associated with the VPC to extend the VPC.

VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. 

Flow log data is stored using Amazon CloudWatch Logs. After you've created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs.

If you delete the default VPC, the only way to get it back is to submit a support ticket 

/16 is the largest CIDR block available when provisioning an IP space for a VPC 

169.254.169.253 - Amazon DNS 

Private IP addresses are not reachable over the Internet. 

All instances are assigned a private IP address, within the IP address range of the subnet.

Primary IP address is associated with the network interface for its lifetime, even when the instance is stopped and restarted and is released only when the instance is terminated .

Additional Private IP addresses, known as secondary private IP address, can be assigned to the instances and these can be reassigned from one network interface to another.

Public IP addresses are reachable over the Internet, and can be used for communication between instances and the Internet, or with other AWS services that have public endpoints 

Public IP address assignment to the Instance depends if the Public IP Addressing is enabled for the Subnet. 

Public IP address can also be assigned to the Instance by enabling the Public IP addressing during the creation of the instance which overrides the subnet’s public IP addressing attribute.

Public IP address is assigned from AWS pool of IP addresses and it is not associated with the AWS account and hence is released when the instance is stopped and restarted or terminated. 

Elastic IP addresses are static, persistent public IP addresses which can be associated and disassociated with the instance, as required.

For an instance, without a public IP address, to communicate to internet it must be assigned an Elastic IP address.

A Network Interface can be assigned either a Public IP or an Elastic IP. 

Elastic IP address can help mask the failure of an instance or software by rapidly remapping the address to another instance in your account. 

Elastic IP address is associated with the AWS account, not to a particular instance.

If you assign an instance, already having an Public IP, an Elastic IP, the public IP is released. 

Elastic IP addresses can be moved from one instance to another, which can be within the same or different VPC within the same account.

Elastic IP are charged for non usage i.e. if it is not associated or associated with a stopped instance or an unattached Network Interface.

When the Elastic IP address is dissociated the public IP address is assigned back to the instance. However, if secondary network interface is attached to the instance, public IP address is not automatically assigned.

Elastic IP addresses are not charged when associated with a running instance.

All AWS accounts are limited to 5 EIPs (soft limit), because public (IPv4) Internet addresses are a scarce public resource.

They are virtual network interfaces that can be attached to the instances running in an VPC only. 

Each Instance is attached with default elastic network interface (Primary Network Interface eth0) and cannot be detached from the instance 

ENI consists of the following

1. • A primary private IP address.

   • One or more secondary private IP addresses

   • One Elastic IP address per private IP address.

   • One public IP address, which can be auto-assigned to the elastic network interface for eth0 when an instance is launched.

   • One or more security groups.

   • A MAC address.

   • A source/destination check flag.

   • A description.

ENI can be created without being attached to an instance.

ENI’s attributes follow the ENI as it is attached or detached from an instance and reattached to another instance. When an ENI is moved from one instance to another, network traffic is redirected to the new instance. 

Multiple ENIs can be attached to an instance and is useful for use cases:  Create a management network, use network and security appliances in your VPC, create dual-homed instances with workloads/roles on distinct subnets, create a low-budget, high-availability solution.

Primary (eth0) interface can’t be detached.

 Secondary (ethN) ENI can be detached when the instance is running or stopped. 

ENI in one subnet can be attached to an instance in another subnet, but the same AZ and same VPC.

Launching an Amazon Linux or Microsoft Windows Server instance with multiple network interfaces automatically configures interfaces, private IP addresses, and route tables on the operating system of the instance.  

A A warm or hot attach of an additional ENI may require bringing up the second interface manually, configure the private IP address, and modify the route table accordingly.  

Instances running Amazon Linux or Microsoft Windows Server automatically recognize the warm or hot attach and configure themselves. 

Attaching another ENI to an instance is not a method to increase or double the network bandwidth to or from the dual-homed instance. 

We can use our secondary ENIs to preserve a fix  MAC address. 

Can be useful to assign multiple IP addresses to an instance in your VPC to do the following. 

1. • A Host multiple websites on a single server by using multiple SSL certificates on a single server and associating each certificate with a specific IP address.

   • Operate network appliances, such as firewalls or load balancers, have multiple IP addresses for each network interface.

   • Redirect internal traffic to a standby instance if your instance fails by reassigning the secondary IP address to the standby instance.

Route table defines rules, termed as routes, which determine where network traffic from the subnet would be routed.

Each VPC has a implicit router to route network traffic.

We can have 200 Route Tables per VPC.

Each VPC has a Main Route table, and can have multiple custom route tables created.

Each Subnet within a VPC must be associated with a single route table at a time, while a route table can have multiple subnets associated with it.

Each Subnet is associated with a route table which controls the traffic. 

Subnet, if not explicitly associated to a route table, is implicitly associated with the main route table. 

Every route table contains a local route that enables communication within a VPC which cannot be modified or deleted.

Route priority is decided by matching the most specific route in the route table that matches the traffic.

Route tables needs to be updated to defined routes for Internet gateways, Virtual Private gateways, VPC Peering, VPC Endpoints, NAT Device etc. 

Each route has a destination and target field. Destination field specifies thex with its destination address (IP or CIDR range). Target field specifies where such a request should be routed. 

An Internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in the VPC and the Internet. 

Provide a target in the VPC route tables for Internet-routable traffic.

To perform network address translation (NAT) for instances that have been NOT been assigned public IP addresses.  

Enabling Internet access to an Instance requires attaching Internet gateway to the VPC,  have route tables associated with the route pointing to the Internet gateway, a Public IP or Elastic IP address assigned, Security groups and NACLs associated with the Instance should allow relevant traffic.

NAT device enables instances in a private subnet to connect to the Internet or other AWS services, but prevents the Internet from initiating connections with the instances. 

NAT devices do not support IPv6 traffic, use an egress-only Internet gateway instead.  

It's charged by hour.

NAT device performs the function of both address translation and port address translation (PAT).

 Prevents instances to be directly exposed to the Internet and having to be launched in Public subnet and assignment of the Elastic IP address to all, which are limited. 

NAT device routes the traffic, from the private subnet to the Internet, by replacing the source IP address with its address and for the response traffic it translates the address back to the instances’ private IP addresses. 

Configuration in 2 ways NAT Instance  & NAT Gateway, managed service by AWS.

NAT gateway is a AWS managed NAT service that provides better availability, higher bandwidth, and requires less administrative effort. 

A NAT gateway supports bursts of up to 10 Gbps of bandwidth.

For over 10 Gbps bursts requirement, the workload can be distributed by splitting the resources into multiple subnets, and creating a NAT gateway in each subnet .

NAT gateway is associated with One Elastic IP address which cannot be disassociated after it’s creation. 

Each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that zone. 

Protocols: TCP, UDP, and ICMP. 

NAT gateway cannot be associated a security group. Security can be configured for the instances in the private subnets to control the traffic.

NACL applies to the NAT gateway’s traffic, which uses ports 1024-65535.

NAT gateway receives an elastic network interface with a private IP address from the IP address range of the subnet, the ENI Attributes cannot be modified.

NAT gateway cannot send traffic over VPC endpoints, VPN connections, AWS Direct Connect, or VPC peering connections. Private subnet’s route table should be modified to route the traffic directly to these devices. 

The recommendation is to use NAT gateway.

When a new NAT gateway has been created, remember to update your route table 

 No need to disable Source/Destination checks 

NAT instance can be created by using Amazon Linux AMIs configured to route traffic to Internet. 

They do not provide the same availability and bandwidth as the NAT Gateway, and need to configured as per the application needs. 

NAT instances must have security groups associated with Inbound traffic enabled from private subnets and Outbound traffic enabled to the Internet.

NAT instances should have the Source Destination Check attribute disabled.

High Availability NAT Instance;  Create One NAT instance per Availability Zone, Configure all Private subnet route tables to the same zone NAT instance, Use Auto Scaling for NAT availability with min a max with 1. Auto Scaling monitor health and availability of the NAT instance. Bootstrap scripts with the NAT instance to update the Route tables programmatically. Keep a close watch on the Network Metrics and scale vertically the NAT instance type to the one with high network performance.

 For high availability, launch NAT instances in  multiple Available Zones and make it as part of an Auto Scaling Group.

SSH agent forwarding (ssh-agent) on the client; This allows an administrator to connect from the bastion to another instance without storing the private key on the bastion. 

If you are experiencing any sort of bottleneck issues with a NAT instance, then increase the instance size.

NAT instances are always behind a security group 

 Availability

1. (Gateway):  Highly available. NAT gateways in each Availability Zone are implemented with redundancy. Create a NAT gateway in each Availability Zone to ensure zone-independent architecture.

2. (Instance): Use a script to manage failover between instances.

Bandwidth

1. (Gateway):  Can scale up to 45 Gbps.

2. (Instance): Depends on the bandwidth of the instance type.

Maintenance

1. (Gateway):  Managed by AWS. You do not need to perform any maintenance.

2. (Instance):  Managed by you, for example, by installing software updates or operating system patches on the instance.

Performance

1. (Gateway):  Software is optimized for handling NAT traffic.

2. (Instance):  A generic Amazon Linux AMI that's configured to perform NAT.

Cost

1. (Gateway):  Charged depending on the number of NAT gateways you use, duration of usage, and amount of data that you send through the NAT gateways.

2. (Instance):  Charged depending on the number of NAT instances that you use, duration of usage, and instance type and size.

Type and size

1. (Gateway):  Uniform offering; you don’t need to decide on the type or size.

2. (Instance):  Choose a suitable instance type and size, according to your predicted workload.

Public IP addresses

1. (Gateway):  Choose the Elastic IP address to associate with a NAT gateway at creation.

2. (Instance):  Use an Elastic IP address or a public IP address with a NAT instance. You can change the public IP address at any time by associating a new Elastic IP address with the instance.

Private IP addresses

1. (Gateway):  Automatically selected from the subnet's IP address range when you create the gateway.

2. (Instance):  Assign a specific private IP address from the subnet's IP address range when you launch the instance.

Security groups

1. (Gateway):  Cannot be associated with a NAT gateway. You can associate security groups with your resources behind the NAT gateway to control inbound and outbound traffic.

2. (Instance):  Associate with your NAT instance and the resources behind your NAT instance to control inbound and outbound traffic.

Network ACLs

1. (Gateway):  Use a network ACL to control the traffic to and from the subnet in which your NAT gateway resides.

2. (Instance):  Use a network ACL to control the traffic to and from the subnet in which your NAT instance resides.

Flow logs

1. (Gateway):  Use flow logs to capture the traffic.

2. (Instance):  Use flow logs to capture the traffic.

Port forwarding

1. (Gateway):  Not supported.

2. (Instance):  Manually customize the configuration to support port forwarding.

Bastion server

1. (Gateway):  Not supported.

2. (Instance):  Use as a bastion server.

Traffic metrics

1. (Gateway):  View CloudWatch metrics for the NAT gateway.

2. (Instance):  View CloudWatch metrics for the instance.

Timeout behavior

1. (Gateway):  When a connection times out, a NAT gateway returns an RST packet to any resources behind the NAT gateway that attempt to continue the connection (it does not send a FIN packet).

2. (Instance):  When a connection times out, a NAT instance sends a FIN packet to resources behind the NAT instance to close the connection.

IP fragmentation

1. (Gateway):  Supports forwarding of IP fragmented packets for the UDP protocol. Does not support fragmentation for the TCP and ICMP protocols. Fragmented packets for these protocols will get dropped.

2. (Instance):  Supports reassembly of IP fragmented packets for the UDP, TCP, and ICMP protocols.

Egress-only Internet gateway works as a NAT gateway, but for IPv6 traffic.

To enable outbound-only Internet communication over IPv4, use a NAT gateway instead. 

Subnet spans a single Availability Zone.

We can have 200 Subnets per VPC.

Subnet can be configured with an Internet gateway to enable communication over the Internet, or virtual private gateway (VPN) connection to enable communication with your corporate network. 

Subnet can be Public or Private 

Instances within the Public Subnet should be assigned a Public IP or Elastic IP address to be able to communicate with the Internet.

Subnets can be configured to Enable assignment of the Public IP address to all the Instances launched within the Subnet by default.

CIDR block assigned to the Subnet can be the same as the VPC CIDR, in this case you can launch only one subnet within your VPC.

CIDR block assigned to the Subnet can be a subset of the VPC CIDR, which allows you to launch multiple subnets within the VPC.

CIDR block assigned to the subnet should not be overlapping.

AWS reserves 5 IPs address (first 4 and last 1 IP address) in each Subnet which are not available for use. Example: with a CIDR block 10.0.0.0/24 the following five IPs are reserved:

1.  10.0.0.0: Network address, 10.0.0.1: Reserved by AWS for the VPC router 

2. 10.0.0.2: Reserved by AWS for mapping to Amazon-provided DNS

3. 10.0.0.3: Reserved by AWS for future use

4. 10.0.0.255: Network broadcast address. AWS does not support broadcast in a VPC, therefore the address is reserved

Allowed block size is between a /28 netmask (minimum with 2^4 – 16 available IP address) and /16 netmask (maximum with 2^16 – 65536 IP address) .

CIDR block must not overlap with any existing CIDR block that’s associated with the VPC.

CIDR block must not be the same or larger than the CIDR range of a route in any of the VPC route tables for e.g. for a CIDR block 10.0.0.0/24, can only associate smaller CIDR blocks like 10.0.0.0/25 

Security groups – Act as a firewall for associated EC2 instances, controlling both inbound and outbound traffic at the instance level.

Network access control lists (ACLs) – Act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level .

Flow logs – Capture information about the IP traffic going to and from network interfaces in your VPC, and can help in monitoring the traffic or troubleshooting any connectivity issues. Data is stored using Amazon CloudWatch Logs. Can be created for the entire VPC, subnets or each network interface.  Use cases: 

1. Troubleshoot connectivity issues

2. Test network access rules

3. Monitor traffic

4. Detect and investigate security incidents

To manage IP v6 in our actual configuration with IP v4 when we have NAT gateways, public network and private network then:

1. Associate an Amazon-provided IPv6 CIDR block with existing VPC and subnets. In the VPC and subnets console, choose “Add IPv6 CIDR”.

2. For public subnets, create a route that routes all IPv6 traffic from the subnet to the internet gateway. For private subnets, create a route that routes all Internet-bound IPv6 traffic to an egress-only internet gateway.

3. Assign IPv6 addresses to EC2 instances from the IPv6 address range that is allocated to the subnet. 

4. Update Your Security Group Rules 

5. Change Your Instance Type 

Capture information about the IP traffic going to and from network interfaces in your VPC, and can help in monitoring the traffic or troubleshooting any connectivity issues. 

Flow log data can be published to Amazon CloudWatch Logs or Amazon S3. After you've created a flow log, you can retrieve and view its data in the chosen destination.

You can create a flow log for a VPC, a subnet, or a network interface. If you create a flow log for a subnet or VPC, each network interface in that subnet or VPC is monitored. 

Flow logs do not capture real-time log streams for network interfaces. 

You can create flow logs for network interfaces that are created by other AWS services, such as: Elastic Load Balancing, Amazon RDS, Amazon ElastiCache, Amazon Redshift, Amazon WorkSpaces, NAT gateways, Transit gateways.

Flow log data for a monitored network interface is recorded as flow log records.

The aggregation interval is the period of time during which a particular flow is captured and aggregated into a flow log record. By default, the maximum aggregation interval is 10 minutes.

To create a flow log, you specify: 

1. The resource for which to create the flow log

2. The type of traffic to capture (accepted traffic, rejected traffic, or all traffic)

3. The destinations to which you want to publish the flow log data.

After you've created a flow log, it can take several minutes to begin collecting and publishing data to the chosen destinations. 

After you've created a flow log, it can take several minutes to begin collecting and publishing data to the chosen destinations. 

Flow logs can help you:

1. Diagnosing overly restrictive security group rules

2. Monitoring the traffic that is reaching your instance

3. Determining the direction of the traffic to and from the network interfaces

Act as a firewall for associated Amazon instances, controlling both inbound and outbound traffic at the instance level.

Acts at an Instance level and not at the subnet level. 

An instance can be assigned 5 security groups with each security group having 50 rules.

We can have 500 Security Groups per VPC.

Generally will use this with white listing traffic.

Security groups allows you to add or remove rules (authorizing or revoking access) for both Inbound (ingress) and Outbound (egress) traffic to the instance. 

Default Security group allows no external inbound traffic but allows inbound traffic from instances with the same security group.

Default Security group allows all outbound traffic.

New Security groups start with only an outbound rule that allows all traffic to leave the instances.

Security groups can specify only Allow rules, but not deny rules.

Security groups can grant access to a specific CIDR range, or to another security group in the VPC or in a peer VPC.

Security groups are evaluated as a Whole or Cumulative bunch of rules with the most permissive rule taking precedence.

We can have 50 inblound and outbound rules per VPC.

Security groups are Stateful – responses to allowed inbound traffic are allowed to flow outbound regardless of outbound rules, and vice versa. 

Security groups are associated with ENI (network interfaces). 

Security groups associated with the instance can be changed, which changes the security groups associated with the primary network interface (eth0) and the changes would be applicable immediately to all the instances associated with the Security group.

Connection Tracking is to track information about traffic to and from the instance.

Responses to inbound traffic are allowed to flow out of the instance regardless of outbound security group rules, and vice versa. 

Connection Tracking is maintained only if there is no explicit Outbound rule for an Inbound request (and vice versa).

Any existing flow of traffic, that is tracked, is not interrupted even if the rules for the security groups are changed. 

Connection Tracking can be controlled by modifying the security group’s outbound rules to permit only certain types of outbound traffic. Alternatively, Network ACLs (NACLs) can be used for the subnet, network ACLs are stateless and therefore do not automatically allow response traffic. 

Act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level of one or more subnets. 

Is applicable to all the instances in that Subnet.

Generally will use this with black listing traffic.

Network ACL has separate inbound and outbound rules, and each rule can either allow or deny traffic .

Default ACL allows all inbound and outbound traffic.

Newly created ACL denies all inbound and outbound traffic.

A Subnet can be assigned only 1 NACLs and if not associated explicitly would be associated implicitly with the default NACL.

Network ACL is a numbered list of rules that are evaluated in order starting with the lowest numbered rule, to determine whether traffic is allowed in or out of any subnet associated with the network ACL.

Network ACLs are Stateless; responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa).

The highest rule number is 32766

Start with rules starting at 100 so you can insert rules if needed

VPC sharing allows multiple AWS accounts to create their application resources, such as EC2 instances, RDS databases, Redshift clusters, and AWS Lambda functions, into shared, centrally-managed VPCs. 

The account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization from AWS Organizations. 

After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. 

Participants cannot view, modify, or delete resources that belong to other participants or the VPC owner. 

VPC endpoint enables creation of a private connection between VPC to supported AWS services and VPC endpoint services powered by PrivateLink using its private IP address.

VPC Endpoint does not require a public IP address, access over the Internet, NAT device, a VPN connection or AWS Direct Connect.

Traffic between VPC and AWS service does not leave the Amazon network.

Endpoints are virtual devices, that are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in the VPC and AWS services without imposing availability risks or bandwidth constraints on your network traffic .

Do not support cross-region requests.

Two types of Endpoints VPC Interface Endpoints & VPC Gateway Endpoints.

VPC Endpoint policy is an IAM resource policy attached to an endpoint for controlling access from the endpoint to the specified service.

Endpoint policy, by default, allows full access to the service. 

Endpoint policy does not override or replace IAM user policies or service-specific policies (such as S3 bucket policies). 

A VPC Gateway Endpoint is a gateway that is a target for a specified route in the route table, used for traffic destined to a supported AWS service (DinamoDB, S3). 

A route is automatically added to the Route table with a destination that specifies the prefix list of service and the target with the endpoint id. for e.g. A rule with destination pl-68a54001 (com.amazonaws.us-west-2.s3) and a target with this endpoints’ ID (e.g. vpce-12345678) will be added to the route tables.

Security groups needs to be modified to allow Outbound traffic from the VPC to the service that's specified in the endpoint. Use the service prefix list ID for e.g. com.amazonaws.us-east-1.s3  as the destination in the outbound rule 

Multiple endpoints can be created in a single VPC.

Multiple endpoints can be created for a single service, and different route tables.

Multiple endpoints to the same service CANNOT be specified in a single route table.

Endpoint cannot be created between a VPC and an AWS service in a different region.  

Endpoints support IPv4 traffic only. 

Cannot be transferred from one VPC to another, or from one service to another.

Endpoint connections cannot be extended out of a VPC i.e. resources across the VPN connection, VPC peering connection, AWS Direct Connect connection cannot use the endpoint.

VPC Interface endpoint enables connectivity to services powered by AWS PrivateLink. 

An elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported service. 

Services include some AWS services for e.g. CloudTrail, CloudWatch etc., services hosted by other AWS customers and partners in their own VPCs (referred to as endpoint services), and supported AWS Marketplace partner services. 

For each interface endpoint, only one subnet per Availability Zone can be selected. 

Each interface endpoint can support a bandwidth of up to 10 Gbps per Availability Zone by default. Additional capacity may be added automatically based on your usage. 

Network ACL for the subnet can restrict traffic, and needs to be configured properly .

Interface Endpoint supports TCP traffic only. 

Endpoints are supported within the same region only.  

Endpoints support IPv4 traffic only. 

Endpoints cannot be transferred from one VPC to another, or from one service to another. 

Examples:

Gateway endpoint

Interface endpoint

A VPC peering connection is a networking connection between two VPCs that enables routing of traffic between them using private IP addresses. 

Instances in either VPC can communicate with each other as if they are within the same network.

VPC peering connection can be established between your own VPCs, or with a VPC in another AWS account in a different region.  

AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. 

VPC peering connection cannot be created between VPCs that have matching or overlapping CIDR blocks. 

VPC peering connection can be created between VPCs in different regions.

VPC peering connection are limited on the number active and pending VPC peering connections that you can have per VPC.

VPC peering does not support transitive peering relationships.  

VPC peering does not support Edge to Edge Routing Through a Gateway or Private Connection.

Only one VPC peering connection can be established between the same two VPCs at the same time.

Maximum Transmission Unit (MTU) across a VPC peering connection is 1500 bytes.

A placement group can span peered VPCs that are in the same region; however, you do not get full-bisection bandwidth between instances in peered VPCs.

Any tags created for the VPC peering connection are only applied in the account or region in which they were created.

Unicast reverse path forwarding in VPC peering connections is not supported.

Instance’s Public DNS can now be resolved to its private IP address across peered VPCs.

VPC Peering can be applied to create shared services or perform authentication with an on-premises instance.

This would help creating a single point of contact, as well limiting the VPN connections to a single account or VPC.

VPC VPN connections provide secure IPSec connections from on-premise computers/services to AWS.  We have the next types: AWS hardware VPN, AWS Direct Connect, AWS VPN CloudHub y Software VPN.

Non-overlapping IP address pool should be configured at each of the regional offices. 

BGP ASN should be unique at offices. 

For each VPN Tunnel, AWS provides two different VPN endpoints. ECMP (Equal Cost Multi-Path) can be used to carry traffic on both VPN endpoints, increasing performance & faster data transfer. 

To set up a Site-to-Site VPN connection, complete the following steps:

Prerequisites: steps:

IPSec (IP Security) is a protocol for in-transit data protection between hosts. 

Configuration of site-to-site IPSec between multiple hosts can be an error-prone and intensive task. If you need to protect N EC2 instances, then you need a full mesh of N*(N-1)IPSec tunnels. 

IPSec operates at the network layer of the OSI model. Hence, it only protects the data that is in transit ( encryption of data in transit ONLY) over the internet, and  both the source and the destination (client and server) may not be IPSec aware. 

With IPsec tunnel we have:

Connectivity can be established by creating an IPSec, hardware VPN connection between the VPC and the remote network.

On the AWS side of the VPN connection, a Virtual Private Gateway (VGW) provides two VPN endpoints for automatic failover.

It's charged by hour.

On customer side a customer gateway (CGW) needs to be configured, which is the physical device or software application on the remote side of the VPN connection.

Each VPN has two tunnels associated with it that can be configured on the customer router, as is not single point of failure. 

Multiple VPN connections to a single VPC can be created, and a second CGW can be configured to create a redundant connection to the same external location or to create VPN connections to multiple geographic locations. 

Virtual Private Gateway – VGW; A virtual private gateway is the VPN concentrator on the AWS side of the VPN connection.

Customer Gateway – CGW; A customer gateway is a physical device or software application on customer side of the VPN connection. VGW is not the initiator; CGW must initiate the tunnels. If the VPN connection experiences a period of idle time, usually 10  seconds, depending on the configuration, the tunnel may go down.  

For a VPN connection, the route table for the subnets should be updated with the type of routing (static of dynamic) that you plan to use. 

Static Routing; If your device does not support BGP.

Dynamic Routing; If the VPN device supports Border Gateway Protocol (BGP), specify dynamic routing with the VPN connection.

Only IP prefixes known to the virtual private gateway, either through BGP advertisement or static route entry, can receive traffic from your VPC. 

By using redundant VPN connections and CGWs, maintenance on one of the customer gateways can be performed while traffic continues to flow over the second customer gateway’s VPN connection. Each VPN connection has two tunnels to help ensure connectivity in case one of the VPN connections becomes unavailable, with each tunnel using a unique virtual private gateway public IP address. 

Provides a dedicated private connection from a remote network to your VPC. 

Direct Connect can be combined with an AWS hardware VPN connection to create an IPsec-encrypted connection.

 REDUCES YOUR BANDWIDTH COSTS: First, by transferring data to and from AWS directly. Second, all data transferred over your dedicated connection is charged at the reduced AWS Direct Connect data transfer rate rather than Internet data transfer rates.

CONSISTENT NETWORK PERFORMANCE: Network latency over the Internet can vary given that the Internet is constantly changing how data gets from point A to B. With AWS Direct Connect, you choose the data that utilizes the dedicated connection and how that data is routed which can provide a more consistent network experience over Internet-based connections.

COMPATIBLE WITH ALL AWS SERVICES: AWS Direct Connect is a network service, and works with all AWS services that are accessible over the Internet, such as Amazon Simple Storage Service (Amazon S3), Elastic Compute Cloud (Amazon EC2), and Amazon Virtual Private Cloud (Amazon VPC).

PRIVATE CONNECTIVITY TO YOUR AMAZON VPC: You can use AWS Direct Connect to establish a private virtual interface from your on-premise network directly to your Amazon VPC, providing you with a private, high bandwidth network connection between your network and your VPC. 

ELASTIC: AWS Direct Connect makes it easy to scale your connection to meet your needs. AWS Direct Connect provides 1 Gbps and 10 Gbps connections, and you can easily provision multiple connections if you need more capacity. You can also use AWS Direct Connect instead of establishing a VPN connection over the Internet to your Amazon VPC, avoiding the need to utilize VPN hardware that frequently can’t support data transfer rates above 4 Gbps.

SIMPLE: You can sign up for AWS Direct Connect service quickly and easily using the AWS Management Console. The console provides a single view to efficiently manage all your connections and virtual interfaces. You can also download customized router templates for your networking equipment after configuring one or more virtual interfaces.

Link aggregation groups (LAG):  You can use multiple connections for redundancy. A link aggregation group (LAG) is a logical interface that uses the Link Aggregation Control Protocol (LACP) to aggregate multiple connections at a single AWS Direct Connect endpoint, allowing you to treat them as a single, managed connection. LAGs streamline configuration because the LAG configuration applies to all connections in the group. 

For higher throughput, LAG can aggregate multiple DX connections to give a maximum of 40 Gig bandwidth. 

A VPN connection over this connection can provide secure connections between on-premise devices to AWS VGW. 

For more than one remote network for e.g. multiple branch offices, multiple AWS hardware VPN connections can be created via the VPC to enable communication between these networks.

Using AWS VPN CloudHub, VGW can be used to connect multiple locations. 

Each location using an existing Internet link & customer routers will set up a VPN connection to VGW. 

BGP Peering will be configured between customer gateway router & VGW using unique BGP ASN at each location. 

VGW will receive prefixes from each location & re-advertise to other peers. 

VPN CloudHub can be used to provide secure communication between sites, if you have multiple VPN connections.

VPN CloudHub operates on a simple hub-and-spoke model that can be used with or without a VPC. 

Each customer gateway must use a unique Border Gateway Protocol (BGP) Autonomous System Number (ASN) and a unique public IP  of the gateway.

Routing advertisements are received and re-advertised to each BGP peer, enabling each site to send data to and receive data from the other sites. 

The sites must not have overlapping IP ranges. 

Each site can also send and receive data from the VPC as if they were using a standard VPN connection. 

Sites that use AWS Direct Connect connections to the virtual private gateway can also be part of the AWS VPN CloudHub. 

Each VPN connection must advertise its specific BGP routes. This is done using the network statements in the VPN configuration files for the VPN connection. 

VPN connection can be setup by running a software VPN like OpenVPN appliance on an EC2 instance in the VPN

AWS does not provide or maintain software VPN appliances; however, there are range of products provided by partners and open source communities

Bastion host is an instance launched  in the Public subnets would act as a primary access point from the Internet and acts as a proxy to other instances. 

Bastion host is a security measure that helps to reduce attack on your infrastructure and you have to concentrate to hardening a single layer.

Bastion host allows you to login to instances in the Private subnet securely without having to store the private keys on the Bastion host (using ssh-agent forwarding or RDP gateways).

Bastion host security can be further tightened to allow SSH/RDP access from specific trusted IPs or corporate IP ranges.

Security for all the Instances in the private subnet should be hardened to accept SSH/RDP connections only from the Bastion host. 

Deploy a Bastion host within each Availability Zone for HA, cause if the Bastion instance or the AZ hosting the Bastion server goes down the ability to connect to your private instances is lost completely

Acts as a hub for all traffic to flow through between your networks.

Connect up to 5,000 VPCs and on-premises environments with a single gateway

Fully managed and highly available

Steps

1. The first step to creating this connectivity is to set up a transit gateway. This can be done through the Amazon EC2 dashboard. Various charges apply for using transit gateway – make sure your architecture and budget can support this. 

2. Transit Gateway operates though network interfaces which are deployed into subnets. To effectively use Transit Gateway, you need to deploy one attachment into each Availability Zone your target VPC occupies. 

3. In each route table of your VPC, make sure traffic is routing outwards towards the Transit Gateway attachment. These attachments are connected to the Transit Gateway. 

4. Inside the Transit Gateway, you can create route tables to direct traffic how you see fit. You can have multiple route tables for very specific interactions. In this case, this just has the one to allow full connectivity. 

Transit VPCs can solve some of the shortcomings of VPC peering by introducing a hub and spoke design for inter-VPC connectivity. 

In a transit VPC network, one central VPC (the hub VPC) connects with every other VPC (spoke VPC) through a VPN connection typically leveraging BGP over IPsec. 

The central VPC contains EC2 instances running software appliances that route incoming traffic to their destinations using the VPN overlay (Figure 3). 

Transit VPC peering has the following advantages: (1) Transitive routing is enabled using the overlay VPN network — allowing for a simpler hub and spoke design. (2) When using 3rd party vendor software on the EC2 instance in the hub transit VPC, vendor functionality around advanced security (layer 7 firewall/IPS/IDS) can be leveraged. If customers are using the same software on-premises, they benefit from a unified operational/monitoring experience.

Transit Gateway provides a number of advantages over Transit VPC:

1. Transit Gateway abstracts away the complexity of maintaining VPN connections with hundreds of VPCs.

2. Transit Gateway removes the need to manage and scale EC2 based software appliances. AWS is responsible for managing all resources needed to route traffic.

3. Transit Gateway removes the need to manage high availability by providing a highly available and redundant Multi-AZ infrastructure.

4. Transit Gateway improves bandwidth for inter-VPC communication to burst speeds of 50 Gbps per AZ.

5. Transit Gateway streamlines user costs to a simple per hour per/GB transferred model.

6. Transit Gateway decreases latency by removing EC2 proxies and the need for VPN encapsulation.

A proxy server is a server that acts as a mediator between the client(s) that sends requests and the server that receives the requests and replies back. 

If any client requires any resources, it connects to the proxy server, and the proxy server evaluates the request based on its filtering rules. 

If the requests are valid, it connects to the server which receives the request and replies. 

The proxy server also maintains cache; i.e., if any subsequent requests from the same or other clients are received, it returns the result from the cache, saving the trip to and from the server. Hence, proxy servers tend to improve performance. 

Usage Example: You want your VPC Instances to be able to access software distribution servers on the Internet for product updates. The servers are accessible via the third party via their DNS names. You want to make sure that the instances can only access these known servers based on their URLs. 

VPCs per Region : 5

Subnets per VPC : 200

IPv4 CIDR blocks per VPC : 5

IPv6 CIDR blocks per VPC : 1

Elastic IP addresses per Region : 5

Egress-only internet gateways per Region : 5

Internet gateways per Region : 5

NAT gateways per Availability Zone : 5

Carrier gateways per VPC : 1

Network ACLs per VPC : 200

Rules per network ACL : 20

Security groups per VPC : 500

Security groups per network interface : 5

Network interfaces per instance : This limit varies by instance type.

Network interfaces per Region : 5,000

Route tables per VPC : 200

Routes per route table (non-propagated routes) : 50

VPC security groups per Region : 2,500

Inbound or outbound rules per security group : 60

Active VPC peering connections per VPC : 50

Outstanding VPC peering connection requests : 25

Expiry time for an unaccepted VPC peering connection request : 1 week

Gateway VPC endpoints per Region : 20

Interface and Gateway Load Balancer endpoints per VPC : 50

VPC endpoint policy size : 20,480 characters

Participant accounts per VPC in a Shared VPC : 100

Subnets that can be shared with an account : 100

VPC General Concepts