Enable private access to a fully managed, autonomous database in Oracle Cloud Infrastructure by provisioning the database with a private endpoint.
This architecture shows a public-facing Flask web server connected to an autonomous database with a private endpoint provisioned in Oracle Cloud Infrastructure.
Description of the illustration autonomous-db-private-endpoint.png
The architecture has the following components:
- Autonomous database, with a private endpoint
This architecture uses an autonomous database (which can be an Oracle Autonomous Transaction Processing database or an Oracle Autonomous Data Warehouse) provisioned in a private subnet; that is with a private endpoint.
A region is a localized geographic area composed of one or more availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or continents).
- Availability domains
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.
- Virtual cloud network (VCN) and subnets
A VCN is a software-defined network that you set up in an Oracle Cloud Infrastructure region. VCNs can be segmented into subnets, which can be specific to a region or to an availability domain. Both region-specific and availability domain-specific subnets can coexist in the same VCN. A subnet can be public or private.
In this architecture, the web server is attached to a public subnet, and the autonomous database is in a private subnet.
Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.
- Compute shapes
This architecture uses an Oracle Linux 7.7 compute instance with a VM.Standard2.1 shape for the Flask-based server. If the application needs more processing power, memory, or network bandwidth, then choose a larger shape.
When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using the Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range that's large enough for the required IP addresses. Use an address range that's within the standard private IP address space.
After you create a VCN, you can't change its address range.
- Autonomous database
In this architecture, the application stores relational data in an autonomous database. We recommend using the latest version of Oracle Database.
- Web-server scalability
You can scale your Flask application by using the compute instance pool and autoscaling features.
Instance pools let you provision and create multiple compute instances based on the same configuration, within the same region.
Autoscaling lets you automatically adjust the number of compute instances in an instance pool based on performance metrics, such as CPU utilization. Autoscaling helps you provide consistent performance for users during periods of high demand and helps you reduce cost during periods of low demand.
- Autonomous database scalability
You can manually scale the database's base number of CPU cores up or down at any time. The autoscaling feature allows your database to use up to three times the current base number of CPU cores at any time. As demand increases, autoscaling automatically increases the number of cores in use. You can scale the storage capacity of the database at any time without affecting availability or performance.
- Application availability
Fault domains provide the best resiliency within an availability domain. If you need higher availability, consider using multiple availability domains or multiple regions.
- Autonomous database backups
Your autonomous database is backed up automatically, and the backups are retained for 60 days. You can restore and recover the database to any point-in-time during the retention period.
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, and the backups are retained for 60 days.
- Compute backups
The Oracle Cloud Infrastructure Block Volumesservice lets you make point-in-time backups of data on a block volume. You can then restore the backups to new volumes either immediately or later.
You can also use the service to make a point-in-time, crash-consistent backup of a boot volume without application interruption or downtime. Boot volume backup capabilities are the same as block volume backup capabilities.
Use policies to restrict who can access your Oracle Cloud Infrastructure resources and what operations they can perform.
- Network security
The networking service offers two virtual firewall features that use security rules to control traffic at the packet level: security lists and network security groups (NSG).
An NSG consists of a set of ingress and egress security rules that apply to only a set of VNICs of your choice within a VCN. For example, an NSG can include the VNICs of all the compute instances in the web tier of a multitier application.
NSG security rules function the same as security list rules. However, for an NSG security rule's source or destination, you can specify an NSG instead of a CIDR block. So, you can easily write security rules to control traffic between two NSGs in the same VCN or traffic within a single NSG.
When you provision the autonomous database in Oracle Cloud Infrastructure, you can specify one or more NSGs. You can also update an existing database to use one or more NSGs.
The Terraform code to deploy this architecture is available on GitHub.
- Go to GitHub.
- Download or clone the code to your local computer.
- Follow the instructions in the README.