I'm a network engineer with roughly 30 years of mostly Cisco and enterprise experience. I earned the Azure Solutions Architect certification a couple of years ago but never had the opportunity to use Azure professionally, so I've been building a fictional cloud post-production studio to get practical experience.
The entire environment is defined with Terraform, but I'm mainly looking for feedback on the architecture rather than the HCL. The current design includes:
- A hub-and-spoke topology, with Azure Firewall in the hub and forced egress from the spoke through UDRs.
- Private endpoints and Private DNS for Blob Storage, so media traffic stays off the public data path.
- NSG segmentation, with administrative access limited to Bastion and storage access restricted to the editing subnet.
- A cost-control approach where expensive components such as GPUs, Azure NetApp Files, Azure Firewall, and Application Gateway are feature-flagged and validated during plan only. The baseline design can therefore be reviewed at approximately $0 before anything costly is deployed.
- Monitoring through VNet flow logs, Log Analytics, Traffic Analytics, and an egress alert aimed at detecting potential content exfiltration.
I'd appreciate an honest architecture review, especially on these points:
1. Is hub-and-spoke with private endpoints reasonable for a single studio, or would a single VNet be more appropriate until a second spoke exists?
2. Are Azure Policy controls—such as denying expensive SKUs—more reliable than Terraform-only safeguards? What is the best way to prevent an accidental high monthly bill?
3. Is the combination of private endpoints, no public IPs, and controlled firewall egress sufficient for pre-release media, or should I add services and controls such as Defender for Storage, versioning, soft delete, or immutable storage?
4. Does plan-only validation meaningfully prove an expensive design at zero cost, or is it better to deploy the resources briefly, use what-if or dev/test pricing, and then destroy them?
I intentionally deferred firewall FQDN allow-listing, Application Gateway TLS, Azure NetApp Files snapshots, and disabling public network access on the storage account. I'd also like feedback on whether those priorities make sense, and on any issues involving private DNS resolution from on-premises networks.
3 Answers
For the cost side, combine multiple layers rather than trusting one control. Use Terraform validation to stop the expected workflow, Azure Policy to deny forbidden SKUs regardless of deployment path, and budgets or cost alerts to catch unexpected usage. Alerts are not hard spending caps, so also restrict who can create or resize costly resources and separate the experimental subscription from anything important.
The hub-and-spoke layout is reasonable even for one studio, since the topology itself costs nothing and retrofitting it later can be painful. Just make sure the implementation and documentation agree: if the diagram shows the firewall in the workload VNet while the description says it lives in a peered hub, that inconsistency will be noticed quickly. Also be prepared to explain how on-premises clients resolve private-endpoint DNS names; that is an important real-world detail.
Azure Policy is a stronger guardrail than a Terraform check because it also covers portal changes and ad hoc CLI deployments. Deny policies for costly SKUs can be applied at an appropriate management-group scope, while budgets are useful for alerts but do not stop deployments. Avoid relying on editable exclusion tags as a protection mechanism. Keep in mind that policy denial happens at apply time, so Terraform plan may not reveal it.
The storage security priorities should be adjusted. Disabling public network access is an ARM-level setting and does not require the Terraform runner to be inside the VNet; only direct blob or container operations from that runner would need network access. You can use default-deny network rules and temporarily allow the runner’s address if necessary. With the public front door still open, the private endpoint is not providing much protection. Also consider disabling shared-key authentication, because a leaked account key can bypass much of the network design, along with soft delete and versioning. Immutable storage is generally more appropriate for finalized assets than actively edited pre-release content.
Plan-only validation is useful for checking configuration and resource wiring, but it cannot prove quotas or successful provisioning. GPU quota is often unavailable by default in a new subscription. A short, controlled deployment followed by evidence collection and destruction provides stronger proof than a clean plan alone. The deferred Application Gateway TLS and NetApp snapshots are understandable, but FQDN egress controls and storage public-access restrictions deserve higher priority because an alert that fires after exfiltration is detection rather than prevention.
The plan-only approach is a good safety mechanism for early design work, but I would describe it accurately: it proves that Terraform can construct a dependency graph and generate a proposed deployment, not that Azure will successfully run the expensive tier. Quotas, regional availability, permissions, provider behavior, and service-specific limits still need validation. A small time-boxed deployment with monitoring screenshots and a confirmed destroy is a much stronger portfolio demonstration, provided spending limits and cleanup checks are in place.
This is exactly the kind of review I was hoping for. I’ll fix the hub-versus-spoke documentation, move storage public access and FQDN controls up the list, and look into quota testing.