Oracle Cloud Infrastructure can be provisioned quickly, but a production-ready OCI environment needs more than working resources. The foundations determine how securely the tenancy can be operated, how easily services can be governed and how much effort future change will require.
Good OCI foundations normally bring together compartments, identity, networking, logging, security controls, tagging, automation and operational ownership. Each area is manageable in isolation. The challenge is designing them as one coherent platform.
Start with the tenancy structure
Compartments are one of the first design decisions because they affect access control, resource organisation, policy scope, cost visibility and operational separation.
A tenancy should not simply mirror an organisation chart. A structure based purely on departments can become awkward when services are shared across teams or when environments need different controls. Equally, placing everything in one compartment makes permissions and cost analysis harder to manage.
A practical design usually considers environment, workload, ownership, sensitivity and shared services. Production and non-production resources often benefit from clear separation, while shared networking, security and management services may need their own controlled areas.
IAM should reflect responsibilities
OCI Identity and Access Management policies are powerful because they can grant access at tenancy or compartment level. That same flexibility makes poorly designed policies difficult to control.
The objective should be least privilege without creating an operational maze. Administrators need enough access to perform their role, but broad tenancy-level permissions should be justified rather than used as a default.
Policies should be written around job responsibilities and operational tasks. Groups, dynamic groups and workload identities should be clearly separated. Where federated identity is used, the relationship between the external identity provider, OCI groups and policies should also be documented.
Periodic access reviews matter because cloud permissions tend to accumulate. A technically correct policy can still become inappropriate as teams and responsibilities change.
Design the network before deploying workloads
The Virtual Cloud Network is another foundational component that is difficult to change casually once workloads depend on it.
Network design should consider CIDR allocation, subnet strategy, route tables, gateways, DNS, connectivity to on-premises environments, inter-region requirements and network security controls. Address ranges should allow room for growth and should avoid unnecessary overlap with connected networks.
Public and private connectivity should be deliberate. Many workloads do not need direct public exposure. Internet Gateways, NAT Gateways, Service Gateways, Dynamic Routing Gateways and peering mechanisms each solve different connectivity requirements and should be used for a defined purpose.
For organisations building or reviewing an OCI platform, DNC’s Cloud Architecture and Engineering services cover network, landing-zone and platform design.
Security Lists and NSGs need a clear model
OCI supports both Security Lists and Network Security Groups. Using both without a clear standard can make effective access difficult to understand.
Security Lists are associated with subnets, while NSGs can be applied more specifically to resources. Many environments use NSGs for workload-level control and keep subnet rules minimal, but the important point is consistency and traceability.
Rules should be specific, documented and regularly reviewed. Wide source ranges, broad port access and temporary rules that become permanent are common sources of unnecessary exposure.
Build logging and monitoring into the platform
Logging is easier to design at the start than retrofit after an incident.
Audit events, service logs, application logs, metrics and alarms should be considered as part of the foundation. Teams should know what is collected, where it is retained, how long it is kept and who responds to alerts.
Centralised visibility can help operations and security teams identify changes and anomalies across compartments. The design should also consider integration with external SIEM or monitoring platforms where these form part of the organisation’s operating model.
Use OCI security services deliberately
OCI provides controls such as Cloud Guard, Security Zones, Vulnerability Scanning, Vault and Bastion. Enabling services is not the same as having an effective security design.
Cloud Guard findings need ownership and a response process. Security Zones can enforce strong restrictions but need to align with workload requirements. Secrets and keys require lifecycle management. Bastion access should form part of a wider administrative-access model.
The objective is to turn platform capabilities into repeatable controls rather than simply switch features on.
DNC’s Cyber Security and Ethical Hacking work can complement OCI architecture by reviewing configuration, access and attack surface.
Tagging and naming improve operability
Resource names and tags can appear cosmetic during an initial build, but inconsistent conventions create real operational overhead as the tenancy grows.
A naming standard should make resources recognisable without becoming excessively complicated. Defined tags can support ownership, environment classification, cost reporting and governance. Where possible, mandatory metadata should be enforced through platform processes rather than depending entirely on individual engineers remembering to add it.
Automation should create consistency
Infrastructure as Code is valuable when it makes the environment repeatable, reviewable and auditable. Terraform is commonly used with OCI, but simply translating every console action into code is not enough.
Modules, state management, repository structure, approval workflows and secrets handling all need thought. The automation model should match the team’s ability to maintain it. A smaller set of clear, reusable modules is often more useful than a complex framework that only one person understands.
Resilience starts at design time
Availability Domains, Fault Domains, regional architecture, backups and disaster recovery requirements should be aligned to business needs.
Not every system requires multi-region architecture, but every important system should have explicit recovery expectations. Recovery Time Objective and Recovery Point Objective should influence database architecture, backup design and failover processes rather than being documented after implementation.
Define ownership
A cloud platform can be technically well designed and still be difficult to operate if ownership is unclear.
The foundation should define who manages IAM, networking, security services, backups, monitoring, Terraform, cost management and incident response. Third-party and MSP responsibilities should be documented alongside internal ownership so that gaps are visible.
What good looks like
A well-founded OCI tenancy has a compartment model that supports governance, controlled IAM policies, deliberate network paths, consistent security rules, central visibility, usable tagging standards and repeatable automation. It is also documented well enough that another competent engineer can understand how the platform is intended to operate.
Most importantly, the design supports the workloads and operational model rather than forcing every application into a generic template.
Conclusion
OCI foundations are not just an initial setup task. They establish the control plane for everything deployed afterwards.
Investing in compartments, IAM, networking, logging, security and automation early makes later migration and growth easier to govern. Where an OCI tenancy already exists, the same principles can be used to assess the current state and identify areas that need strengthening.
For support with OCI landing zones, tenancy reviews, current-state discovery or migration architecture, see DNC’s Cloud Architecture and Engineering services or contact DNC.