Bukan lagi: bagaimana membuat VPC?
Tetapi: siapa boleh menghubungkan apa, melalui path mana, dengan policy siapa, dan failure-nya berhenti di mana?

explicit
owned
auditable
segmented
repeatable
recoverable
cost-visible
safe under partial failure

"Sudah beda AWS account, berarti aman."

VPC peering
Transit Gateway
PrivateLink
VPC Lattice
VPN
Direct Connect
Route 53 Resolver forwarding
shared VPC/subnet
public internet path
CloudFront/ALB/API Gateway entrypoint

route table
security group
NACL
endpoint policy
resource policy
firewall policy
DNS rule
SCP/IAM guardrail
inspection path
logging path

Account = administrative cell
VPC     = network cell
Subnet  = placement + routing cell
Route   = reachability statement
Policy  = permission statement
DNS     = naming authority
Logs    = evidence stream

Kalau account A compromise, account mana yang ikut reachable?
Kalau route salah propagate, environment mana yang bocor?
Kalau DNS forwarding salah, service mana resolve ke target salah?
Kalau NAT/inspection VPC mati, traffic mana yang terhenti?
Kalau app team membuat VPC sendiri, siapa mencegah CIDR overlap?
Kalau vendor minta koneksi, apakah kita expose network atau hanya service?

Network account  -> owns connectivity primitives
Security account -> owns detection, logs, inspection governance
Workload account -> owns application runtime
Shared account   -> owns common internal services

prod and non-prod
regulated and non-regulated
internet-facing and internal
team A and team B
experiments and critical services

"Network-nya shared, tapi trust us."

who can create routes
who can attach VPC to core network
which accounts have internet egress
which accounts can receive inbound traffic
where logs go
which policy blocks bypass

CIDR plan
VPC module
NAT pattern
DNS pattern
endpoint pattern
inspection pattern
logging pattern

Account yang mengelola routing global tidak sama dengan account yang menyimpan data bisnis sensitif.

Transit Gateway
Cloud WAN core network
Direct Connect Gateway association
Site-to-Site VPN attachment
centralized ingress VPC
centralized egress VPC
inspection VPC
shared interface endpoints
Route 53 Resolver inbound/outbound endpoints
Network Firewall
Gateway Load Balancer appliances
IPAM administration
network automation pipeline

Network account owns the policy and shared control points.
Workload accounts own their local workload and local blast radius.

Org -> OU -> Account

node mana boleh attach?
edge mana boleh dibuat?
route mana boleh dipropagate?
DNS name mana boleh resolve ke mana?
traffic mana wajib inspect?
traffic mana dilarang transitive?

prod-core
nonprod-core
shared-services
internet-egress
inspection
partner
regulated
sandbox

Jangan membuat semua attachment propagate ke semua route table.

BAD:
Team bebas memilih 10.0.0.0/16.

GOOD:
Account/VPC creation meminta CIDR dari pool terkontrol.

pcx-... created 2 years ago, nobody knows why
TGW attachment without business owner
resolver rule forwarding to unknown DNS server
public hosted zone delegated but no owner

owner: platform-network
business_service: payments
source_account: prod-payments
connected_to: shared-services
approved_by: security-architecture
data_classification: confidential
expiry_review: 2026-12-31

Dari account mana workload bisa keluar ke internet?
Melalui NAT mana?
Apakah diinspect?
Apakah DNS-nya difilter?
Apakah egress domain allowlist/blocklist diterapkan?

CloudFront + WAF
Global Accelerator + NLB/ALB
public ALB with WAF
API Gateway + WAF

random public EC2
random public RDS
random public OpenSearch

public zone dikelola account mana?
private zone dikelola account mana?
zone mana associate ke VPC mana?
resolver forwarding rule dibuat siapa?
on-prem domain diarahkan ke mana?
AWS private domain diarahkan ke mana?

nonprod -> shared -> prod

