Cloud Adoption Framework Landing Zone
The Cloud Adoption Framework (CAF) Landing Zone is a set of automated modules that help you configure your Oracle Cloud Infrastructure (OCI) cloud tenancy in preparation for moving your workloads to the cloud.
Important: Oracle Cloud Infrastructure provides multiple landing zone implementations that you can choose from. See How Do I Decide Which Landing Zone to Use?
The CAF Landing Zone provides the baseline architectural framework for your organization to deploy new projects and workloads on OCI. The landing zone consists of Terraform modules, the architectural documentation in this section, and an implementation guide. The landing zone helps you quickly and securely create a foundation for your cloud deployment based on Oracle recommendations, customer experience, and industry-standard best practices.
The CAF Landing Zone creates infrastructure that consists of compartments, networking resources, and security at the infrastructure layer. Migrating or developing workloads is not in scope for the CAF Landing Zone. However, setting up the right infrastructure is often the first step to migrating workloads to the cloud or developing cloud-native workloads successfully.
The CAF Landing Zone is composed of two stacks. The first landing zone stack deploys the core infrastructure components. The second landing zone stack, called Workload Expansion, deploys workload-specific architecture components that form the baseline for a workload deployment into the landing zone.
How to Deploy
You can deploy the CAF Landing Zone as either a comprehensive version (the Enterprise Scale Baseline Landing Zone) or a Start Small and Scale version.
The Enterprise Scale Baseline Landing Zone includes an implementation guide and architectural guidance. Deploy multiple workloads (by using the Workload Expansion Landing Zone) with separate networks for isolation and access, add private connectivity to your environment from on-premise locations by using FastConnect or Site-to-Site VPN, and optionally federate with Microsoft Active Directory.
Core infrastructure components: To deploy the core infrastructure components, install the Enterprise Scale Baseline Landing Zone as the first stack using the Console, Resource Manager, or the Oracle Cloud Infrastructure Terraform provider.
The Terraform template for the core infrastructure components is available on GitHub: https://github.com/oracle-quickstart/oci-enterprise-scale-baseline-landing-zone
Workload expansion: After you install the core infrastructure components, you can deploy the workload infrastructure components by installing the Workload Expansion Landing Zone as the second stack using the Console, Resource Manager, or the Oracle Cloud Infrastructure Terraform provider.
The Terraform template for the Workload Expansion is available on GitHub: https://github.com/oracle-quickstart/oci-esblz-workload-expansion
Start Small and Scale Version
The Start Small and Scale Landing Zone includes a limited set of functionality that lets you get started with the CAF Landing Zone. Install the Start Small and Scale Landing Zone from the Deploy a baseline Landing Zone Quickstarts card on the Console home page.
The primary objectives of the CAF Landing Zone include the following items:
Reduce the time taken to onboard to OCI
Provide an architecturally strong foundation
Maintain the balance between flexibility to customize and prescriptive guidance, while the implementation evolves to your organization's needs
Key Design Principles
Key design principles for resiliency and security ensure that the CAF Landing Zone deploys a strong foundation for your cloud environment.
A resilient cloud architecture helps you to avoid single points of failure for your cloud-based workloads.
At the infrastructure level, OCI provides physical and logical resources to help you design for resiliency, such as regions, availability domains, and fault domains.
Resiliency depends on the nature, architecture, and implementation of the workloads that you plan to deploy on OCI. For best practices, see Resilience and Continuous Availability of Oracle Cloud Infrastructure Services and Platform FAQ and Best practices for designing reliable and resilient cloud topologies.
The CAF Landing Zone follows best practices for security design principles.
Design to mitigate attacks
Limit permissions based on requirements
Enforce network segmentation
Leverage cloud-native security controls
Use identity as primary access control
Focus on information protection
Design for resilience
Defense in depth
Defense at edge
Assume zero trust
For more information, see the security design principles in Best practices framework for Oracle Cloud Infrastructure.
The CAF Landing Zone creates an architectural framework that's ready for you to launch new projects and workloads on to OCI. In order to achive this, you must run both the core infrastructure stack and the Workload Expansion stack.
Note: The Workload Expansion Landing Zone stack cannot be deployed in standalone mode. Instead, deploy the core infrastructure stack first and then deploy the Workload Expansion stack.
Compartments: Use compartments to organize and isolate your resources to make it easier to manage and secure access to them.
Tags: Use tags to organize and list resources based on your business needs.
Budgets and alerts: Use budgets to set soft limits on your OCI spending, and use alerts to let you know when you might exceed your budget.
Oracle Cloud Infrastructure Identity and Access Management (IAM): Use IAM to control access to your cloud resources on OCI.
Networking and connectivity: Create a virtual cloud network (VCN), subnets, and other networking and connectivity resources that are required to run your workloads and connect to the internet or your on-premises network.
Security: Enable a strong security posture by enabling OCI security services such as Oracle Cloud Guard, Oracle Vulnerability Scanning Service, and Oracle Cloud Infrastructure Bastion.
You use compartments to organize and isolate your resources to make it easier to manage and secure access to them.
The CAF Landing Zone creates a compartment structure for your organization. You control access to compartment by creating policies that specify what actions groups of users can take on the resources in those compartments. The following diagram shows the compartments that are created by the CAF Landing Zone. The components that are deployed by the Workload Expansion stack are noted.
The following table describes the compartments that are created by the CAF Landing Zone.
|Root||-||0||Created when your tenancy is provisioned. Your root compartment holds all of your cloud resources. You can think of the root compartment like a root folder in a file system.|
The parent compartment for the CAF Landing Zone.
You can choose a name for the parent compartment. The CAF Landing Zone creates the parent compartment as the first level compartment under the root compartment (tenancy).
All other resources that are created by the CAF Landing Zone are created in the parent compartment and its subcompartments. You can think of the parent compartment as the container compartment for your landing zone deployment.
|Common Infra||Root/<Parent_compartment>||2||Contains resources related to network and security.|
|Network||Root/<Parent_compartment>/Common Infra||3||Resources for networking and connectivity are created in this compartment. These resources include the virtual cloud network (VCN), subnets, gateways, and other related components.|
|Security||Root/<Parent_compartment>/Common Infra||3||All resources related to security and monitoring are created in this compartment. Resources related to governance, such as logging, notifications, and events, are also created in this compartment.|
|Applications||Root/<Parent_compartment>||2||Contains the workloads that you want to move to OCI.|
<Workload 1> to <n>
Note: Deployed only with the Workload Expansion stack
One or more workload compartments. Create a separate workload compartment for each workload that you plan to run on OCI. Then, place all compute and storage resources for the applications in the associated workload compartment. Example resources include compute instances, block volumes, functions, and Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) resources.
You provide the names for your workload compartments during the landing zone deployment. To make it easier to identify and manage your workloads, assign names to the workload compartment that describe the workloads that will run in the compartment.
Note that the CAF Landing Zone creates the workload compartments, but does not create any workload-related resources.
Example Compartment Structure
Say that you want to deploy three workloads on OCI: a finance application, a human resources (HR) application, and a marketing application.
The first step is to deploy the Enterprise Scale Baseline Landing Zone modules, which create the foundation of your environment.
After you deploy the core infrastructure components, you run the Workload Expansion stack for your first workload, the finance application. You configure the relevant parameters and naming conventions according to your organization's policies. Then, you're ready to migrate the application.
For the remaining applications, you perform the same process of running the Workload Expansion stack and defining the relevant parameters needed for each application. When you are ready, you can migrate each application into the relevant environment.
This process gives you complete control and isolation over each application. The workload compartments can share common infrastructure resources such as identity domains, FastConnect, Cloud Guard targets, and so on.
The CAF Landing Zone creates a basic tagging structure to help you manage your resources.
Tagging allows you to define keys and values and associate them with resources. You can then use the tags to help you organize and list resources based on your business needs.
As part of the CAF Landing Zone deployment, the resources that are created by the Landing Zone are assigned tags for cost center and geographic location. You should define values for these tags that will help you identify and separate resources based on your organization's workloads. We recommended that you map the cost center tag to a project or line of business that a workload supports. The geographic location should be defaulted to the OCI region where your workload runs.
Budgets and Alerts
The CAF Landing Zone configures basic budgets and alerts to help you manage your resources.
A budget can be used to set soft limits on your OCI spending. You can set alerts on your budget to let you know when you might exceed your budget, and you can view all of your budgets and spending from one single place in the Console.
The CAF Landing Zone creates the necessary resources to use budgets and alerts, including a threshold metric for alerts and an email recipient to receive the alerts.
Use Oracle Cloud Infrastructure Identity and Access Management (IAM) to control access to your cloud resources on OCI.
The CAF Landing Zone creates IAM groups and policies that control access to the resources created by the Landing Zone. Optionally, with the Enterprise Scale Baseline Landing Zone, you can federate with your organization's Microsoft Active Directory implementation.
We recommend that you create one or more break-glass users during your deployment, especially if you are using federation. Break-glass users are administrators who have emergency access to all Oracle Cloud Infrastructure services and resources in the tenancy.
For non-federated users, the CAF Landing Zone creates IAM groups and policies. For information about the IAM groups created by the CAF Landing Zone, see IAM Policies and Groups.
Federating with Microsoft Active Directory
With the Enterprise Scale Baseline Landing Zone, you can optionally federate with Microsoft Active Directory.
Use the same group names in Oracle Cloud Infrastructure as you use for Active Directory. To do this, pass the Active Directory group names as variables to the Enterprise Scale Baseline Landing Zone Terraform module. The groups will be created by the landing zone and mapped to your Active Directory groups.
The following diagram shows the Microsoft Active Directory federation supported by the Enterprise Scale Baseline Landing Zone.
For more information about federating with Active Directory, see Federating with Microsoft Active Directory.
For information about the IAM policies created by the CAF Landing Zone, see IAM Policies and Groups.
Networking and Connectivity
The CAF Landing Zone helps you configure the network architecture for your organization's cloud deployment.
The CAF Landing Zone creates a virtual cloud network (VCN) in the Network compartment. You can choose the name and the IPv4 CIDR blocks for the VCN. We recommend that you use a single VCN with multiple subnets, and deploy each workload on its own subnet. This will lead to better network isolation for your workloads. Because of this, ensure that you create the VCN with a large enough CIDR range for your workloads.
The following diagram shows the VCN that is created by the CAF Landing Zone. The components that are deployed by the Workload Expansion stack are noted.
Tip: If you plan to deploy a virtual appliance, we recommend that you manually create another VCN to host the virtual appliance.
The CAF Landing Zone creates public and private subnets within the VCN.
Subnet-Public: A public subnet to host all internet-facing servers and resources, including load balancers. This subnet must be secured with the correct Cloud Guard recipes and other security features, as described in Security.
Subnet-Shared Services: A private subnet to host all common or shared services that your organization uses. Depending on your applications, you must create security lists to allow the network traffic between servers in your cloud tenancy (east/west traffic) to enter and exit this subnet. Create security lists during the deployment of your workloads.
Subnet Bastion Service: A private subnet to host the Bastion service. Bastion provides restricted and time-limited access to target resources that don't have public endpoints. Configuring bastions is important to ensure that your organization's cloud administrators can access resources that reside in private subnets.
Subnet - <Workload>: Deployed only with the Workload Expansion stack. A private subnet that you should use to host all resources that are needed by a specific workload, with the exception of databases. You can create multiple subnets, one for each workload.
Subnet - <Workload> - Database Services: Deployed only with the Workload Expansion stack. A private subnet to host database resources for your applications. You can create multiple subnets, one for each workload's database resources.
The CAF Landing Zone creates the gateways that your applications might need to connect with Oracle Cloud Infrastructure services and the internet, plus the basic components to control access.
Internet gateway: A virtual router that connects the edge of the VCN with the internet to allow direct connectivity to the internet. The CAF Landing Zone creates an internet gateway, and the following components along with the internet gateway:
Security lists: Security lists are virtual firewalls that let you control ingress and egress traffic. The CAF Landing Zone creates a security list associated with the internet gateway. The actual ingress and egress rules will depend on your workloads and the traffic that you want to allow. Configure the ingress and egress rules when you move your workloads to OCI.
Note: The CAF Landing Zone creates stateful security lists. If you have a public-facing application or load balancer that requires you to support a very large number of connections, we recommend that you create stateless security lists. For more information, see Stateful Versus Stateless Rules.
Route table: Route tables are used to map the traffic of a VCN from subnets through gateways to external destinations. The CAF Landing Zone creates a route table that is associated with the internet gateway. You must create rules in the route table to allow necessary traffic to go to the internet gateway. The rules will depend on your workloads.
Network Address Translation (NAT) gateway: A NAT gateway gives cloud resources without public IP addresses access to the internet without exposing those resources to incoming internet connections. The CAF Landing Zone creates a NAT gateway for the landing zone deployment. It also creates a route table and route rule to route traffic from each of your workload compartments. The actual route rules will depend on your workloads. Create the rules when you move your workloads to OCI.
Private endpoints: A private endpoint is a private IP address within your VCN that you can use to access a given service within OCI. The CAF Landing Zone creates private endpoints to access the following Oracle Cloud Infrastructure services: Autonomous Database, Streaming, Data Safe, Data Catalog, Analytics Cloud, and Data Flow. We recommend that you use private endpoints if your workloads need to connect with any of these services.
Service gateway: A service gateway enables cloud resources without public IP addresses to privately access Oracle services without the traffic going over the internet. The CAF Landing Zone creates a service gateway. You must create service CIDR labels, route rules, and security rules for the service gateway when you move your workloads to OCI. The configuration will depend on your workloads.
The Enterprise Scale Baseline Landing Zone can optionally configure dynamic routing gateways (DRGs) using Site-to-Site VPN or FastConnect.
Site-to-Site VPN: A site-to-site IPSec connection between your on-premises network and your VCN. Provide the IP address of your customer-premises equipment (CPE) to the landing zone Terraform module. Also provide the static routes for the IPSec connection.
FastConnect: A dedicated, private connection between your data center and Oracle Cloud Infrastructure, using your choice of Oracle partners. In addition to selecting an Oracle partner, also provide the following information:
FastConnect routing policy
Virtual circuit bandwidth shape
Virtual circuit cross connect mapping - customer Border Gateway Protocol (BGP) peering
Virtual circuit cross connect mapping - Oracle BGP peering
Virtual circuit customer autonomous system number (ASN)
The CAF Landing Zone helps you configure a security architecture for your organization's cloud deployment.
Security features are deployed in the Security compartment. Depending on your organization's structure, a cybersecurity or cloud platform team typically manages the security functions for your tenancy.
The following diagram shows the reference architecture for security features in the CAF Landing Zone.
As a starting point to secure your cloud environment on OCI, we recommend that you enable and use services such as Cloud Guard, Vulnerability Scanning, and Bastion. Customize the security architecture for your organization based on your organization's requirements.
Use Cloud Guard to manage the security of your cloud resources in alignment with Oracle best practices.
Cloud Guard is a cloud-native service that helps customers monitor, identify, achieve, and maintain a strong security posture on Oracle Cloud. Use the service to examine your Oracle Cloud Infrastructure resources for security weakness related to configuration, and your Oracle Cloud Infrastructure operators and users for risky activities. Upon detection, Cloud Guard can suggest, assist, or take corrective actions, based on your configuration.
Use Oracle-managed recipes as the baseline starting point. Available recipes include:
OCI Configuration Detector recipe: Set of rules designed specifically to detect resource configuration settings that could pose a security problem.
OCI Activity Detector recipe: Set of rules designed specifically to detect actions on resources that could pose a security problem.
Responder recipe: Defines the action or set of actions to take in response to a problem that a detector has identified.
The CAF Landing Zone implements security best practices monitoring by enabling Cloud Guard at the tenancy level. It also enables security posture monitoring of the parent compartment by using Oracle-managed configuration detector recipes and activity detector recipes.
Note: To avoid potential application outages due to unexpected platform modification, responder recipes are not enabled. We recommend that you apply responder recipes after reviewing and testing for your organization.
Be aware of the following considerations:
Your Cloud Guard administrator should review the detector recipes and customize the scope with conditional groups as needed.
Before enabling the responder recipes and related policies, your Cloud Guard administrator should review them with the stakeholders of any existing applications.
You can create customer-managed responder recipes and detector recipes by cloning Oracle-managed recipes as needed.
Vulnerability and port scanning is enabled for the parent compartment of the CAF Landing Zone.
Vulnerability Scanning helps improve your security posture by routinely checking your cloud resources for potential vulnerabilities.
For information about the vulnerability sources and the platforms that the Scanning service detects vulnerabilities in, see Compute Targets.
The Scanning service also scans for ports in your compute instances that are unintentionally left open and might be a potential attack vector to your cloud resources, or enable hackers to exploit other vulnerabilities.
A network mapper searches your public IP addresses for open ports.
Agent-based scanning checks for open ports that are not accessible from public IP addresses.
Your administrator can extend the Scanning service to the tenancy level by defining a scan target at the root compartment with a standard recipe.
Important: Because Windows scanning does not include Open Vulnerability and Assessment Language (OVAL) data, we recommend that you do not rely solely on the Scanning service to ensure that your Windows instances are up to date and secure.
Prolonged Archiving of Audit Logs
Use retention rules to preserve Oracle Cloud Infrastructure Audit logs for long-term data governance, regulatory compliance, and legal hold requirements.
Be aware of the following considerations:
By default, Audit logs are retained for 365 days. If your organization needs to meet compliance or other requirements, you can optionally archive Audit logs for a longer length of time by saving them in immutable storage written to Oracle Cloud Infrastructure Object Storage and Archive Storage buckets with locked, time-bound retention rules.
You should deploy immutable Audit log archiving only when there is a strong business need to keep Audit logs for longer than the retention period.
Review (or unlock) the retention rule within 14 days before it is locked.
Locking a retention rule is an irreversible operation. Not even a tenancy administrator can delete a locked rule.
There is a mandatory 14-day delay before a rule is locked. This delay lets you thoroughly test, modify, or delete the rule or the rule lock before the rule is permanently locked.
A rule is active at the time of creation. The lock only controls whether the rule itself can be modified. After a rule is locked, only increases in the duration are allowed.
Object modification is prevented and the rule can only be deleted by deleting the bucket. A bucket must be empty before it can be deleted.
To avoid difficulties in cleaning up your testing environment, consider using a short retention period in non-production environments, such as one day.
By default, Oracle manages the keys that encrypt the Object Storage or Archive Storage buckets. If you want greater control over the lifecycle and use of your encryption keys, you can choose a key from a vault that you have access to. For more information, see Overview of Vault.
After the audit log bucket is created, you can manually enable the write access logs to meet the Center for Internet Security (CIS) Oracle Cloud Infrastructure Benchmark.
You can integrate logs with third-party security information and event management (SIEM) solutions using the Service Connector Hub and Streaming services. For examples, see Oracle Cloud Infrastructure logging plugin for Splunk and Move logs from Oracle Cloud Infrastructure into IBM QRadar.
Bastion provides secured, session-based access to resources without public endpoints.
Bastions let authorized users connect from specific IP addresses to target resources using Secure Shell (SSH) sessions. When connected, users can interact with the target Oracle Cloud Infrastructure resource by using any software or protocol supported by SSH. For example, you can use the Remote Desktop Protocol (RDP) to connect to a Windows host, or use Oracle Net Services to connect to a database.
Be aware of the following considerations:
A bastion is associated with a single virtual cloud network (VCN). You cannot create a bastion in one VCN and then use it to access target resources in a different VCN.
Bastions, like most Oracle Cloud Infrastructure resources, are subject to service limits. Request a service limit increase if needed, and consider subcompartments for your bastions as an alternative.
VCN Flow Logs
Use VCN flow logs to view details about traffic that passes through your VCN.
VCN flow logs help you to audit traffic and troubleshoot your network controls. After you enable VCN flow logs, they record traffic for the virtual network interface cards (VNICs) attached to compute instances in the subnet.
Your operational teams can use the predefined VCN Flow Logs dashboard in Oracle Cloud Infrastructure Logging Analytics, or create custom dashboards to meet your organization's specific needs.
Managing Terraform State
The Enterprise Scale Baseline Landing Zone in Resource Manager and the Start Small and Scale Landing Zone in the Console Quickstarts manage Terraform state inherently as part of each landing zone deployment.
You can store Terraform state within Oracle Cloud Infrastructure Object Storage if needed. For more information, see Using Object Storage for State Files.