Domain 4.0: Network Design for a complex large scale deployment (10% of Exam)
4.1 Demonstrate ability to design and implement networking features of AWS
4.2 Demonstrate ability to design and implement connectivity features of AWS
- When you create a NAT instance, don’t forget to disable source/destination checks!
-
- Connecting 2 VPCs within a single region
- Transitive peering is not supported (on purpose)
- Up to 50 peers can be created (soft limit, contact amazon to go up to 125)
- Allows you to route traffic between the peer VPCs using private IP addresses; as if they are part of the same network.
- Can’t have matching or overlapping CIDR blocks
- A placement group can span peered VPCs, but you won’t get full bandwidth between instances
- Can’t reference a security group from peer VPC as source/destination for ingress/egress rules. Instead use CIDR blocks
- Private DNS values cannot resolve between instances in peered VPCs (use private IP addresses instead)
-
How to setup:
- Local VPC owner sends request to remote VPC owner
- Remote VPC owner has to accept
- Local VPC adds route out to route table
- Remote VPC adds route back to their route table
- Security Groups & NACLs in both VPCs have to allow traffic
- Connecting 2 VPCs within a single region
-
AWS Direct Connect (https://aws.amazon.com/directconnect/faqs/) :
- https://youtu.be/SMvom9QjkPk
-
Can be partitioned into multiple virtual interfaces (VIFS)
- use the same connection to access public IP address space (EC2, DynamoDB, & S3) via public VIFs, and private resources (internal IP addresses) via private VIFs
- Reduce costs when dealing with large volumes of traffic
- Increase reliability & bandwidth
- Available in 10Gbps, 1Gbps and sub-1Gbps (through Direct Connect Partners)
- Uses 802.1Q Ethernet VLAN trunking
-
Is not redundant:
- You can add redundancy by having 2 connections (2 routers, 2 direct connects) or by having a site-to-site VPN in place (using BGP for failover)
- Layer 2 connections are not supported
-
When using a VPN to connect to a VPC, you need 2 anchor points:
- Customer Gateway (CGW): physical or software appliance
- Virtual Private Gateway (VPG): anchor on the AWS side
- In US only, just need 1 Direct Connect to connect to all 4 US regions.
- Recommended best practice for an HA solution is to use either 2 DXs or 1 DX and 1 VPN.
- Does not support jumbo frames
- External Border Gateway Protocol (eBGP) for routing
-
- Batch processing with large, compute intensive workloads
- Demands high CPU, Storage & networking requirements
- Usually requires jumbo frames as well (MTU 9000)
-
Enhanced networking (https://aws.amazon.com/ec2/faqs/) is available using SR-IOV on supported instance types:
- C3, C4, D2, I2, M4, R3
- Must be HVM, not PV (paravirtual)
- http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html
-
Placement Groups (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
- Don’t span AZs, 1 PG = 1 AZ
-
Can span subnets (in same AZ)
- only certain supported instances (C3, C4, D2, I2, M4, R3)
- existing instances can’t be moved into a PG
-
Amazon prefers homogenous instance types, but you can mix
- Greater likelihood that launch will succeed
- Best practice is to size PG for peak load & launch all instances @ the same time as there may not be sufficient capacity in the AZ to add extra instances later on.
-
Elastic Load Balancers (https://aws.amazon.com/elasticloadbalancing/):
- Region wide load balancer
- Can be used internally or externally
- Can do SSL termination and processing
-
Cookie based sticky session (session affinity) http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
- ELB routing the same client to the same application server
- AWS best practice dictates using the DB instead of using ELB for sticky sessions so that you don’t impact the user
- Integrates with auto-scaling
- ELB EC2 health checks (query a page)
-
Integrate with CloudWatch
- Advance metric Load balancing based on CloudWatch metrics (CPU, network usage, disk, etc.)
- Integrate with Route 53 (Cloud based DNS load balancing)
-
Supported ports:
- 25 (SMTP)
- 80/443
- 1024-65535
- Can’t assign Elastic IPs to an ELB
- IPv4 & IPv6 supported (but VPCs don’t support IPv6 currently)
- Can load balance to zone apex of domain name
- Can get history of ELB API calls by turning on CloudTrail (output to S3 bucket & inspect logs in bucket)
- 1 SSL certificate per ELB unless you have a wildcard cert.
-
NAT instance vs NAT Gateway
- Evaluate technical difference between the 2 for your needs, if you don’t need a specific item only supported by an instance, go gateway.
-
Instance
- Use a script to manage failover between instance
- Depends on the bandwidth of the instance type
- Managed by you
- Manual port forwarding
- Use a bastion server to manage
- Use CloudWatch to see traffic/alarms
-
Gateway
- Built in HA. Gateways in each AZ are implemented with redundancy
- Can burst up to 10Gbps
- Managed by AWS
- Optimized for handling NAT traffic
- Port forwarding not supported
- Bastion server not supported
- Traffic metrics not supported
-
Scaling NATs
-
Scale UP
- Increase instance size
- Choose instance family which supports enhanced networking (C3, C4, D2, I2, M4, R3)
-
Scale OUT
- Add an additional NAT & subnet, then migrate ½ of workloads to new subnet
- http://nineofclouds.blogspot.com/2013/01/vpc-migration-nats-bandwidth-bottleneck.html
- https://aws.amazon.com/articles/2781451301784570
-
- http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html