Deploy Oracle Insurance Data Foundation in the Cloud with an Autonomous Data Warehouse

As an insurance provider, you need a comprehensive data analytics solution. Oracle Insurance Data Foundation is a platform that combines a data model for the insurance industry with a set of management and infrastructure tools to help you manage your analytics life cycle, from sourcing to reporting and business intelligence.

Deploy Oracle Insurance Data Foundation on Oracle Cloud Infrastructure with Oracle Autonomous Data Warehouse, and realize the following business benefits:
  • Move your infrastructure to the cloud with minimal-to-zero need to change your application architecture.
  • Lower the total cost of ownership by reducing over-provisioning and moving from fixed to variable costs.
  • Reduce the risk of interruptions to business operations, and increase your responsiveness and customer satisfaction.


This reference architecture shows the infrastructure required to deploy Oracle Insurance Data Foundation in the cloud.

The middleware tier, application tier, and database tier are in separate private subnets, which can be accessed through a bastion host. External access to the applications is through a public load balancer. Every tier has redundant resources distributed in different fault domains, ensuring a highly available application environment across the stack.

Description of oidf-oci.png follows
Description of the illustration oidf-oci.png

The architecture has the following components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domain

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault domain

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  • Virtual cloud network (VCN) and subnet

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Load balancer

    The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from one entry point to multiple application servers in the backend. The load balancer provides a front end to the application servers, isolating and preventing unnecessary or unauthorized access to the internal layers.

    When you create the application layer in cluster mode, you can configure the load balancer to distribute traffic across the servers in your Oracle WebLogic Server domain.

  • Bastion host

    The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud. The bastion host is provisioned typically in a demilitarized zone (DMZ). It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. So, you can avoid exposing the more sensitive components of the topology without compromising access to them.

  • Application tier

    The Oracle Insurance Data Foundation server is the node that hosts the product binaries, multi-threaded services for metadata management, and batch-processing frameworks.

  • Middleware tier
    The middleware tier contains the following components:
    • Oracle WebLogic Server
    • Oracle Data Integrator: Required only if using Oracle Financial Services Data Integration Hub
  • Database tier

    In this architecture, Oracle Autonomous Data Warehouse is used for the configuration schema and application (atomic) schema. An access control list (ACL) limits network access to the data warehouse to only the hosts in the middleware tier and the application tier.

    Oracle Autonomous Data Warehouse is a self-driving, self-securing, self-repairing database service that is optimized for data warehousing workloads. You do not need to configure or manage any hardware, or install any software. Oracle Cloud Infrastructure handles creating the database, as well as backing up, patching, upgrading, and tuning the database.

  • NAT gateway

    The NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.

  • Internet gateway

    The internet gateway allows traffic between the public subnets in a VCN and the public internet.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

  • Service gateway

    The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.


Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

  • Network design

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

    Use regional subnets.

  • Load balancer

    Choose an appropriate shape based on the number of simultaneous connections and the throughput required for your workload. Oracle recommends that you use DNS names.

  • Compute instances

    This architecture uses a single compute instance for the application tier and the middleware tier in each fault domain. Depending on your workload, decide the number of compute instances you need.

  • Block storage

    The compute instances in this architecture use regular block storage; no extra performance is required.

  • Network connectivity

    To enable your administrators to manage the environment, you can connect the cloud topology to your existing on-premises infrastructure by using site-to-site IPSec VPN connections or dedicated FastConnect circuits.

    If the cloud topology needs to be isolated from the on-premises infrastructure, you can deploy a bastion host to secure management access to the resources in the private subnets.

  • Security
    • Use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure proactively. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.

    • For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe, and denies operations that violate any of the policies.


When deploying Oracle Insurance Data Foundation in the cloud, consider the following factors:

  • Performance

    You can scale the performance of the architecture as needed. You can use larger shapes and add more instances to redistribute the load in the application tier and the middleware tier.

    Autoscaling is enabled by default when you create an instance of Oracle Autonomous Data Warehouse. You can also manually scale the database's base number of CPU cores up or down at any time. With autoscaling enabled, the database can use up to three times more CPU and IO resources without any manual intervention.

  • Security

    Use private subnets for all the resources except the bastion host and the public load balancer.

  • Availability

    In this architecture, redundant resources are provisioned in each layer across fault domains, ensuring high availability. You can adjust the architecture to distribute the resources across multiple regions.

    Your autonomous database is backed up automatically, and the backups are retained for 60 days. You can also create manual backups to supplement the automatic backups. Manual backups are stored in a bucket that you create in Oracle Cloud Infrastructure Object Storage. You can restore and recover the database to any point-in-time during the retention period. When you initiate a point-in-time recovery, Oracle Autonomous Data Warehouse determines uses the backup that enables faster recovery.

    Autonomous databases run on highly available Exadata infrastructure. For enhanced protection of your business' data against unforeseen disaster scenarios, consider enabling a standby database by using Autonomous Data Guard. This is an advanced feature, and is available only in 19c and higher versions. It's not available in the Always-Free tier.

  • Cost

    You can adjust the compute instances and database systems to use larger shapes when the load increases and shrink to smaller shapes when the load reduces.


  1. Set up the infrastructure resources shown in this reference architecture, by using the Oracle Cloud Infrastructure interface of your choice: web console, CLI, or API.
  2. Configure your application to use Oracle Autonomous Data Warehouse.
    Follow the instructions in the "Use Oracle Autonomous Data Warehouse as the Database for OIDF" section of Oracle Insurance Data Foundation Application Pack Installation and Configuration Guide.