An OCI estate drifts. What started as a clean design accumulates one off changes, emergency fixes, abandoned resources and quiet assumptions until no single person can say with confidence whether the architecture is still sound. A regular architecture review is how you catch that drift before it becomes an incident or an invoice. This guide gives you a structured checklist for reviewing an OCI architecture across the areas that matter, and a cadence for doing it without it becoming a burden.
Why reviews matter more than launch decisions
The decisions made at launch are usually the most carefully considered ones. The risk lives in everything that happened afterwards, the security list that was opened wide to unblock a deployment and never closed, the oversized shape provisioned for a test and left running, the backup policy that was never actually verified by a restore. A review is not a criticism of the original design, it is a deliberate check that reality still matches intent. Estates that review quarterly are dramatically less likely to be surprised by an outage or a cost spike.
The review checklist
- Identity and access. Are IAM policies least privilege, are unused users and keys removed, is multi factor enforced, and are compartments still structured the way the org intends.
- Network. Are security lists and network security groups tight, are public endpoints justified, is the VCN and routing topology still matching the design, and are flow logs enabled where they matter.
- Availability. Are critical tiers spread across fault and availability domains, has failover actually been tested, and do the recovery time and recovery point objectives still hold.
- Backup and recovery. Do backups run, are they retained correctly, and has a restore been tested recently rather than assumed.
- Cost. Are there idle or oversized resources, untagged spend, premium storage holding cold data, and commitments that no longer match usage.
- Security posture. Is Cloud Guard enabled and acted on, are findings triaged, and is encryption applied to data at rest and in transit.
- Operations. Are logging, monitoring and alerting in place for every critical service, and does someone own the response when an alert fires.
Scoring each area honestly
A checklist is only useful if the answers are honest. The trap is marking an item green because it was set up once, when the real question is whether it still works. Backups that run but have never been restored are not a passing item. Alerts that fire into a channel no one watches are not monitoring. Score each area on evidence, not intention, and where you cannot produce evidence, treat that as a finding in itself. This evidence first mindset is the same one that underpins our walkthrough of the Well Architected Framework.
Cadence by risk
Not everything needs reviewing at the same rhythm. Security and cost reward frequent attention because they drift fastest, while a full architecture review can happen less often. The table below is a sensible default that you can tune to your own risk appetite.
| Review type | Cadence | Owner |
|---|---|---|
| Cost and idle resource sweep | Monthly | FinOps or platform owner |
| Security posture and Cloud Guard | Monthly | Security lead |
| Backup restore verification | Quarterly | Operations |
| Full architecture review | Quarterly to twice yearly | Architecture owner |
| Disaster recovery test | Twice yearly | Operations and business owner |
Turning findings into action
A review that produces a list and no change is theatre. Each finding should become a tracked item with an owner, a priority and a due date, and the next review should start by checking whether the last round of findings was actually closed. The highest value reviews are the ones that feed a small, steady stream of improvements rather than a single overwhelming report that sits unread. This connects to the broader operating discipline in our scaling patterns guide and the foundations in the complete architecture guide.
Tooling that makes reviews repeatable
A review done entirely by hand is slow and inconsistent, and the second time around no one remembers exactly what was checked. The fix is to lean on the tooling OCI already provides so that much of the review is generated rather than gathered manually. Cloud Guard continuously assesses security posture and surfaces misconfigurations, so the security portion of a review starts from its findings rather than a blank page. The Cost Analysis and budgets features expose spend trends and anomalies for the cost portion. Tagging and the search capability let you find untagged or orphaned resources quickly. The more of the review that comes from these standing tools, the more repeatable and honest it becomes.
For estates that want consistency across reviews, capturing the checklist itself as a living document, with the queries and dashboards that feed each item, turns the review from an event that depends on who runs it into a process that anyone can run the same way. This repeatability is what lets a review cadence actually stick, because each round builds on the last rather than starting over.
The cost dimension in depth
Cost deserves more than a single checklist line because it drifts faster and quieter than almost anything else. The recurring culprits are idle compute that was provisioned for a project and never deprovisioned, block and object storage holding data long past its usefulness on premium tiers, oversized database and compute shapes chosen with a generous safety margin that was never revisited, and commitments or reservations that no longer match the shape of actual usage. None of these announce themselves, which is why a monthly sweep catches them while an annual one lets them accumulate.
The review should not just find these items but quantify them, because a finding with a dollar figure attached gets acted on and a vague note does not. Pairing the cost sweep with focused optimisation work turns the review into a steady source of savings rather than a list of suspicions, and it is the same approach that underpins our scaling patterns guide where capacity and cost meet.
Tagging and accountability
Underlying almost every review difficulty is a tagging problem. When resources are not tagged with an owner, an environment and a cost centre, every review item becomes a detective exercise, who owns this instance, is this environment still needed, which team is this spend attributable to. A disciplined tagging scheme, enforced where possible through policy, transforms reviews because every question about a resource has an answer attached to the resource itself. It also makes accountability real, because spend and posture can be attributed to the teams responsible for them rather than landing on a central function that cannot do much about it.
Establishing tagging before an estate grows is far easier than retrofitting it across hundreds of resources, which is why it belongs in the foundations described in our complete architecture guide. Where it was not done early, an early review finding should be to introduce it, because so much else depends on it.
Bringing in an outside view
Internal reviews are valuable but they share the blind spots of the people who built the estate. A periodic independent review catches the assumptions that the team has stopped seeing, and it carries more weight with leadership precisely because it is independent. The same availability and recovery thinking in our notes on designing for high availability belongs in every review. When you want a structured, independent assessment of your OCI architecture against cost, security, availability and operations, that is exactly what our OCI consulting and advisory service delivers, and a focused starting point is to book an OCI assessment.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.