Centralised AWS networking: what belongs in the network account?

bfstore has a dedicated AWS account called:

bfstore-network

The name appears straightforward.

Then almost every resource involved in communication begins making a case for residence there: load balancers, VPC endpoints, Route 53 zones, security groups and even EKS clusters.

By that reasoning, the network account becomes the reluctant landlord of half the AWS estate.

That is centralisation by vocabulary rather than responsibility.

The network account should not own every resource involved in communication.

It should own the shared connectivity capabilities through which independently operated accounts obtain addresses, exchange routes, reach common destinations and cross external network boundaries.

AWS guidance recommends a dedicated networking account for shared services such as Transit Gateway and Amazon VPC IP Address Manager. It also presents centralised egress and decentralised ingress as a useful multi-account pattern.

For bfstore, the opening boundary is:

NETWORK ACCOUNT

Owns network capabilities
shared by several accounts.


WORKLOAD ACCOUNT

Owns network resources
whose lifecycle follows one workload.

The network account should own the roads shared by several properties. It should not own every front door, driveway and room merely because people travel through them.

The central ownership boundary

The network account owns the shared connectivity control plane: address allocation, transit relationships, common egress, inspection, DNS distribution, external connectivity and resource sharing.

It may also operate shared data-plane services such as Transit Gateway, NAT gateways, Network Firewall, Resolver endpoints and VPN attachments.

Workload-specific data planes remain with the workloads:

workload VPCs;
application subnets;
local route tables;
internet-facing and internal load balancers;
application security groups;
Kubernetes network interfaces;
database network interfaces;
workload-specific VPC endpoints.

                         bfstore-network
                                │
        ┌───────────────────────┼───────────────────────┐
        │                       │                       │
        ▼                       ▼                       ▼
 ADDRESS AUTHORITY        TRANSIT AUTHORITY       SHARED DNS
        │                       │                       │
        ▼                       ▼                       ▼
       IPAM              TRANSIT GATEWAY        PROFILES / RULES
        │                       │                       │
        └───────────────────────┼───────────────────────┘
                                ▼
                    SHARED EGRESS AND INSPECTION
                                │
               ┌────────────────┼────────────────┐
               │                │                │
               ▼                ▼                ▼
          bfstore-dev     bfstore-staging    bfstore-prod
               │                │                │
               ▼                ▼                ▼
        WORKLOAD VPC       WORKLOAD VPC       WORKLOAD VPC

The network account sets the shared rules of movement.

The workload accounts retain ownership of the workloads being moved.

Address authority belongs centrally

The first capability I would place in bfstore-network is Amazon VPC IP Address Manager.

bfstore’s address plan must cover every environment, shared platform, future AWS Region and external cloud or network.

If each account chooses its own CIDRs independently, overlapping address space eventually becomes a connectivity constraint.

Transit Gateway does not make overlapping networks conveniently transitive.

Direct private connectivity between overlapping ranges requires redesign, translation or deliberate isolation.

AWS supports delegating IPAM administration to an AWS Organizations member account, allowing the management account to avoid everyday IPAM administration.

For bfstore:

AWS ORGANIZATIONS MANAGEMENT ACCOUNT
              │
              │ delegates IPAM administration
              ▼
       bfstore-network
              │
              ▼
             IPAM

IPAM can be bfstore’s central AWS allocation authority.

It can allocate and monitor AWS CIDRs, while externally owned ranges are recorded as reservations in the broader address plan.

BFSTORE ADDRESS PLAN
        │
        ▼
AMAZON VPC IPAM
│
├── allocates and monitors AWS CIDRs
├── reserves planned Azure ranges
├── reserves planned GCP ranges
└── records external network space


AZURE AND GCP

enforce their allocations
through their own provider controls

Amazon VPC IPAM does not automatically discover or enforce Azure and GCP allocations in the same way it integrates with AWS Organizations resources.

The AWS pools might begin with:

bfstore
│
├── eu-west-2
│   ├── infrastructure
│   │   ├── network
│   │   ├── shared-services
│   │   ├── observability
│   │   └── backup
│   │
│   ├── workloads
│   │   ├── development
│   │   ├── staging
│   │   └── production
│   │
│   ├── sandbox
│   └── policy-test
│
└── future-regions

