AWS Landing Zone Network Structure 2016 Amazon Web

Introduction • Landing Zone engagement context • Previously: Account Structure and Security Baseline • Now: Network Architecture

What we’ll cover v v v VPC Patterns and Tenets Multi-VPC Connectivity Patterns and Tenets Appling account structure to selected VPC pattern On-Premises/Cross-Region/Internet Architecture Extensibility

Landing Zone Network Tenets • Use dedicated network address space for your AWS networks (no overlapping IP ranges). • Design networks to support highly available applications (e. g. leverage all available AZs). • Do not over-engineer your initial network structure. Instead, use an iterative approach to creating and structuring your networks. • Enable default monitoring features (VPC Flow Logs) • Leverage AWS native network features (peering, VPC endpoints, etc. )

AWS Landing Zone IPAM (IP Address Management) Are you currently using RFC 2860 or 6598 (100. 64. 0. 0/10)? 4, 194, 176 addresses Small block preallocation Medium block preallocation Large block preallocation 100. 64. 0. 0/10 Divide a CIDR into several pre-sized smaller CIDR blocks ü Small: 2 k ü Medium: 8 k ü Large: 16 k

VPC Tenets/Best Practices • • • When designing your VPC, determine user/application access. o Will it be external resources? o Internal resources? o Both? Decide VPC network range. Ensure that your VPC network ranges (CIDR blocks) do not overlap. Make sure the solution you choose is able to scale according to your current and future VPC connectivity needs. Put subnets in each Availability Zone (AZ), for each use case (public/private/hybrid), where applicable. Connect only those VPCs that really need to communicate with each other.

Individual VPC Patterns ü Hybrid 2 -tier (public and private) ü Internal-only ü Internet-only ü Hybrid 3 -tier (Presentation/Application/Data)

Sample VPC Architecture – Hybrid (2 -tier) VPC subnet Internet gateway VPC endpoint bucket flow logs Internet users AWS service VPC subnet virtual private cloud VPN gateway corporate data center users

Sample VPC Architecture - Internal VPC endpoint bucket flow logs AWS service VPC subnet virtual private cloud VPN gateway corporate data center users

Sample VPC Architecture - Internet VPC subnet Internet gateway VPC endpoint bucket flow logs virtual private cloud Internet AWS service users

Sample VPC Architecture – Hybrid (3 -tier) Presentation Internet gateway Internet users Application VPC endpoint bucket flow logs Data virtual private cloud VPN gateway AWS service corporate data center users

Public subnet Private subnet VPC peering Public subnet Private subnet Availability Zone Shared Services Internet gateway Private subnet Availability Zone VPC endpoint Private subnet Availability Zone Application Public subnet Internet gateway VPC endpoint

How do we connect AWS to existing infrastructure? <internal> Modify deck based on questionnaire to model the correct architecture/pattern for on-prem connectivity. • Direct Connect • VPN Gateway • Stand up a VGW initially with VPN, with the intent of provisioning DX later

Public subnet Internet gateway Public subnet VPC peering Private subnet Availability Zone VPC endpoint Private subnet Availability Zone Shared Services AWS Direct Connect Private subnet VPN gateway Phase 1: Temporary connectivity (VPN gateway connections to one or more VPCs, while waiting on circuit provider/partner to install Direct Connect circuit. VPC endpoint Application VPN gateway Customer VPN appliance corporate data center users

Public subnet Internet gateway Public subnet VPC peering Private subnet Availability Zone Availability Zone VPC endpoint Shared Services Private subnet VPN gateway customer gateway VPC endpoint Application VPN gateway customer gateway AWS Direct Connect Phase 2: Shift connectivity to Direct Connect Phase 3: Maintain VPN gateways for redundant Connectivity (disaster recovery) Customer VPN appliance corporate data center users

Multi-VPC Partially Meshed Network (VPC Peering) Customers can create multiple VPCs within the same region or in different regions, in the same account or in different accounts. This option is best suited for customers with the following use case/requirements: ü Do not require full connectivity between all of their VPCs. ü Would benefit from a central VPC to host shared services such as Active Directory or a central repository. ü Have multiple VPCs that need access to shared resources but do not need access to each other. ü They require fewer than 100 peering connections per VPC.

Multi-VPC Hub-and-Spoke with Shared Services Pattern 1(Partially Meshed) • A single shared services VPC that offers common infrastructure support services (Active Directory, anti-virus, etc) is peered with each application VPC.

Multi-VPC Hub-and-Spoke with Shared Services Pattern 2 • Enhances Pattern 1 to include limited app VPC to app VPC peering (where needed for application connectivity).

Applying VPC Pattern to Accounts Billing Account Structure Security & Audit Account Structure Shared Services Account Structure Application Account Structure

Architectural Patterns The following patterns interact with on-premises: ü Replicate to Shared Services VPC ü Multiple VPN/DX VIFs ü Transit VPC

Sample Support Architecture – Replicate to Shared Services VPC; AD Auth example • Support tools such as Active Directory and anti-virus are replicated from on-premises to the Shared Services VPC. • On-site admins proxy connections through jump boxes to configure EC 2 instances.

What goes in shared services? • Authentication (Active Directory or a Read-only Domain Controller) • Time/DNS • CI/CD pipeline Considerations: • Bandwidth • Duplicated infrastructure

Multiple VPN/DX VIFs (done per app VPC) This design pattern leverages AWS Direct Connect to route traffic between VPCs, and offers customers the ability to incorporate transitive routing into their network design. This option is best suited for customers with the following use case/requirements: • • • They have an existing AWS Direct Connect connection. They can use the AWS Direct Connect connection for transitive routing between VPCs. They need to create more than 100 connections per VPC. Jenkins This can also be used to leverage existing on-premises resources, like CI/CD infrastructure for deployments.

Transit VPC This approach uses customer-managed Amazon Elastic Compute Cloud (Amazon EC 2) VPN instances in a dedicated transit VPC with an Internet gateway. This option is best suited for customers with the following use case/requirements: • They have already implemented a transit VPC • They want to leverage it to manage more advanced connection types, such as interregion connectivity, or multi-VPC connectivity to on-premises resources.

Network Architecture Extensibility Please view the Network Architecture for Landing Zone as a one-size-fits-most solution. Please feel free to extend the architecture to fit the customer’s needs. Thoughts: • Additional subnet separation • Additional granularity around account separation (for example, specific Security Logs account for auditing web access; CI/CD shared services; pre-production accounts, etc. )

Internal Conversations with Security and Ops Workstreams • Avoid NACLs - they only work on traffic between subnets • Adopt a security group naming convention

Q&A

Thank You!