consumer model
network exposure model
auth model
logging model
rate limit model
backup/failover model
owner

VPC CIDR
subnet
route table
TGW attachment
TGW route table association/propagation
peering route
resolver rule association
endpoint
security group baseline
NACL baseline
NAT route
egress inspection route
CloudFront/WAF entrypoint

+ autonomy tinggi
+ blast radius lokal
+ sederhana untuk team kecil
- policy drift
- cost duplication
- sulit audit
- sulit hybrid connectivity
- sulit enforce inspection

startup kecil
isolated workloads
sandbox/experiment
highly autonomous product units dengan guardrail kuat

+ governance kuat
+ audit mudah
+ consistent egress/inspection
+ hybrid simpler
- central bottleneck
- routing complexity tinggi
- blast radius network account besar
- potential cross-AZ/cross-region cost
- platform team bisa jadi blocker

regulated enterprise
hybrid-heavy organization
strict egress control
central security inspection requirement

+ scalable ownership
+ consistent baseline
+ local autonomy
+ governance tetap kuat
- butuh automation matang
- butuh contract jelas
- butuh observability lintas account

AWS Organizations
IAM roles
SCP
RAM share
CloudFormation/Terraform pipelines
approval workflow
config rules
service control guardrails

VPC route table
TGW route table
Cloud WAN segment
NAT Gateway
Network Firewall
GWLB appliance
PrivateLink endpoint
CloudFront edge
Global Accelerator edge
Direct Connect/VPN

VPC Flow Logs
TGW Flow Logs
Route 53 Resolver query logs
Network Firewall logs
WAF logs
CloudFront logs
ELB access logs
CloudTrail
AWS Config
Reachability Analyzer
Network Access Analyzer
CloudWatch metrics

"Karena IaC bilang route ada, berarti traffic pasti lewat sana."

VPC
subnet
route table
NACL
gateway
network-level structure

EC2
ECS/EKS worker/node resources if applicable
ENI created by participant-owned resources
security groups depending on service/resource model

central network team must own subnet/routing strictly
many small workload accounts use common network zones
legacy migration wants fewer VPCs
platform wants standardized subnet placement

application needs route autonomy
blast radius must be account-local
team needs isolated VPC-level quotas/settings
security boundary should be stronger
multi-region/cell architecture needs repeated units

App team: network team owns route.
Network team: app team owns SG.
Security team: nobody knows why this traffic exists.

Do not create duplicate private zones with different records unless intentionally split-horizon.
Do not forward all DNS to on-prem by default without understanding AWS private names.
Do not depend on public DNS for private service discovery if private DNS is required.
Log resolver queries for sensitive environments.
Document PHZ association ownership.

simple
AZ-local
low central blast radius
team autonomy

difficult central inspection
cost duplication
harder egress allowlist
harder audit

central inspection
consistent egress policy
central NAT/domain filtering
clear audit path

route complexity
TGW data processing cost
cross-AZ cost risk
central blast radius
must design appliance scaling and failover

least public exposure
smaller egress surface
works for regulated workloads

endpoint sprawl
Private DNS complexity
policy evaluation complexity
not every external dependency supports PrivateLink

local egress for low-risk/simple accounts
central egress for regulated/prod accounts
VPC endpoints for AWS service access

DNS -> edge -> L7/L4 entrypoint -> policy -> route -> target -> app authorization

Public inbound should be rare, named, logged, protected, and owned.

Active Directory / LDAP
internal DNS
certificate authority
artifact registry
CI/CD runners
observability endpoints
metadata/config service
bastion or SSM access pattern
central API gateways

service: internal-artifact-registry
producer_account: shared-services-prod
producer_vpc: shared-prod-vpc
exposure_model: PrivateLink
consumer_accounts:
  - prod-apps-ou
  - nonprod-apps-ou
ports:
  - 443
