architecting-networks

Name: architecting-networks
Author: ancoleman

54installs59forks

How to install architecting-networks?

ancoleman/ai-design-components/architecting-networks

$npx -y skills add ancoleman/ai-design-components --skill architecting-networks

Installs into the current project.

Summary

Design cloud network architectures with VPC patterns, subnet strategies, zero trust principles, and hybrid connectivity. Use when planning VPC topology, implementing multi-cloud networking, or establishing secure network segmentation for cloud workloads.

Files · 1

View on GitHub

SKILL.md

1	# Network Architecture
2
3	Design secure, scalable cloud network architectures using proven patterns across AWS, GCP, and Azure. This skill provides decision frameworks for VPC design, subnet strategy, zero trust implementation, and hybrid connectivity.
4
5	## When to Use This Skill
6
7	Invoke this skill when:
8	- Designing VPC/VNet topology for new cloud environments
9	- Implementing network segmentation and security controls
10	- Planning multi-VPC or multi-cloud connectivity
11	- Establishing hybrid cloud connectivity (on-premises to cloud)
12	- Migrating from flat network to sophisticated architecture
13	- Implementing zero trust network principles
14	- Optimizing network costs and performance
15
16	## Core Network Architecture Patterns
17
18	### Pattern 1: Flat (Single VPC) Architecture
19
20	Use When: Small applications, single environment, simple security requirements, team < 10 engineers
21
22	Characteristics:
23	- All resources in one VPC with subnet-level segmentation
24	- Public, private, and database subnet tiers
25	- Simplest to understand and manage
26	- No inter-VPC routing complexity
27
28	Tradeoffs:
29	- ✓ Lowest cost, fastest to set up
30	- ✗ Poor isolation, difficult to scale, entire VPC is blast radius
31
32	### Pattern 2: Multi-VPC (Isolated) Architecture
33
34	Use When: Multiple environments (dev/staging/prod), strong isolation requirements, compliance mandates separation
35
36	Characteristics:
37	- Separate VPCs per environment or workload
38	- No direct connectivity without explicit setup
39	- Independent CIDR ranges
40
41	Tradeoffs:
42	- ✓ Strong blast radius containment, clear security boundaries
43	- ✗ Management overhead, duplicate infrastructure, higher costs
44
45	### Pattern 3: Hub-and-Spoke (Transit Gateway) Architecture
46
47	Use When: 5+ VPCs need communication, centralized security inspection required, hybrid connectivity, multi-account setup
48
49	Characteristics:
50	- Central hub VPC/Transit Gateway
51	- Spoke VPCs connect to hub
52	- All inter-VPC traffic routes through hub
53
54	Tradeoffs:
55	- ✓ Simplified routing, centralized security, scales easily (100+ VPCs)
56	- ✗ Transit Gateway costs (~$0.05/hour + $0.02/GB), increased latency (hub hop)
57
58	### Pattern 4: Full Mesh (VPC Peering) Architecture
59
60	Use When: Small number of VPCs (< 5), low latency critical, no centralized inspection needed
61
62	Characteristics:
63	- Every VPC directly connected via peering
64	- Direct VPC-to-VPC communication
65
66	Tradeoffs:
67	- ✓ Lowest latency, no Transit Gateway costs
68	- ✗ Management complexity scales as O(n²), doesn't scale beyond ~10 VPCs
69
70	### Pattern 5: Hybrid (Multi-Pattern) Architecture
71
72	Use When: Large enterprise with diverse requirements, balancing cost/performance/security
73
74	Characteristics:
75	- Hub-spoke for most VPCs + direct peering for latency-sensitive pairs
76	- Combination based on workload requirements
77
78	Tradeoffs:
79	- ✓ Optimized for specific needs
80	- ✗ More complex to design and manage
81
82	## Pattern Selection Framework
83
84	```
85	Number of VPCs?
86	│
87	├─► 1 VPC → Flat (Single VPC)
88	├─► 2-4 VPCs + No inter-VPC communication → Multi-VPC (Isolated)
89	├─► 2-5 VPCs + Low latency critical → Full Mesh (VPC Peering)
90	├─► 5+ VPCs + Centralized inspection → Hub-and-Spoke (Transit Gateway)
91	└─► 10+ VPCs + Mixed requirements → Hybrid (Multi-Pattern)
92
93	Additional Considerations:
94	├─► Hybrid connectivity required? → Hub-and-Spoke preferred
95	├─► Centralized egress/inspection? → Hub-and-Spoke with Inspection VPC
96	├─► Multi-account environment? → Hub-and-Spoke with AWS RAM sharing
97	└─► Cost optimization priority? → Flat or Multi-VPC (avoid TGW fees)
98	```
99
100	## Subnet Strategy
101
102	### Standard Three-Tier Design
103
104	Public Subnets:
105	- Route to Internet Gateway
106	- Use for load balancers, bastion hosts, NAT Gateways
107	- CIDR: /24 to /27 (256 to 32 IPs)
108
109	Private Subnets:
110	- Route to NAT Gateway for outbound
111	- Use for application servers, containers, compute workloads
112	- CIDR: /20 to /22 (4,096 to 1,024 IPs)
113
114	Database Subnets:
115	- No direct internet route
116	- Use for RDS, ElastiCache, managed databases
117	- CIDR: /24 to /26 (256 to 64 IPs)
118
119	### Multi-AZ Distribution
120
121	Production: Distribute each tier across 3 Availability Zones minimum
122	Dev/Test: 1-2 AZs acceptable for cost savings
123
124	### CIDR Block Planning
125
126	VPC Sizing:
127	- /16 (65,536 IPs) - Large production environments
128	- /20 (4,096 IPs) - Medium environments
129	- /24 (256 IPs) - Small/dev environments
130
131	Critical Rules:
132	- Non-overlapping CIDR ranges across VPCs
133	- Coordinate with on-premises network team for hybrid connectivity
134	- Reserve address space for future expansion
135
136	For detailed subnet planning, see `references/subnet-strategy.md`
137
138	## NAT Gateway Strategy
139
140	### Decision Framework
141
142	```
143	Cost vs Resilience?
144	│
145	├─► Cost Priority (Dev/Test)
146	│ └─► Single NAT Gateway (

People who liked this also viewed

6 picks

Type

architecting-networks

54installs59forks

View on GitHub

How to install architecting-networks?

ancoleman/ai-design-components/architecting-networks

$npx -y skills add ancoleman/ai-design-components --skill architecting-networks

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Network Architecture
2
3	Design secure, scalable cloud network architectures using proven patterns across AWS, GCP, and Azure. This skill provides decision frameworks for VPC design, subnet strategy, zero trust implementation, and hybrid connectivity.
4
5	## When to Use This Skill
6
7	Invoke this skill when:
8	- Designing VPC/VNet topology for new cloud environments
9	- Implementing network segmentation and security controls
10	- Planning multi-VPC or multi-cloud connectivity
11	- Establishing hybrid cloud connectivity (on-premises to cloud)
12	- Migrating from flat network to sophisticated architecture
13	- Implementing zero trust network principles
14	- Optimizing network costs and performance
15
16	## Core Network Architecture Patterns
17
18	### Pattern 1: Flat (Single VPC) Architecture
19
20	Use When: Small applications, single environment, simple security requirements, team < 10 engineers
21
22	Characteristics:
23	- All resources in one VPC with subnet-level segmentation
24	- Public, private, and database subnet tiers
25	- Simplest to understand and manage
26	- No inter-VPC routing complexity
27
28	Tradeoffs:
29	- ✓ Lowest cost, fastest to set up
30	- ✗ Poor isolation, difficult to scale, entire VPC is blast radius
31
32	### Pattern 2: Multi-VPC (Isolated) Architecture
33
34	Use When: Multiple environments (dev/staging/prod), strong isolation requirements, compliance mandates separation
35
36	Characteristics:
37	- Separate VPCs per environment or workload
38	- No direct connectivity without explicit setup
39	- Independent CIDR ranges
40
41	Tradeoffs:
42	- ✓ Strong blast radius containment, clear security boundaries
43	- ✗ Management overhead, duplicate infrastructure, higher costs
44
45	### Pattern 3: Hub-and-Spoke (Transit Gateway) Architecture
46
47	Use When: 5+ VPCs need communication, centralized security inspection required, hybrid connectivity, multi-account setup
48
49	Characteristics:
50	- Central hub VPC/Transit Gateway
51	- Spoke VPCs connect to hub
52	- All inter-VPC traffic routes through hub
53
54	Tradeoffs:
55	- ✓ Simplified routing, centralized security, scales easily (100+ VPCs)
56	- ✗ Transit Gateway costs (~$0.05/hour + $0.02/GB), increased latency (hub hop)
57
58	### Pattern 4: Full Mesh (VPC Peering) Architecture
59
60	Use When: Small number of VPCs (< 5), low latency critical, no centralized inspection needed
61
62	Characteristics:
63	- Every VPC directly connected via peering
64	- Direct VPC-to-VPC communication
65
66	Tradeoffs:
67	- ✓ Lowest latency, no Transit Gateway costs
68	- ✗ Management complexity scales as O(n²), doesn't scale beyond ~10 VPCs
69
70	### Pattern 5: Hybrid (Multi-Pattern) Architecture
71
72	Use When: Large enterprise with diverse requirements, balancing cost/performance/security
73
74	Characteristics:
75	- Hub-spoke for most VPCs + direct peering for latency-sensitive pairs
76	- Combination based on workload requirements
77
78	Tradeoffs:
79	- ✓ Optimized for specific needs
80	- ✗ More complex to design and manage
81
82	## Pattern Selection Framework
83
84	```
85	Number of VPCs?
86	│
87	├─► 1 VPC → Flat (Single VPC)
88	├─► 2-4 VPCs + No inter-VPC communication → Multi-VPC (Isolated)
89	├─► 2-5 VPCs + Low latency critical → Full Mesh (VPC Peering)
90	├─► 5+ VPCs + Centralized inspection → Hub-and-Spoke (Transit Gateway)
91	└─► 10+ VPCs + Mixed requirements → Hybrid (Multi-Pattern)
92
93	Additional Considerations:
94	├─► Hybrid connectivity required? → Hub-and-Spoke preferred
95	├─► Centralized egress/inspection? → Hub-and-Spoke with Inspection VPC
96	├─► Multi-account environment? → Hub-and-Spoke with AWS RAM sharing
97	└─► Cost optimization priority? → Flat or Multi-VPC (avoid TGW fees)
98	```
99
100	## Subnet Strategy
101
102	### Standard Three-Tier Design
103
104	Public Subnets:
105	- Route to Internet Gateway
106	- Use for load balancers, bastion hosts, NAT Gateways
107	- CIDR: /24 to /27 (256 to 32 IPs)
108
109	Private Subnets:
110	- Route to NAT Gateway for outbound
111	- Use for application servers, containers, compute workloads
112	- CIDR: /20 to /22 (4,096 to 1,024 IPs)
113
114	Database Subnets:
115	- No direct internet route
116	- Use for RDS, ElastiCache, managed databases
117	- CIDR: /24 to /26 (256 to 64 IPs)
118
119	### Multi-AZ Distribution
120
121	Production: Distribute each tier across 3 Availability Zones minimum
122	Dev/Test: 1-2 AZs acceptable for cost savings
123
124	### CIDR Block Planning
125
126	VPC Sizing:
127	- /16 (65,536 IPs) - Large production environments
128	- /20 (4,096 IPs) - Medium environments
129	- /24 (256 IPs) - Small/dev environments
130
131	Critical Rules:
132	- Non-overlapping CIDR ranges across VPCs
133	- Coordinate with on-premises network team for hybrid connectivity
134	- Reserve address space for future expansion
135
136	For detailed subnet planning, see `references/subnet-strategy.md`
137
138	## NAT Gateway Strategy
139
140	### Decision Framework
141
142	```
143	Cost vs Resilience?
144	│
145	├─► Cost Priority (Dev/Test)
146	│ └─► Single NAT Gateway (

People who liked this also viewed

6 picks

Type