A cloud architecture review should answer three questions with evidence from the live environment: What differs from the intended design? What can an external or unintended principal reach? Where is the architecture spending money without creating enough value? The output is not a polished diagram. It is a prioritized set of findings, owners, and next actions tied to the AWS resources that are actually running.
Use the review below to catch infrastructure drift, exposure paths, and cost waste before they become separate security, reliability, and FinOps incidents.
What Is a Cloud Architecture Review?
A cloud architecture review is a structured assessment of a workload’s current design, deployed configuration, and operating evidence. It checks whether the system still meets its security, reliability, performance, operational, cost, and sustainability requirements.
That scope matches the six pillars in the AWS Well-Architected Framework. But a useful review goes beyond answering a questionnaire. It connects each design claim to live resources, relationships, configurations, and usage data.
The review should produce:
- A current inventory of in-scope accounts, Regions, resources, and dependencies
- A comparison between intended configuration and deployed state
- A map of public, cross-account, and high-privilege access paths
- Cost findings tied to specific resources and workload decisions
- A ranked remediation backlog with an owner and due date for every accepted action
- A record of intentional exceptions so the same finding is not rediscovered every review
AWS recommends treating architecture review as a lightweight, continuing practice rather than a one-time audit. The people who build and operate the workload should be part of the conversation because they understand why a configuration exists and what a proposed change could break.
Start With Evidence, Not the Last Diagram
The fastest way to weaken a review is to treat an old diagram as ground truth. Use it as a statement of intent. Build the current-state view from deployed resources.
Collect evidence from five sources:
- Resource inventory: Accounts, Regions, VPCs, subnets, gateways, load balancers, compute, databases, storage, queues, secrets, and identity resources.
- Infrastructure as code: CloudFormation, Terraform, AWS CDK, or another declared source that represents the approved configuration.
- Configuration history: AWS Config, CloudTrail, deployment history, and change records that explain when and how the environment changed.
- Security evidence: IAM Access Analyzer findings, Security Hub findings, network paths, security groups, resource policies, encryption settings, and logging coverage.
- Cost and utilization evidence: Cost Optimization Hub, Compute Optimizer, Cost Explorer, tags, unit-cost metrics, and workload demand patterns.
AWS Config records resource configurations, relationships, and historical changes for supported resource types. That makes it useful for reconstructing current state and investigating when a risky or expensive change appeared.
How to Find Infrastructure Drift
Infrastructure drift is a difference between an approved or declared configuration and the environment that is actually deployed. Not every difference is a defect. The review must separate intentional exceptions from temporary changes and unmanaged divergence.
Compare declared and deployed state
For CloudFormation-managed resources, run drift detection and inspect the property-level differences. AWS CloudFormation drift detection reports the expected and actual property values for supported resources that have drifted.
Do not stop with resources covered by one infrastructure-as-code stack. Also look for:
- Resources created manually and never imported into code
- Deployed resources missing from the approved architecture
- Security group, route, policy, or encryption changes made outside the delivery pipeline
- Parameters or secrets that differ across supposedly equivalent environments
- Temporary troubleshooting changes that were never reversed
- Resources that are declared in code but no longer serve the live workload
Classify each difference
Use a simple decision record for every material difference:
| Classification | Meaning | Required action |
|---|---|---|
| Approved | The deployed state is intentional and authorized | Update the code, diagram, and decision record |
| Temporary | The change has a defined short-term purpose | Add an owner, expiry date, and rollback condition |
| Unintended | The deployed state violates the approved design | Remediate or formally accept the risk |
| Unknown | The team cannot explain the difference | Treat as a finding until ownership and intent are established |
The correction path matters. If the deployed change is right, bring the declared source and documentation forward. If the deployed change is wrong, restore it through the delivery path. Avoid normalizing a console change simply because production currently depends on it.
How to Review Public and Cross-Account Exposure
Exposure is not limited to a resource with a public IP address. A review must follow the path from an untrusted principal or network location to a sensitive resource or action.
Review these layers together:
- Internet gateways, public subnets, route tables, NAT gateways, and transit paths
- Load balancer listeners, API endpoints, CDN origins, and firewall rules
- Security groups and network ACLs
- S3 bucket policies, KMS key policies, queue and topic policies, repository policies, and other resource-based policies
- IAM roles, trust policies, permission boundaries, and cross-account assumptions
- Secrets, snapshots, backups, logs, and data stores that may be reachable through a trusted intermediary
IAM Access Analyzer identifies supported resources shared with external principals by analyzing resource-based policies. AWS currently lists 15 supported external-access resource types, including S3 buckets, IAM roles, KMS keys, Lambda functions, queues, secrets, snapshots, ECR repositories, EFS file systems, and DynamoDB tables or streams.
Treat analyzer findings as evidence, not the entire review. AWS notes that external-access analysis is Regional for supported resources. Network reachability, identity chaining, application authorization, and resources outside the supported set still need separate checks.
For each exposure path, record:
- Entry point and source
- Resource or data reached
- Identity and permissions involved
- Protective controls in the path
- Business reason for the exposure
- Monitoring and response coverage
- Owner, decision, and remediation date
How to Find Cloud Cost Waste
Cost waste is usually the financial result of an architecture decision, not just an expensive line item. Review the resource, its relationship to the workload, and the demand it serves.
Look for four categories:
Idle resources
Find compute, storage, databases, load balancers, NAT gateways, addresses, snapshots, and test environments with no current workload purpose. AWS Compute Optimizer states that its idle-resource recommendations are refreshed daily and use resource specifications plus utilization metrics over a lookback period.
Oversized resources
Compare provisioned capacity with sustained and peak demand. Include seasonality, failover capacity, and service-level requirements before resizing. A low average can hide a legitimate peak, while a high limit can conceal an inefficient workload.
Duplicated or stranded architecture
Trace resources that remain after a migration, redesign, failed experiment, or environment teardown. Common examples include unattached storage, obsolete snapshots, duplicate data transfer paths, unused reservations, and parallel services that no longer support a rollback plan.
Structurally expensive choices
Look beyond rightsizing. Repeated cross-AZ or cross-Region traffic, unnecessary NAT paths, excessive log retention, chatty service boundaries, and the wrong storage tier can make an otherwise healthy resource expensive.
AWS Cost Optimization Hub consolidates recommendations across accounts and Regions for actions such as rightsizing, deleting idle resources, and applying Savings Plans or Reserved Instances. Use its estimates as a prioritization input. Validate workload risk and future usage before acting.
A Practical Cloud Architecture Review Process
1. Define the review boundary
Name the workload, accounts, Regions, environments, data classes, and business capabilities in scope. Record explicit exclusions. Assign one accountable workload owner.
2. Build the current-state model
Scan the live AWS environment and organize resources by workload and dependency. Connect network, identity, data, compute, and integration relationships. Mark evidence timestamps so reviewers know how current the model is.
3. Compare intent with reality
Overlay infrastructure-as-code definitions, approved diagrams, architecture decision records, and policy requirements. List every material mismatch without deciding too early whether it is acceptable.
4. Trace exposure paths
Start with public and cross-account entry points. Follow network routes, resource policies, roles, and application trust boundaries to sensitive resources. Confirm whether every path is required and monitored.
5. Add cost and utilization
Attach current cost, estimated savings, utilization, and ownership to the affected resources. Separate safe cleanup from changes that require load testing, resilience analysis, or commercial review.
6. Prioritize by combined impact
Rank findings using more than severity:
| Priority signal | Question |
|---|---|
| Security | Can an unintended principal reach a sensitive action or dataset? |
| Reliability | Can the condition cause an outage, data loss, or failed recovery? |
| Cost | What recurring spend or estimated saving is attached to the finding? |
| Drift | Does the deployed state bypass the approved delivery and control path? |
| Effort | Can the team remediate safely now, or is design work required? |
| Confidence | Is the finding supported by current, complete evidence? |
7. Assign and verify actions
Every action needs an owner, due date, success condition, and verification method. Re-scan after remediation. Update the infrastructure code and architecture record so the fix persists.
Where Creately Blueprint Fits
Creately Blueprint is a hosted cloud-architecture scanning and visualization layer for platform and cloud infrastructure engineers. It is designed to provide an always-current, auditable view of cloud environments.
In a review workflow, that means starting from a live AWS scan and using a shared visual model to examine deployed resources and relationships. The visual is not a substitute for AWS security, configuration, or cost evidence. It is the review surface that helps platform, security, FinOps, and workload owners investigate the same current-state architecture and connect findings to the affected components.
If you need to design or communicate an intended AWS architecture before a live-state review, use Creately’s AWS architecture diagram tool. Keep the intended design and the scanned deployed state distinct so reviewers can see what changed.
Cloud Architecture Review Checklist
- Review boundary, workload owner, accounts, and Regions are recorded
- Current resource inventory has a capture timestamp
- Resource relationships and critical data paths are mapped
- Deployed state is compared with infrastructure as code
- Manual, temporary, unmanaged, and unknown changes are classified
- Public and cross-account access findings are reviewed in every active Region
- Network, identity, and resource-policy exposure paths are traced together
- Idle, oversized, duplicated, stranded, and structurally expensive resources are assessed
- Each finding includes evidence, impact, owner, due date, and verification
- Accepted exceptions have a reason and review date
- Remediated findings are re-scanned
- Code, diagrams, and decision records are updated to match the approved state
