Networking and Connectivity

Networking decisions shape security, reliability, and developer experience. Keep the network model understandable before adding service mesh, private endpoints, or multi-region complexity.

Network baseline

Every platform should define:

• Account or subscription boundaries.
• VPC, VNet, subnet, and routing standards.
• Public, private, and restricted ingress patterns.
• Egress controls and allowed outbound dependencies.
• DNS ownership, certificate issuance, and renewal flows.
• Connectivity to data stores, SaaS systems, and partner networks.
• Logging for firewall, load balancer, gateway, and DNS events.

Ingress

Use a small number of approved ingress patterns.

• Prefer managed load balancers and gateways unless requirements demand custom control.
• Terminate TLS at a documented layer and automate certificate renewal.
• Put authentication, authorization, WAF, and rate limiting at explicit boundaries.
• Keep internal and external routes visually distinguishable.

Egress

Uncontrolled egress creates security and audit blind spots.

• Route production egress through known paths.
• Log and alert on unusual destinations or volume.
• Use private endpoints for sensitive managed services where practical.
• Document third-party dependencies and failure behavior.

Service mesh

A service mesh is useful for complex service-to-service traffic, but it is not a default requirement.

Adopt mesh only when the team needs several of:

• Mutual TLS between services.
• Consistent retries, timeouts, and traffic splitting.
• Deep service-to-service telemetry.
• Policy enforcement at workload boundaries.

Avoid mesh when the primary problem is missing ownership, weak observability, or inconsistent deployment practices. Mesh does not fix those by itself.