VPC

Share this page:

About VPC

From 2006, when AWS started, everyone there was one single public network for everyone. Since December 2013 VPC is by default, you cannot have an instance that’s NOT in a VPC.

Subnets

A VPC is created in one of the 21 regions, and then you choose one or more AZs to span your application. Subnet is created in a single AZ.

IMPORTANT: 5 IPs are reserved by AWS (first 4 and the last one) for an internal management and routing, so you cannot use that. Have it in mind when planning subnets.

Gateways

IGW is used for Public Subnets to reach Internet. Before you assign a IGW, all Subnets are private. VPG - Virtual Private Gateway, for VPN with your on-prem.

Transit GW is used for various Data Centers and VPCs to connect using a Hub and Spoke configuration. Important:

• Each connection VPN to TGW or VPC to TGW is an Attachment
• 5 Transit Gateways are supported per account
• You need to propagate MANUALY routes from TGW to VPCs
• You now have the option to propagate routes by default to a default Route Table
• DirectConnect is NOT supported at the moment (Sep2019)

Security

NACL: Allow/deny traffic into the Subnet. NACLs are optional, but recommendable, as the “first line of defense” Security Groups: Allow/deny traffic into the Instance, for more granular control. Security groups are processed at the Elastic Network Interface for the Instance.

IMPORTANT: NACLs are stateless, so you need to allow both, Inbound and Outbound manually. Security Groups are stateful, so you can just focus on Inbound.

Code

Deep Dive

Elastic Load Balancing

Auto Scaling is one of the biggest benefits of the Public Cloud.

You can monitor CPU or Memory, you can define advanced metrics, or you can use Machine Learning to do the auto scaling the SMART way.

ELB is not a real HW load balancer, it’s actually a EC2 instance, launched in the AZ where we’re deploying the instances. If you use a Cross-zone load balancing, ELB can send the traffic to instances in different AZ within a region.

ELB has its own DNS record set, and ELB will not use a static IP as VIP, you can only do this using a Network Load Balancer.

There are 3 types of Load Balancers:

• Classic ELB, for simple load balancing (TCP). All instances get routed to evenly.
• Application ELB, which has replaced a classic ELB, and it can LB on L7. It’s able to inspect a L7, and you can create Target Groups for advanced LB within the same subnet, like based on a folder or other content-based rules. You can have this ELB process AWS WAF rules.
• Network Load Balancer (not elastic, no SSL offload) for a simple L4 Load balancing. This responds to a use case where there is a sudden increase in traffic, because this LB is not running on EC2 instance so you don’t have to wait for EC2 ELB to scale as an instance. Also if you need a STATIC IP address as a VIP.

NAT: If you use a EC2 instance, instead of NAT as a managed service, you’re limited to an instance throughput.

VPC Endpoints:

• Gateway Endpoint to store stuff in S3 or DynamoDB without data going on the public network. Route tables are updated so that the traffic are sent using these Endpoints, instead of going to the IGW.
• Interface Endpoints, on the Elastic Interface, using the Private Address.

Direct Connect Each AWS Direct Connect connection can be configured with one or more virtual interfaces. Virtual interfaces may be configured to access AWS services such as Amazon EC2 and Amazon S3 using public IP space, or resources in a VPC using private IP space.

AWS Transit Gateway

The problem TGW solves is:

• Avoid a full mesh of VPN Peerings. TGW scales to 500 VPCs, and supports ECMP.
• Avoid configuring a Customer Gateway and VIF in each VPC.

Direct Connect Gateway introduces a Transit VIF, so you no longer need a VIF per VPN.

!!! You cannot mix normal Direct Connect Gateways and Transit VIF.

As a further improvement, in TGW we have Attachments, which is where we attach 3 resource types:

• VPC
• Direct Connect
• VPN

IMPORTANT: each attachment can have a SINGLE Route Table association. TGW has a default route table called Routing Domain, so you can use that one, or define a custom one.

In each Attachment you need to worry about two directions of routes:

• TGW gets the routes from the attachments, statically or dynamically.
• In TGW you can define what routes are propagated to the other Attachments.

If you use Direct Connect and VPN as a Backup, you need to have in mind how Route Table is populated:

1. Most specific prefix
2. Static Routes
3. VPC propagated
4. Direct Connect routes
5. VPN routes

Where to find more info

Feedback

Was this page helpful?

Yes No

Awesome! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.