- Draw the request path.
- Identify internal endpoints.
- List the machines that need to communicate.
Start with the boundaries
Expose the public reverse proxy or application edge. Bind databases and management listeners to their intended interfaces. Require authentication even on internal paths; a private address is not an identity.
Separate development, production and recovery so a test configuration cannot silently open a production service.
Encrypt sensitive paths
Use authenticated encryption across public networks or regions. For a private gateway, keep keys on the participating machines and define only the routes the application needs.
Review the tunnel and host firewall together. A working tunnel does not automatically restrict the listener behind it.
Keep chatty components close
Place an application and database in the same region as a straightforward starting point. A query round trip can happen many times per user request. A high-capacity port does not remove distance from that conversation.
Use another region for recovery when you have a data-copy and failure plan that matches the application.
Include DNS in the plan
Use stable service names and document how they resolve in each environment. Check what happens when records expire, hosts restart or addresses change. A spare machine alone is not a complete failover path.
Keep internal names out of public records unless you intend them to be discoverable.
Test failure too
In a controlled window, stop one component and observe retries, timeouts and queue growth. Restore it and check that the system recovers without duplicated work. Write the expected behaviour into the runbook.