Oracle Cloud Key Terms
Oracle Cloud Identifier (OCID)
Oracle Cloud Identifier (OCID) is a unique name assigned to every resource you provision on OCI. This is an auto-generated long string used by Support Engineers to identify your cloud resource when working with any Support Tickets. The customer can’t choose a preferred value for OCID and can’t modify it for the life of cloud resource. The customer will also use OCIDs when working with REST APIs or SDKs.
Cloud resource refers to anything you provision on the cloud platform. In OCI terms, it can be a VCN, Compute, User, Compartment, DBaaS, LBaaS or any other service component on the platform.
On-Premises is a widely-used term in Cloud Technologies and it refers to your traditional data-center environment. It includes any co-location, dedicated floor space, dedicated data-center building or even a desktop running under your desk.
The cloud objects that your company’s employees create and use when interacting with Oracle Cloud Infrastructure. For example: compute instances, block storage volumes, virtual cloud networks (VCNs), subnets, route tables, etc.
An individual employee or system that needs to manage or use your company’s Oracle Cloud Infrastructure resources. Users might need to launch instances, manage remote disks, work with your virtual cloud network, etc. End users of your application are not typically IAM users. Users have one or more IAM credentials
A collection of users who all need the same type of access to a particular set of resources or compartment.
A special type of group that contains resources (such as compute instances) that match rules that you define (thus the membership can change dynamically as matching resources are created or deleted). These instances act as “principal” actors and can make API calls to services according to policies that you write for the dynamic group.
A collection of related resources. Compartments are a fundamental component of Oracle Cloud Infrastructure for organizing and isolating your cloud resources. You use them to clearly separate resources for the purposes of measuring usage and billing, access (through the use of policies), and isolation (separating the resources for one project or business unit from another). A common approach is to create a compartment for each major part of your organization.
The root compartment that contains all of your organization’s Oracle Cloud Infrastructure resources. Oracle automatically creates your company’s tenancy for you. Directly within the tenancy are your IAM entities (users, groups, compartments, and some policies; you can also put policies into compartments inside the tenancy). You place the other types of cloud resources (e.g., instances, virtual networks, block storage volumes, etc.) inside the compartments that you create.
A document that specifies who can access which resources, and how. Access is granted at the group and compartment level, which means you can write a policy that gives a group a specific type of access within a specific compartment, or to the tenancy itself. If you give a group access to the tenancy, the group automatically gets the same type of access to all the compartments inside the tenancy. For more information, see Example Scenario and How Policies Work. The word “policy” is used by people in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named “policy” document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources.
The region where your IAM resources reside. All IAM resources are global and available across all regions, but the master set of definitions reside in a single region, the home region. You must make changes to your IAM resources in your home region. The changes will be automatically propagated to all regions.
A relationship that an administrator configures between an identity provider and a service provider. When you federate Oracle Cloud Infrastructure with an identity provider, you manage users and groups in the identity provider. You manage authorization in Oracle Cloud Infrastructure’s IAM service. Oracle Cloud Infrastructure tenancies are federated with Oracle Identity Cloud Service by default.
Oracle Cloud Infrastructure Compute lets you provision and manage compute hosts, known as instances. You can launch instances as needed to meet your compute and application requirements. After you launch an instance, you can access it securely from your computer, restart it, attach and detach volumes, and terminate it when you’re done with it. Any changes made to the instance’s local drives are lost when you terminate it. Any saved changes to volumes attached to the instance are retained.
Oracle Cloud Infrastructure offers both Bare Metal and Virtual Machine instances:
Bare Metal – A bare metal compute instance gives you dedicated physical server access for highest performance and strong isolation.
Virtual Machine – A Virtual Machine (VM) is an independent computing environment that runs on top of physical bare metal hardware. The virtualization makes it possible to run multiple VMs that are isolated from each other. VMs are ideal for running applications that do not require the performance and resources (CPU, memory, network bandwidth, storage) of an entire physical machine.
An Oracle Cloud Infrastructure VM compute instance runs on the same hardware as a Bare Metal instance, leveraging the same cloud-optimized hardware, firmware, software stack, and networking infrastructure.
Virtual Cloud Network (VCN)
Virtual Cloud Network (VCN) also known as Cloud Network is a software-defined network that you set up on OCI. You can think of VCN as an extension of your on-premises network to the cloud, with firewall rules and specific types of communication gateways. A VCN covers a single, contiguous CIDR (range of IP Addresses) block of your choice. VCN is a regional resource, it means it covers all the Availability Domains (ADs) within a region.
Oracle OCI VCN supports a CIDR range of /16 to /30 and you can’t change the CIDR of a VCN after it’s created. The VCN’s CIDR must not overlap with your on-premises network so work with your on-premises Network Administrator to get an available range of IP addresses (CIDR) that can be used with your VCN.
A subnet is a subdivision of cloud network (VCN). Subnet is an AD (Availability Domain) specific resource and you must have one subnet per AD in a region. A subnet consists of a contiguous range of IP Addresses that do not overlap with other Subnets within the same VCN. You build a subnet by specifying the CIDR (range of IP Address), Availability Domain (AD) and a user-friendly name for the Subnet. Subnets contain virtual network interface cards (VNIC), which attach to instances. You can designate a subnet as private when you create it, which means VNICs in the subnet can’t have public IP address.
A subnet is associated with Security Lists, Route tables and DHCP options to control what traffic can flow in which direction (DRG or IG for public/private traffic). You can’t change Security Lists/Route Table attachment once a subnet is built, however you can change the rules of Security Lists and Route Tables.
Virtual Network Interface Card (VNIC)
A Virtual Network Interface card (VNIC) resides in a Subnet and gets attached to an instance to enable connections to the Subnet’s VCN. Each instance has a default primary VNIC that is created during instance launch and can’t be removed. You can add Secondary VNICs to an existing instance (in the same AD as the primary AD) if needed.
Dynamic Routing Gateway (DRG)
Dynamic Routing Gateway (DRG) is a virtual router that provides a path for private traffic between OCI cloud network (VCN) and on-premises (data-center) network. DRG is a standalone resource on OCI and is designed to give you full flexibility to attach/detach to different VCN as per the business needs. A DRG is required for both VPN IPSec Tunnels and Fast Connect virtual circuits. A network administrator might think of the DRG as the VPN head-end on their OCI Services.
Internet Gateway (IG)
Internet Gateway (IG) is an optional virtual router that you can add to an VCN for internet connectivity. It provides internet access to your VCN and is controlled by the Route Tables and Security List configuration on the Subnet Level. In addition to IG, you must have the following to access the internet from the compute instance:
a) Routing rule in Route Table that points to the IG
b) Appropriate port open in the Security List, e.g. Port 80/443 must be opened for Web Server Traffic.
NOTE: Having an Internet Gateway alone DOES NOT expose your subnet to the internet unless you satisfy both conditions above.
Security Lists are a virtual firewall for your VCN on OCI infrastructure. Each security list consists of ingress and egress rules that specify the destination (CIDR) and type of traffic (Protocol and port) allowed in and out of instances within a subnet.
A Security List is attached to a subnet and you can change the traffic type/destination dynamically. For example, a rule in Security Lists with source CIDR 10.100.200.0/24 with destination port 22 of TCP protocol will allow all ingress traffic from IP addresses (10.100.200.0/24) on to OCI instances on port 22 for ssh connection.
Route Tables are virtual route tables where you configure private and public traffic using DRG or IG. The route table rules provide mapping for the traffic from subnets via gateways to a destination outside VCN, e. g., private traffic flows using DRG and public traffic flows using IG. You can build multiple route tables within a VCN or use the default route table.
A route table must be assigned to a subnet within a VCN, so a default route table is used when you create a subnet without specifying a route table. You can have one dedicated route table per subnet to keep it easy for subnet management. You can’t change a subnet to use another route table once a subnet is created, however, you can change the route table rules at any time.