Secure cloud architecture: a practical blueprint

Build the organisation before the workload

Use separate accounts, subscriptions or projects for production, non-production, security logging and shared services. Central policy should stop dangerous configurations while preserving team autonomy inside approved boundaries.

Federate workforce identity from a managed identity provider. Avoid permanent cloud users and shared administrator accounts. Emergency access should be rare, monitored and tested.

• Separate production from development
• Centralise identity and strong authentication
• Apply organisation-level policy guardrails
• Keep security logs in a protected account

Design network and service boundaries

Prefer private service access and explicit ingress paths. Public exposure should be an owned decision with web or API protection, certificate management, rate limits and logging.

Cloud networks still need segmentation, but identity and service policy matter as much as addresses. Restrict east-west communication to documented application flows and control egress so compromised workloads cannot freely reach the internet.

• Dedicated ingress and egress controls
• Private endpoints for managed services
• Workload identity for service-to-service calls
• Documented, tested network flows

Protect data through its lifecycle

Classify data before selecting storage. Define encryption, key ownership, backup, retention, deletion and cross-region rules. Access should follow the application or workload identity, not broad network membership.

Separate duties around key management and recovery. A backup that uses the same identities and account boundary as production can fail with production.

• Least-privilege data access
• Customer-managed keys where the risk requires them
• Immutable or isolated recovery copies
• Verified deletion and retention

Make operations part of architecture

Send identity, control-plane, network, workload, data-access and security-service logs to a central, protected pipeline. Define who responds before alerts are enabled.

Resilience choices should follow business recovery objectives. Test restoration, account compromise and loss of a region or critical service. The cloud provider runs the cloud; the customer still owns its configuration, identities, data and application risk.

• Asset and owner inventory
• Configuration and vulnerability monitoring
• Incident playbooks with cloud access
• Regular recovery exercises

A practical 30-day field plan

Week one — Foundation. Organisation, accounts, identity and policy. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.

Week two — Platform. Networks, keys, logging and shared services. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.

Week three — Workloads. Application, data and runtime controls. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.

Week four — Operations. Detection, response, recovery and improvement. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.

Evidence worth keeping

Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.

• Separate production from development — owner, current state, last validation and any open exception
• Dedicated ingress and egress controls — owner, current state, last validation and any open exception
• Least-privilege data access — owner, current state, last validation and any open exception
• Asset and owner inventory — owner, current state, last validation and any open exception
• Decision log showing who approved residual risk and when it will be reviewed
• Test or exercise result with the actual outcome, not only a pass label

Questions for the leadership review

Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.

• Who is accountable for the cloud architecture outcome when teams disagree about delivery and risk?
• Which critical service or customer promise would be affected by a failure in this area?
• What evidence would tell us the design is working in production today?
• Which exception creates the largest concentration of access, dependency or recovery risk?
• What would the team contain first, and how would it restore a trustworthy service?
• Which improvement can be completed in the next 30 days without waiting for a large programme?