The network account owns IPAM, pools, allocation rules, sharing, compliance, overlap detection and external reservations.

The workload account owns the VPC created from the allocation, its subnet design and the resources consuming those addresses.

NETWORK ACCOUNT

You may allocate a /20
from the production pool.

WORKLOAD ACCOUNT

This /20 becomes the production VPC.

Its subnets follow
the workload's availability needs.

Address governance belongs centrally.

Every subnet decision does not.

Transit authority belongs centrally

AWS Transit Gateway is a Regional routing hub for VPC, VPN, Direct Connect and other supported attachments.

bfstore should create it in bfstore-network and share it with participating accounts through AWS RAM.

The network account owns the Transit Gateway, its route tables, attachment acceptance, associations, propagation, static and blackhole routes, peering, VPN attachments and network-function integration.

When bfstore-network shares the Transit Gateway, a workload account creates the VPC attachment for the VPC it owns and selects one attachment subnet in each required Availability Zone.

The network account accepts the attachment where required and controls its Transit Gateway route-table association, propagation and transit routes.

bfstore-network

Transit Gateway
Transit Gateway route tables
route segmentation
attachment governance


bfstore-prod

production VPC
VPC attachment request
attachment subnets
local route tables
security groups

The Transit Gateway route tables express communication policy.

PRODUCTION TRANSIT ROUTE TABLE

may reach:
    shared services
    observability
    backup
    central egress

must not reach:
    development
    sandbox
    policy-test


NON-PRODUCTION TRANSIT ROUTE TABLE

may reach:
    shared services
    non-production observability
    central egress

must not reach:
    production

I would disable automatic default route-table association and propagation, then associate and propagate attachments explicitly.

ATTACHMENT ASSOCIATION

Which Transit Gateway route table
governs traffic arriving here?


ROUTE PROPAGATION

Which attachment destinations
may appear in this route table?

Those decisions affect relationships between accounts, so they belong centrally.

The workload team still owns the local VPC routes directing selected destinations towards Transit Gateway.

Workload-local networking stays with the workload

Production, development and observability VPCs should live in their respective workload or platform accounts.

Those accounts own VPC lifecycle, subnets, local routes, internet gateways, security groups, network ACLs, endpoint associations, Flow Logs, local DNS associations and connectivity tests.

The network account supplies address allocation, shared transit, common routing policy, egress, DNS configuration and external connectivity.

WORKLOAD VPC

belongs with the workload
because its topology is part
of the workload architecture.


TRANSIT NETWORK

belongs centrally
because it determines how
several VPCs interact.

AWS also supports VPC sharing, which can suit organisations requiring tight central control over topology.

It is not my preferred starting point for bfstore because separate VPC ownership makes teardown, infrastructure state, responsibility and isolation clearer.

The network account should establish the network contract.

It should not deploy every application subnet for every team.

Shared egress should be deliberate

Private workloads still need controlled outbound access for activities such as:

operating-system updates;
package repositories;
payment-provider APIs;
shipping-provider APIs;
public identity endpoints;
selected SaaS integrations;
public AWS service endpoints where no private endpoint is used.

A central egress design sends internet-bound traffic from spoke VPCs through Transit Gateway towards a network-account egress path.

That path may contain:

Transit Gateway attachment subnets;
inspection;
NAT gateways;
an internet gateway;
egress route tables;
network telemetry;
zonal failure-domain routing.

PRIVATE WORKLOAD
       │
       ▼
WORKLOAD VPC ROUTE TABLE
       │
       ▼
TRANSIT GATEWAY
       │
       ▼
INSPECTION
       │
       ▼
EGRESS VPC
       │
       ▼
NAT GATEWAY
       │
       ▼
INTERNET GATEWAY

The network account should own the shared route, NAT, internet gateway, inspection integration, availability design and network-level telemetry.

The workload account still owns:

whether a subnet uses that route;
application security groups;
application-level destination controls;
credentials;
timeout and retry behaviour.

Central egress answers:

Which shared path carries
internet-bound traffic?

It does not answer:

Is the order service authorised
to call this payment operation?

Central egress can provide:

shared inspection;
fewer NAT gateways;
stable public source addresses;
common network policy;
central flow visibility.

It also introduces:

