Cloud connectivity readiness: ten questions to answer before design begins

Teams often begin connectivity design by choosing a circuit, gateway or VPN. That is usually too early. The useful starting point is a shared description of what must communicate, under which conditions, with which risk tolerance and under whose control.

1. What is actually in scope?

List the applications, environments, locations, cloud regions, partner services and user populations that the project must connect. Distinguish the launch scope from later phases. A vague requirement such as “connect the data centre to cloud” hides the number of networks, trust zones, owners and dependencies involved.

Evidence to collect: application inventory, environment list, current topology, project phases and accountable stakeholders.

2. Which traffic flows are required?

Document source, destination, protocol, port, expected direction, business purpose and security owner for important flows. Include management, monitoring, DNS, identity, backup and update traffic—not only the primary application path.

A flow matrix helps prevent two common outcomes: over-permissive connectivity “for convenience” and late firewall changes discovered during cutover.

3. What availability outcome is required?

Clarify whether the service can tolerate minutes, hours or a full business day of connectivity loss. Then identify the components that must be redundant: customer edge, carrier, physical path, cloud attachment, gateway, region, firewall, DNS and operational support.

Two logical connections do not automatically provide resilience when they share a carrier, facility, router, conduit or approval process.

4. Is the IP addressing plan compatible?

Check for overlapping address space, growth capacity, summarisation boundaries, partner constraints and addresses already committed to other clouds. Address translation can solve specific conflicts, but it also adds operational and troubleshooting complexity.

The addressing plan should support the intended routing and segmentation model rather than being treated as an isolated spreadsheet.

5. Who controls routing—and how will paths change?

Define where routes are originated, filtered, summarised and preferred. For dynamic routing, record the intended BGP policy, failover behaviour and responsibility for each side. For static routing, identify who must update routes as networks grow.

Test not only the normal path but also maintenance and failure conditions. A backup link that never attracts traffic—or attracts it asymmetrically through a stateful firewall—is not an effective backup.

6. Where are the trust boundaries and inspection points?

Identify which traffic is inspected, where policy is enforced and which team owns each control. Confirm whether traffic must pass through central firewalls, cloud-native controls, service endpoints or third-party security platforms.

The network design should show the security path clearly enough that reviewers can verify it without reconstructing the architecture from multiple documents.

7. How will names resolve across environments?

DNS is a connectivity dependency. Determine which namespaces exist, which resolvers are authoritative, how queries cross environments, what happens during failover and whether split-horizon behaviour is required.

Include DNS in testing and rollback planning. A path can be reachable by IP while the application remains unavailable because names resolve incorrectly or depend on an inaccessible resolver.

8. What are the performance and capacity assumptions?

Estimate steady-state and peak throughput, latency sensitivity, packet-size considerations, encryption overhead and growth. Compare the requirement with the end-to-end path, not only the advertised capacity of one service.

Backups, replication, data migration and patching can create short periods of demand that are far above normal application traffic.

9. How will the change be introduced and reversed?

Map prerequisites, lead times, configuration sequence, validation steps, decision points and rollback criteria. Assign an owner to every action that crosses a customer, carrier, cloud provider, firewall team or application team.

A useful cutover plan describes what evidence confirms success—not merely that each configuration command was entered.

10. Who will operate and troubleshoot the design?

Define monitoring, logs, alerts, support boundaries, escalation paths, access requirements and runbooks. Record which team owns carrier tickets, cloud routing, firewalls, DNS and application validation.

Architecture is complete only when the receiving team can understand expected behaviour, detect deviation and coordinate recovery.

Use readiness to reduce redesign

These questions do not replace detailed design. They create the stable input that makes detailed design defensible. When answers remain unknown, mark them as decisions or risks with an owner and due date rather than allowing assumptions to disappear inside a diagram.