Map traffic paths before designing subnets
Start with flows, not network objects. Document how internet traffic reaches a public service, which internal APIs that service calls, which data stores those APIs use, and how engineers and deployment systems enter the environment. For every path, record the source, destination, protocol, port, authentication method, data sensitivity, and operational owner. This becomes the working specification for routes, firewall rules, workload identities, and monitoring.
A useful baseline separates the public entry tier, application and API tier, data tier, and management or shared-services tier. The entry tier contains components such as a CDN, web application firewall, load balancer, or API gateway. The application tier runs web backends, workers, and internal APIs. The data tier contains databases, caches, and messaging systems. Management services may include private DNS, logging collectors, deployment agents, VPN endpoints, and controlled administration hosts. These tiers should represent enforceable boundaries, with separate subnets, route tables, and security policies where appropriate.
- Deny by default: Permit known flows instead of trusting every address in a private range.
- Keep dependencies directional: A public-facing service may call a specific API, but the data tier should not initiate arbitrary connections to the public tier.
- Target workloads precisely: Prefer workload identities, security groups, or service tags over broad CIDR rules.
- Preserve evidence: Centralize flow logs, DNS activity, rejected connections, and policy changes.
Expose the entry point, not the entire application
A service that must be reachable by users does not necessarily need public IP addresses on its application instances. A stronger pattern is to terminate internet traffic at a CDN, WAF, load balancer, or API gateway, then forward approved requests to workloads in private subnets. The entry tier can centralize TLS certificates, basic rate limits, request-size controls, and common attack protections. Application workloads should accept traffic only from the designated entry components, reducing the number of endpoints that can be scanned or attacked directly.
Do not add every possible gateway product by default. An employee-only tool may need only an identity-aware proxy, while an API serving many external integrations often benefits from explicit versioning, quotas, OAuth policies, and consumer-specific credentials. Choose controls according to the threat model, latency requirements, cost, and the team's ability to operate them. A WAF does not replace application authorization, and a private subnet does not correct an overprivileged service account.
Outbound traffic deserves equal attention. If every private workload can reach any internet destination through a NAT gateway, a compromised service may download tools or exfiltrate data. Route cloud-provider services through private endpoints where practical, and define how workloads access package repositories, container registries, and approved third-party APIs. Strict egress filtering adds operational overhead, so many teams begin with databases and sensitive workloads, observe legitimate destinations, and expand enforcement deliberately.
Treat internal APIs and databases as separate boundaries
An API is not trusted merely because it has a private address. Service-to-service calls still need authenticated identities and authorization for sensitive operations. Workload identity, short-lived tokens, or mutual TLS are preferable to permanent credentials embedded in code or configuration. When the platform integrates with LINE, ERP, CRM, or IoT systems, route those connections through a controlled integration tier. That tier can validate payloads, translate protocols, apply rate limits, and publish only the specific internal operations each partner requires.
The database boundary should be narrower still. Databases should have no public address and should accept connections only from named application workloads or security groups. Administrative access should use a separate VPN, zero-trust access broker, or audited session service. Separate runtime read-write accounts from reporting, read-only, migration, and administrative identities. Deliver secrets through a managed secret store and rotate them without rebuilding the network. Backup, replication, monitoring, and maintenance flows must also be designed explicitly; they should not become reasons to permit an entire subnet.
As the service count grows, individual network rules can become difficult to reason about. A service mesh or centralized API layer can standardize encryption, identity, and policy, but it also introduces proxies, certificate lifecycles, resource overhead, and new failure modes. For a smaller estate, clear security groups combined with workload identity are often easier to operate. Centralized controls become more compelling when policies are being duplicated across clusters, cloud accounts, or independently managed teams.
Design for environments, operations, and continuous verification
Production, test, and development should have distinct account, project, or virtual-network boundaries rather than relying on subnet names alone. Development workloads should not gain direct access to production data for convenience. Use sanitized copies or controlled data exchange when representative data is required. Connections between cloud networks and an on-premises ERP should also be narrowly routed. Advertise only required address ranges, allow named services, and plan for overlapping CIDRs, private DNS resolution, and failover before establishing a VPN or dedicated circuit.
Administrative access is where otherwise sound segmentation is often bypassed. Avoid permanently open SSH and database administration ports. Prefer access methods with multi-factor authentication, short-lived authorization, device or identity checks, and recorded sessions. Emergency access should be attributable and expire automatically. Deployment platforms likewise need only the network paths and cloud permissions required to release software; convenience should not turn a CI system into a permanent administrator of every tier.
Finally, test that isolation actually works. Verify denied paths as well as successful ones: the public tier must not connect directly to the database, development must not read production, and ordinary workloads must not enter the management network. Manage routes, firewall rules, and security groups as code, review them with application changes, and regularly identify unused rules, unusual egress, and repeated denials. For systems spanning several clouds and enterprise platforms, a shared traffic matrix maintained by network, identity, and application engineers provides a durable source of truth and makes integration changes much safer.