Transit Gateway processing charges;
concentrated traffic;
central failure modes;
route complexity;
possible cross-Availability-Zone cost;
dependence on network-account changes.

The correct decision tree is:

OUTBOUND REQUIREMENT
        │
        ▼
CAN IT USE A PRIVATE SERVICE ENDPOINT?
        │
     ┌──┴──┐
     │     │
    YES    NO
     │     │
     ▼     ▼
 ENDPOINT  DOES IT NEED CONTROLLED
           INTERNET EGRESS?
                │
             ┌──┴──┐
             │     │
            YES    NO
             │     │
             ▼     ▼
       CENTRAL OR LOCAL   NO ROUTE
         EGRESS PATH

Gateway endpoints for Amazon S3 and DynamoDB are VPC-local.

They are associated with route tables in the consuming VPC and cannot be used from another VPC through Transit Gateway, VPC peering, VPN or Direct Connect.

They therefore belong in each consuming workload VPC.

Interface endpoints can be local or shared, depending on cost, DNS, availability and failure-boundary requirements.

A local NAT gateway may still be appropriate where workload independence, latency or cost analysis favours it.

The network account should provide a shared egress capability.

It should not force every byte through it when a simpler private or local path is better.

Inspection belongs in the shared transit architecture

Central inspection is part of the shared routing architecture.

Its account ownership should follow the organisation’s operational and security-policy model.

bfstore has a separate account called:

bfstore-security-tooling

That creates two reasonable ownership arrangements.

NETWORK ACCOUNT

owns routing integration
and shared transit behaviour


SECURITY TOOLING

owns policy objectives,
standards and exceptions

The firewall resource itself may live in either account, provided the Transit Gateway and firewall attachment workflow supports the chosen boundary and operational responsibilities are explicit.

AWS now provides two principal Network Firewall integration models.

Inspection VPC

The traditional design deploys Network Firewall endpoints inside a dedicated VPC.

SPOKE VPC
    │
    ▼
TRANSIT GATEWAY
    │
    ▼
INSPECTION VPC
    │
    ▼
NETWORK FIREWALL ENDPOINTS
    │
    ▼
TRANSIT GATEWAY
    │
    ▼
EGRESS OR DESTINATION

This is useful when bfstore needs:

detailed control over VPC subnet routing;
additional network appliances;
Gateway Load Balancer integration;
an established inspection-VPC model.

The Transit Gateway VPC attachment must use appliance mode so forward and return flows remain on a consistent Availability Zone path.

Transit Gateway network-function attachment

Transit Gateway can connect directly to AWS Network Firewall through a network-function attachment.

SPOKE VPC
    │
    ▼
TRANSIT GATEWAY
    │
    ▼
NETWORK FUNCTION ATTACHMENT
    │
    ▼
AWS NETWORK FIREWALL
    │
    ▼
TRANSIT GATEWAY DESTINATION

This removes the need to create and operate an inspection VPC.

It reduces subnet and VPC route-table components and keeps traffic steering in Transit Gateway route tables.

Appliance mode is handled by the attachment model.

A firewall attachment created from another account can require acceptance by the Transit Gateway owner, allowing the security account to operate the firewall while the network account retains transit authority.

The bfstore decision should compare:

account ownership;
route complexity;
appliance requirements;
change workflow;
failure-domain design;
operational skills;
support for future third-party appliances.

The inventory should therefore describe an inspection capability, not assume that an inspection VPC must exist.

For policy rollout:

begin Route 53 DNS Firewall rules with the ALERT action;
for Network Firewall, begin with non-blocking or alert-producing rules appropriate to the selected rule type and policy;
enable logging;
characterise legitimate traffic;
introduce drop or reject actions deliberately.

Network Firewall does not have one universal firewall-wide alert mode.

Shared name resolution and private service access

DNS is partly central and partly distributed.

The network account should own common resolution behaviour.

Workload and platform accounts should own names whose lifecycle follows their services.

Common DNS configuration

When required, the network account should own Resolver endpoints, shared rules, DNS Firewall groups, Route 53 Profiles, common query logging, hybrid integration and genuinely shared zones.

A Route 53 Profile can distribute:

private hosted zones;
Resolver forwarding and system rules;
DNS Firewall rule groups;
Resolver query logging;
selected VPC DNS settings;
interface VPC endpoint DNS associations.