identity_required: true
network_policy:
  allowed_sources:
    - prod workload endpoint SG
    - nonprod workload endpoint SG
logs:
  - NLB access logs
  - VPC Flow Logs
  - application audit logs
availability:
  azs: 3
  failover: multi-AZ NLB targets
review_cycle: quarterly

share Transit Gateway for VPC attachments
share subnets for VPC sharing
share Route 53 Resolver rules
share IPAM pools
share prefix lists

Sharing a resource shares operational coupling.

Who owns lifecycle?
Who approves participant accounts?
Who pays?
Who can detach/delete?
What happens during incident containment?
How is drift detected?
What logs prove usage?

Enterprise private range
  Region pool
    Environment pool
      Business unit / product pool
        VPC allocation
          Subnet allocation

10.0.0.0/8 enterprise
10.32.0.0/11 ap-southeast-1
10.32.0.0/13 prod
10.40.0.0/13 nonprod
10.48.0.0/14 shared
10.52.0.0/14 network

prod payments account       -> 10.32.0.0/16
prod case-management account -> 10.33.0.0/16
prod analytics account       -> 10.34.0.0/16
nonprod payments account     -> 10.40.0.0/16
shared services              -> 10.48.0.0/16
network inspection           -> 10.52.0.0/16

/20 per AZ per subnet class for large platforms
/24 or /23 for smaller specialized subnet classes
reserve future subnet classes from day one

AWS workload ranges
on-prem ranges
partner/vendor ranges
future region ranges
IPv6 plan
overlap exception process

prod-vpc
nonprod-vpc

create workload VPC
attach workload VPC to route domain
request private service exposure
request shared service consumer access
request private hosted zone association
request egress exception
request partner connectivity
request public ingress

CIDR allocation
VPC/subnet/route tables
TGW attachment
route table association/propagation
security group baseline
endpoint baseline
resolver rule association
flow logs
tags/metadata
cost allocation
Config rules

Which route table is ProdVpcA associated with?
Which routes does it receive?
Does DevVpc receive routes to ProdVpcA?
Does SharedVPC receive return routes to every workload?
Is inspection symmetric?
Where do DNS queries go?
Where are flow/firewall/DNS logs stored?
Can workload teams create public IGW route?
Can they create peering that bypasses TGW?

Dev can reach prod private IP.

All TGW attachments propagate to one shared route table.

separate TGW route tables per environment
explicit propagation
Network Access Analyzer policy
SCP guardrails for attachment creation

App calls prod-looking name but reaches nonprod/internal endpoint.

duplicate private hosted zone
wrong VPC association
resolver forwarding rule precedence surprise

central PHZ inventory
query logging
domain ownership model
review PHZ associations in IaC

Many workloads cannot call external APIs.

inspection appliance/NAT path failure
route table blackhole
AZ-local path not preserved

multi-AZ inspection
per-AZ TGW attachment subnet design
health-based appliance routing if applicable
break-glass local egress plan for critical workloads

Two accounts communicate outside approved TGW path.

manual VPC peering created by application admin

SCP deny ec2:CreateVpcPeeringConnection except platform role
AWS Config rule / inventory
CloudTrail alert
route table drift detection

New business unit cannot connect to core network.

both sides use 10.0.0.0/16 or broad overlapping RFC1918 ranges

IPAM
NAT translation design
PrivateLink service-level exposure
long-term renumbering plan

ec2:CreateVpcPeeringConnection
ec2:AcceptVpcPeeringConnection
ec2:CreateTransitGatewayVpcAttachment
ec2:CreateInternetGateway
ec2:AttachInternetGateway
ec2:CreateNatGateway
ec2:CreateRoute
ec2:ReplaceRoute
ec2:AssociateRouteTable
route53:CreateHostedZone
route53resolver:CreateResolverRule
ram:CreateResourceShare

