A cloud architecture review should do more than confirm that a diagram exists or that services are running. Its purpose is to understand whether the environment is secure, resilient, supportable and aligned with the organisation’s current and future needs.
That means looking beyond individual cloud resources and examining how the platform operates as a complete system.
Start with the current state
Before assessing whether an architecture is good, you need to understand what is actually deployed.
That includes cloud accounts or tenancies, regions, networks, identity structures, compute, databases, storage, integrations, security services, monitoring and automation.
Documentation is useful, but it should be validated against the live environment. Architecture diagrams often drift out of date as projects introduce new services, temporary routes or additional access.
DNC’s Cloud Architecture services include current-state discovery, architecture assessment and future-state design.
Identity and access management
Identity should be one of the first areas reviewed because access decisions affect almost every other cloud control.
Check how users authenticate, how administrators are separated from standard users, whether multi-factor authentication is enforced and how access is granted through groups, roles and policies.
Service accounts, application identities, API keys and automation credentials should also be reviewed. These non-human identities can hold significant privilege and are often overlooked.
The review should identify excessive permissions, unused accounts, direct user grants and credentials that are not being rotated or managed appropriately.
Network architecture and segmentation
Cloud networking should make it clear which systems can communicate, how traffic enters and leaves the environment and where trust boundaries exist.
Review virtual networks, subnets, routing, gateways, firewalls, security groups, private endpoints and connectivity to on-premises or third-party environments.
Public exposure should be deliberate. If a workload does not need direct internet access, the architecture should not provide it by default.
Network rules should also be understandable. Years of exceptions can create a design where nobody is confident about what can communicate with what.
Resilience and availability
A highly available service is not created simply by placing it in the cloud.
Review whether critical workloads are distributed appropriately across availability zones, fault domains or regions, depending on the cloud platform and business requirement.
Look for single points of failure in compute, databases, load balancing, DNS, storage and network connectivity.
The design should reflect the business impact of failure rather than applying the same resilience model to every workload.
Backup and disaster recovery
Backups are only one part of recovery.
A cloud architecture review should confirm what is backed up, how frequently, how long backups are retained and whether copies are isolated appropriately.
More importantly, the organisation should know how those backups are restored.
Recovery Time Objectives and Recovery Point Objectives should be connected to actual technical capabilities. If the business expects a service to return within two hours but the restore process takes twelve, the architecture does not meet the requirement.
Security controls
Security should be reviewed across the platform rather than treated as a single product or service.
Check encryption, key management, vulnerability management, configuration monitoring, threat detection, security posture management and controls around public exposure.
Cloud-native security services can provide strong visibility, but only when they are enabled, configured and monitored.
DNC’s Cyber Security services can support security reviews alongside wider cloud architecture assessments.
Logging, monitoring and alerting
A well-designed platform should provide enough information to understand both operational problems and security events.
Review which logs are collected, where they are stored, how long they are retained and who can access them.
Monitoring should cover more than CPU and memory. It should include service health, failed authentication, unusual privilege changes, backup failures, network events and other signals relevant to the environment.
Alerts should also be actionable. Hundreds of ignored alerts are not an effective monitoring strategy.
Compute, database and storage design
Review whether workloads are appropriately sized and whether the chosen services still match their requirements.
Instances may have been created larger than necessary, storage may have accumulated without lifecycle policies and databases may be running on designs that no longer reflect current usage.
This part of the review often identifies opportunities to improve both performance and cost.
Automation and Infrastructure as Code
Manual cloud administration increases inconsistency and makes environments harder to reproduce.
Review how infrastructure is created and changed. Where practical, repeatable infrastructure should be managed through Infrastructure as Code and controlled deployment processes.
The review should also consider how configuration is versioned, approved and recovered if an incorrect change is introduced.
Cost and resource governance
Cloud cost problems are frequently architecture problems in disguise.
Unused resources, oversized systems, duplicate services, excessive data transfer and poor storage lifecycle management can all increase spend.
Review tagging, budgets, cost allocation and ownership so that the organisation knows which services are consuming money and why.
Cost optimisation should not simply mean choosing the cheapest option. The goal is to ensure that cost is proportionate to the value, resilience and performance required.
Operational ownership
An architecture can be technically sound but operationally weak if nobody knows who owns each component.
Identify responsibilities across internal teams, managed service providers and software vendors.
The review should make clear who monitors the platform, who responds to incidents, who manages backups, who approves access and who is responsible for patching and lifecycle management.
DNC’s Corporate Architecture and Technology Services include current-state discovery and ownership mapping for complex environments.
Documentation and governance
Architecture documentation should help people make decisions, not simply exist for audit purposes.
Useful outputs include current-state diagrams, dependency views, security boundaries, ownership information, risks and design decisions.
Documentation should also have an owner and a process for keeping it current.
The review should produce priorities
A cloud architecture review should not finish with a long list of observations that all appear equally important.
Findings should be prioritised according to business impact, security exposure, resilience risk, operational effort and the organisation’s future plans.
Some issues may need immediate remediation. Others may be better addressed during an upgrade, migration or wider transformation programme.
What good looks like
A strong cloud environment has clear identity boundaries, controlled network paths, appropriate resilience, tested recovery, useful monitoring, repeatable deployment and documented ownership.
It does not have to be perfect. It does need to be understood.
The value of a cloud architecture review is therefore not simply finding problems. It is creating a reliable view of the environment and turning that understanding into a practical improvement roadmap.
Conclusion
Cloud platforms evolve quickly. What was a reasonable design two years ago may no longer reflect the organisation’s risks, workload patterns or business priorities.
Regular architecture reviews help organisations identify weaknesses before they become incidents or blockers to future change.
For a defined independent assessment with a written findings report and improvement roadmap, explore DNC’s Cloud Infrastructure Audit. You can also learn about our wider Cloud Architecture services or request a discussion.