Profiles can be shared through AWS RAM and associated with VPCs in other accounts.

bfstore-network

Route 53 Profile
│
├── common Resolver rules
├── DNS Firewall rule groups
├── query logging
├── shared private zones
└── selected endpoint DNS
        │
        ▼
shared with workload accounts

Only one Route 53 Profile can be associated with a VPC.

That makes Profile composition and ownership important.

Locally configured DNS resources can also take precedence when they conflict with Profile-provided configuration.

The network team therefore cannot treat Profiles as several independent policy layers that every central team attaches separately.

bfstore needs one coherent Profile design per VPC population.

Namespace ownership remains distributed

Workload and platform accounts may own service-specific zones, environment aliases, platform discovery, application records and local associations.

For bfstore:

NETWORK ACCOUNT

network.aws.internal.bfstore.example
shared forwarding rules
future hybrid DNS


SHARED-SERVICES ACCOUNT

platform.aws.internal.bfstore.example
Backstage
TerraKube
module registry


OBSERVABILITY ACCOUNT

observability.aws.internal.bfstore.example
telemetry ingestion
query endpoints


WORKLOAD ACCOUNTS

service and environment names
owned entirely by those workloads

Central DNS should provide a coherent namespace.

It should not turn a record for orders into a cross-team planning summit.

Resolver endpoints exist only for resolver boundaries

Resolver endpoints belong centrally when another DNS environment exists.

An inbound endpoint lets another resolver ask Route 53 VPC Resolver for AWS-private answers.

An outbound endpoint lets Route 53 Resolver forward selected namespaces to another authority.

They are useful for:

on-premises DNS;
future Azure DNS;
future GCP DNS;
private partner or identity services;
bidirectional hybrid resolution.

Today, bfstore has no on-premises network and no active private connection to Azure or GCP.

network_account_dns:
  inbound_resolver_endpoints: []
  outbound_resolver_endpoints: []
  hybrid_forwarding_rules: []

The network account owns the future capability.

That does not mean it should deploy idle endpoints before another resolver boundary exists.

A central account should contain shared infrastructure with a job.

Not a museum of things bfstore may one day need.

Interface endpoints require an ownership test

Interface VPC endpoints can be deployed in each consuming VPC or centralised in a shared VPC reachable through Transit Gateway.

A consumer-owned endpoint is usually better for one workload, natural private DNS, low latency and independent failure behaviour.

A shared endpoint may be worthwhile when many VPCs consume the service, endpoint-hour cost is material, Transit Gateway already exists, and the DNS, policy and shared failure boundary are acceptable.

WHO CONSUMES THE ENDPOINT?
        │
   ┌────┴────┐
   │         │
ONE VPC    MANY VPCs
   │         │
   ▼         ▼
LOCAL      EVALUATE CENTRAL
ENDPOINT   SHARED ENDPOINT

Historically, central interface-endpoint designs often required custom private hosted zones and Resolver configuration because the endpoint’s managed private DNS applied within the endpoint VPC.

Route 53 Profiles can now distribute selected interface endpoint DNS associations to Profile-associated VPCs.

That can reduce custom private-zone work, but it does not remove routing, security-group, endpoint-policy, zonal availability, failure-boundary, capacity or cost requirements.

A PrivateLink endpoint service normally belongs with the provider service, not the network account.

bfstore-observability

owns:
    observability endpoint service
    provider load balancer
    telemetry application


bfstore-prod

owns:
    consumer interface endpoint
    endpoint security group


bfstore-network

owns:
    shared routing and naming standards

The network account enables connectivity.

It does not become the owner of every privately consumed service.

Public ingress stays with the workload

Customer traffic enters through workload-specific application infrastructure.

For production, that may include:

Amazon CloudFront;
AWS WAF;
an internet-facing ALB;
Envoy Gateway;
EKS workloads;
application certificates;
host and path routing.

INTERNET
    │
    ▼
PRODUCTION INGRESS
inside bfstore-prod
    │
    ▼
PRODUCTION APPLICATION

The production account owns its load balancers, target groups, certificates, ingress routes, WAF association, DNS intent and customer-facing availability.

Security tooling may own organisation-wide WAF and Shield policy. The network account retains shared address planning, private external connectivity and any common inspection architecture.