VPC Flow Logs
Route 53 Resolver query logs where relevant
ELB/ALB/NLB access logs where relevant
CloudFront logs for public edge
WAF logs for protected web entrypoints
Network Firewall logs for inspection paths
CloudTrail and Config

environment: prod | nonprod | sandbox
owner: team/platform
business_service: name
network_domain: prod-core | shared | inspection | sandbox
data_classification: public | internal | confidential | restricted
connectivity_approved_by: person/team
created_by_pipeline: true

route table route changed outside pipeline
new peering created
new IGW route added
new resolver forwarding rule created
new public subnet created
new wildcard SG ingress added
NACL changed
new endpoint policy changed to allow all

Which accounts exist and why?
Who owns network account?
Who owns DNS?
Who owns shared services?
Who approves connectivity changes?
Who can break-glass during incident?

Are VPC CIDRs non-overlapping?
Are future regions reserved?
Are subnet classes sized for growth?
Are route domains documented?
Are prod/nonprod/sandbox separated by route, not name?

Which VPCs can talk to which VPCs?
Is connectivity network-wide or service-specific?
Is PrivateLink better than routing?
Is TGW/Cloud WAN justified?
Is VPC Peering becoming a mesh?

Where does public traffic enter?
Is WAF/CloudFront/GA/ALB required?
Where does internet egress happen?
Is egress inspected?
Are AWS service calls using endpoints?

Where are public hosted zones?
Where are private hosted zones?
How are VPC associations controlled?
How does on-prem DNS interact?
Are resolver query logs enabled?

What SCP prevents bypass?
What IAM role can mutate routes?
Are endpoint policies least privilege?
Are SG/NACL baselines defined?
Are firewall policies central or local?

Can we prove packet path?
Where are Flow Logs stored?
Can security query logs across accounts?
Is there a runbook for reachability failure?
Is cost attribution available?

1. Define account taxonomy and OUs.
2. Define IPAM pool hierarchy.
3. Define network account and DNS/shared-services accounts.
4. Create VPC module standard.
5. Create logging baseline.
6. Create central route domains.
7. Create egress/ingress baseline.
8. Create resolver baseline.
9. Add workload VPC attachment workflow.
10. Add connectivity request workflow.
11. Add drift detection and policy guardrails.
12. Add periodic reachability review.

network_contract_version: 1
account:
  id: "123456789012"
  name: prod-payments
  environment: prod
  owner: payments-platform
vpc:
  cidr_source: ipam
  region: ap-southeast-1
  subnet_classes:
    - private-app
    - private-data
    - endpoint
connectivity:
  route_domain: prod-core
  allowed_destinations:
    - shared-services:443
    - inspection-egress:0.0.0.0/0
  denied_destinations:
    - nonprod-core
    - sandbox
internet:
  ingress: none
  egress: centralized-inspected
dns:
  private_zones:
    - corp.example.com
  resolver_rules:
    - onprem.corp
observability:
  flow_logs: required
  resolver_query_logs: required
  logs_destination: log-archive
change_control:
  route_changes: platform-pipeline-only
  peering: denied
  tgw_attachment: platform-approved

A new workload account can be created without inventing networking from scratch.
CIDR allocation is automated and non-overlapping.
Every connectivity path has owner, purpose, and review cycle.
Prod/non-prod/sandbox are segmented by route domain and policy.
Public ingress is narrow and protected.
Internet egress is known and measurable.
DNS ownership is explicit.
Shared services expose contracts, not tribal routes.
Bypass mechanisms are blocked or alerted.
Packet path can be proven from logs and analyzers.
Cost is attributable to account/service/path.
Incident containment can remove routes or attachments safely.

Account boundary is administrative, not automatically network-isolating.
Route domains are the real segmentation primitive.
DNS is part of the network control plane.
Shared services require contracts.
Centralization improves governance but can create bottlenecks.
Decentralization improves autonomy but can create drift.
The right model is usually federated: central guardrails, local workload ownership.