Cloud Networking Design Brief
Plan a network layout with segmentation.
Added October 15, 2026. Written with AI assistance and checked for clarity and placeholders; not reviewed by a lawyer, accountant, clinician or other professional. How these prompts are made
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
[VERIFY] is an editorial flag, not a blank to fill. Wherever the prompt shows [VERIFY], check that item against a reliable source before you use it (what [VERIFY] means).
Design a cloud network layout. Cloud provider: [CLOUD_PROVIDER]. Workloads and tiers (web, app, data, admin): [WORKLOADS]. Regions and availability needs: [REGIONS]. Connectivity needs to offices or other clouds: [CONNECTIVITY]. Compliance constraints I know of: [COMPLIANCE]. Provide an address plan using non-overlapping private ranges with room for growth, a subnet table (name, purpose, range, public or private, route), security group or firewall rules in a matrix of source, destination, port and reason, and egress control. Explain choices for NAT, private endpoints and bastion alternatives. Include a failure analysis of what happens if a zone fails. List the information I should verify with my provider's documentation and mark compliance statements [VERIFY]. Do not include real credentials or internal IP data beyond placeholders. Include a short threat-model section listing five realistic network-level threats for my workloads and the control in your design that addresses each, with an honest note about residual risk. Add a validation plan: how to test that the firewall rules do what the matrix says, using connectivity tests that I can run from each tier, and a drawing of the layout in plain text. Add a worked address plan using invented ranges: one private block split into per-environment ranges, then per-tier subnets across three zones, showing the arithmetic for the number of usable addresses and the growth headroom as a percentage. Present a connectivity test matrix with the source tier, destination tier, port, expected result (allowed or blocked) and the command concept to test it, so the validation plan is concrete. Add an egress section listing which workloads may reach the internet, through which path, and with what logging. Finish with a change procedure for opening a new firewall rule: request, reviewer, expiry date, test, and removal, so that rules do not accumulate without owners. Close with a list of the six design decisions that are hardest to change later (address ranges, account boundaries, region choice, shared services placement, private endpoints, peering model) and my recorded choice for each.
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.