It should not own the production ALB merely because an ALB is a network service.

That resource’s lifecycle is coupled to the production application.

AWS RAM is one of the network account’s quiet workhorses.

bfstore may use it to share:

Transit Gateway;
IPAM pools;
Route 53 Profiles;
Resolver rules;
DNS Firewall rule groups;
selected prefix lists;
other supported shared network resources.

Sharing and unsharing semantics are resource-specific. A Transit Gateway attachment, for example, can remain functional after the gateway is unshared even though the participant loses visibility of the gateway.

Every share therefore needs an owner, approved consumers, infrastructure-code evidence, a removal runbook, a tested impact model and rollback.

resource_share:
  name: bfstore-transit-gateway

  resource:
    type: ec2:TransitGateway
    owner: bfstore-network

  principals:
    - bfstore-dev
    - bfstore-staging
    - bfstore-prod
    - bfstore-shared-services
    - bfstore-observability

  change_repository: bfstore-network-infrastructure
  removal_runbook: transit-gateway-share-removal

Hybrid connectivity also belongs in the shared architecture when a real external network exists.

The network account is the natural owner of:

Site-to-Site VPN;
customer gateways;
Transit Gateway VPN attachments;
hybrid routing policy;
advertised and accepted prefixes;
connection monitoring;
redundant paths.

A Site-to-Site VPN attachment must be created in the account that owns the Transit Gateway.

Direct Connect can involve a more distributed ownership model.

A Direct Connect gateway can be associated with a Transit Gateway in another account through an association proposal.

The Transit Gateway owner proposes the association, while the Direct Connect gateway owner accepts it and can control or override the allowed prefixes.

That is a useful reminder:

CENTRAL NETWORK AUTHORITY

does not always mean

ONE ACCOUNT OWNS
EVERY PROVIDER COMPONENT

bfstore currently has no on-premises data centre and no active Azure or GCP private network.

The circuit should not be created before the relationship exists.

Telemetry crosses the account boundary

The network account creates VPC and Transit Gateway Flow Logs, firewall logs, NAT and transit metrics, Resolver query logs, hybrid-connectivity metrics and CloudTrail change evidence.

The network account should own the configuration that emits these signals.

It should not necessarily store every signal locally.

`bfstore-log-archive`

Owns:

durable security evidence;
long-term network-flow archives;
organisation CloudTrail;
recovery copies;
tightly controlled retention.

Where bfstore requires immutability, the archive design must provide it explicitly through controls such as:

S3 versioning;
S3 Object Lock;
a defined governance or compliance retention mode;
restricted retention administration;
KMS key controls;
CloudTrail log-file integrity validation;
replication where required.

CloudTrail integrity validation can detect modification or deletion.

It does not prevent either action.

S3 Object Lock compliance mode prevents protected object versions from being overwritten or deleted during their retention period, including by the account root user.

`bfstore-observability`

Owns:

searchable network telemetry;
dashboards;
route and firewall alerts;
flow analysis;
DNS investigations;
operational correlations.

NETWORK ACCOUNT
      │
      ├── emits network telemetry
      │
      ├────────────► LOG ARCHIVE
      │                durable evidence
      │
      └────────────► OBSERVABILITY
                       operational analysis

A routing failure may need correlation with:

a workload deployment;
a DNS change;
a firewall-rule change;
an IAM session;
an application timeout;
an external-provider incident.

The network account supplies the source.

The observability and archive accounts provide the destinations appropriate to their responsibilities.

What does not belong in the network account

The following would not normally belong in bfstore-network.

Resource or capability	Normal owner
Application services	Workload or platform account
Workload databases	Account owning the service state
Public and internal application load balancers	Workload account
Application security groups	Workload team, within central policy
Kubernetes network policy	Cluster or workload platform
Service-specific DNS records	Service or platform owner
Application secrets and certificates	Application or security boundary
Customer-facing ingress	Workload account
Backstage, TerraKube, Kafka or observability backends	Their platform accounts
Organisation-wide security intent	Security tooling or governance

The network account may implement shared enforcement resources.

It should not become the vault for application credentials, the home of workload databases or a general shared-services cluster.

A network account full of platform applications becomes another shared-services account with unusually dangerous routing permissions.

The proposed bfstore inventory

Capability	Initial state	Network-account responsibility
Amazon VPC IPAM	Deploy	Delegated administration, pools, allocation policy and sharing
Transit Gateway	Deploy	Gateway, route tables, association, propagation and sharing
Network-services VPC	Deploy thinly	Host central DNS or selected endpoint capabilities
Central egress	Deploy when required	Shared routing, NAT, internet gateway and availability
Inspection capability	Phase later	Choose inspection VPC or network-function attachment
Shared private zones	Selective	Shared network namespaces only
Route 53 Profiles	Adopt as DNS estate grows	One coherent common DNS configuration per VPC population
Resolver endpoints	Do not deploy yet	Add for genuine hybrid or multi-cloud DNS
DNS Firewall	Begin with `ALERT` later	Central rule implementation, coordinated with security
Shared interface endpoints	Evaluate individually	Centralise only when economics and failure model justify it
Gateway endpoints	Deploy in consuming VPCs	Not centralisable through Transit Gateway
Site-to-Site VPN	None currently	Add when a real external network exists
Direct Connect	None currently	Add with explicit gateway and prefix ownership
Transit Gateway peering	None initially	Add for another AWS Region when required
Network telemetry	Deploy with each capability	Emit to archive and observability accounts
AWS RAM shares	Deploy	Share IPAM, Transit Gateway and later DNS resources
Network applications	Never	Keep ordinary applications out of this account

The physical VPC layout may evolve.

bfstore-network
│
├── IPAM
├── Transit Gateway
├── AWS RAM shares
│
├── network-services VPC
│   ├── future Resolver endpoints
│   └── selected shared endpoints
│
├── inspection capability
│   ├── inspection VPC
│   └── or TGW network-function attachment
│
└── egress VPC
    ├── NAT gateways
    ├── internet gateway
    └── shared egress routes

Combining functions initially may reduce cost.

Separating them later may improve clarity and blast-radius control.

Infrastructure code should preserve the roles even when the first implementation uses fewer physical VPCs.

Ownership follows the decision

One resource can involve several owners.

Decision	Network team	Workload team	Security team	Observability team
CIDR allocation	Owns pool and approval	Requests and consumes	Reviews policy exceptions	Monitors utilisation
VPC attachment	Accepts and routes	Creates attachment and subnets	Approves communication intent	Tests and alerts
Egress	Operates shared path	Chooses local routes and application controls	Defines policy	Monitors health and flow
Inspection	Integrates transit	Validates application impact	Owns standards and exceptions	Monitors enforcement
DNS	Distributes common configuration	Owns service records	Defines filtering policy	Monitors resolution
Recovery	Reconstructs shared network	Revalidates workloads	Reviews emergency access	Proves restored visibility

Central networking should centralise shared authority.

It should not centralise every task.

Otherwise the network team becomes the queue through which all application delivery must crawl.

The network account is a service

The network account operates production capabilities.

Its service indicators should cover:

Transit: attachment availability, route correctness, reachability, loss, latency and unintended blackholes.
Egress and inspection: connection success, NAT errors, zonal availability, firewall health and rejected flows.
DNS: endpoint health, latency, SERVFAIL, target timeouts, query-log freshness and unusual NXDOMAIN growth.
IPAM: pool utilisation, non-compliant allocations, overlaps, allocation failures and available capacity.
Recovery: time to reconstruct transit, firewall and DNS configuration from infrastructure code, including emergency-access validation.

A central network is shared infrastructure.

Shared infrastructure eventually becomes somebody’s outage unless it is operated as a service.

A staged implementation

Phase 1: Address governance

delegate IPAM administration to bfstore-network;
define AWS pools and external range reservations;
share approved pools;
allocate workload VPC ranges.

Phase 2: Thin network baseline

establish network-account roles;
enable CloudTrail and Config integration;
create telemetry destinations;
create the infrastructure repository;
define emergency access.

Phase 3: Transit routing

create Transit Gateway;
disable automatic default association and propagation;
create segmented route tables;
share the gateway through AWS RAM;
attach development and shared services first;
test allowed and forbidden reachability;
add staging and production deliberately.

Phase 4: Shared DNS governance

define internal namespace conventions;
determine central and distributed zone ownership;
enable Resolver query logging;
design one Route 53 Profile per VPC population where common configuration justifies it.

Phase 5: Central egress

create the egress path;
deploy zonal NAT;
route selected non-production traffic first;
measure cost and failure behaviour;
add production after testing.

Phase 6: Inspection

compare an inspection VPC with a Transit Gateway network-function attachment;
establish policy ownership;
begin DNS Firewall with ALERT;
begin Network Firewall with suitable non-blocking or alert-producing rules;
enable logging;
move to blocking only after legitimate traffic is understood.

Phase 7: External connectivity

Add Resolver endpoints, VPN, Direct Connect or multi-cloud transit only when an actual external environment needs the path.

The network account should grow in response to connectivity relationships.

Not in anticipation of every icon in the AWS console.

The mental model I am keeping

My earlier model was:

NETWORK ACCOUNT

contains AWS networking resources

The stronger model is:

                       AWS ORGANISATION
                              │
                              ▼
                        bfstore-network
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
       ▼                      ▼                      ▼
  ADDRESS AUTHORITY      ROUTING AUTHORITY       COMMON DNS
       │                      │                      │
       ▼                      ▼                      ▼
      IPAM              TRANSIT GATEWAY       PROFILES / RULES
       │                      │                      │
       └──────────────────────┼──────────────────────┘
                              ▼
                  SHARED EGRESS AND INSPECTION
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
       ▼                      ▼                      ▼
      DEV                  STAGING                 PROD
       │                      │                      │
       ▼                      ▼                      ▼
  WORKLOAD VPC           WORKLOAD VPC          WORKLOAD VPC
       │                      │                      │
       ├── subnets            ├── subnets            ├── subnets
       ├── load balancers     ├── load balancers     ├── load balancers
       ├── security groups    ├── security groups    ├── security groups
       └── applications       └── applications       └── applications

IPAM answers which address space an account may consume.

Transit Gateway answers which attached networks may exchange routes.

Central egress and inspection answer which shared path traffic uses and which flows cross enforcement.

Route 53 Profiles answer which common DNS configuration a VPC population inherits.

Resolver endpoints answer how DNS crosses into another resolver environment.

AWS RAM answers how other accounts consume centrally owned capabilities.

The workload VPC answers:

How is this application environment
segmented and operated locally?

The workload ingress answers:

How does traffic reach
this particular application?

The security account answers:

Which organisation-wide network
behaviour should be prohibited?

The observability account answers:

How do we know the shared
network is still behaving?

And the network account answers:

Which shared connectivity decisions
must remain consistent across bfstore?

That is the account’s real job.

The network account should own the map, the shared junctions and the bridges between territories. The workload accounts should still own the buildings, their entrances and the locks on their doors.

For bfstore, bfstore-network will own IPAM, Transit Gateway, shared route policy, AWS RAM network shares and the eventual shared egress, inspection, hybrid connectivity and Resolver infrastructure.

It will not own the production EKS cluster.

It will not own the order database.

It will not own the customer-facing ALB.

It will not become a general shared-services cluster.

It will not host Backstage merely because Backstage has a hostname.

The account should remain narrow, resilient and slightly dull.

When every other account depends on the roads, the road authority should not also run a furniture shop from the central reservation.

References and further reading

Foundational infrastructure and the network account
Centralised egress
Decentralised ingress
Work with shared Transit Gateways
Amazon VPC attachments in Transit Gateway
Amazon VPC IPAM and AWS Organizations
Manual IPAM allocations for external reservations
AWS Transit Gateway network-function attachments
Transit Gateway attachment configuration for AWS Network Firewall
Accepting cross-account firewall attachments
Route 53 Profiles
Associating interface VPC endpoints with Route 53 Profiles Covers distributing selected interface endpoint DNS associations.
Centralised interface VPC endpoints Describes central endpoint patterns and their DNS implications.
Gateway endpoints for Amazon S3 Documents that gateway endpoints are VPC-local and cannot be consumed through Transit Gateway.
DNS Firewall rule actions Documents the ALERT, ALLOW and BLOCK actions.
Network Firewall rule actions Covers alerting and enforcement behaviour for different rule types.
Direct Connect gateways and Transit Gateway associations Covers cross-account association proposals and allowed prefixes.
S3 Object Lock Covers governance and compliance retention modes for WORM protection.