Design Considerations

Network Isolation

You can attach the compute instances in your cloud topology to a private subnet or a public subnet, based on whether you want to permit access to the instances from the internet. A compute instance that you attach to a public subnet can be assigned a public IP address, and you can access the instance from the internet through the internet gateway. Compute instances attached to private subnets have only private addresses.

Scenario 1: Use Only Private Subnets
For production deployments that don't require internet-facing endpoints, attach all the resources to private subnets. The resources can't be accessed directly from the public internet. This type of deployment is useful when you want to deploy a hybrid topology, with the cloud topology being an extension to your on-premises data center.

To access the cloud topology from your on-premises environment, you can use IPSec VPN tunnels or FastConnect virtual circuits. Consider creating a bastion host, through which you can access all the servers attached to the private subnets.
Scenario 2: Use Both Public and Private Subnets
You can attach a few instances to a public subnet and the remainder to private subnets. This type of deployment is useful when the applications have both internet-facing endpoints and non-internet-facing endpoints.

For example, certain applications might be used by internal users, and other applications might serve external users. Attach the application instances that serve internal traffic to private subnets, and attach the application servers that serve external traffic to a public subnet.

Alternatively, for the internet-facing application instances, instead of attaching the application servers to a public subnet, you can use a public load balancer.

If you create a bastion host and attach it to a public subnet in this topology, then you can access the compute instances attached to the private subnets through the bastion host.
Scenario 2: Use Only Public Subnets
For quick trials or demonstrations, or for production-grade deployments that don't require internal endpoints, you can choose to attach all the resources to public subnets. This deployment is suitable if you don’t have your own data center, or you can’t access the cloud by using IPSec VPN tunnels or FastConnect virtual circuits. In this deployment, all the instances, including the application and database instances, are attached to public subnets. Every instance has a public IP address. You can regulate network access to the private resources by using security lists or network security groups.

To control administrative access to such a cloud topology, consider creating a bastion host, through which you can access all the servers in the topology. With this approach, you would open the administration ports to only the bastion host (and not to the public internet), by using security lists or network security groups.

High Availability

Ensure that your cloud topology has no single points of failure at any level: load balancers, web tier, application tier, and database tier.

The Oracle Cloud Infrastructure Load Balancing service creates a primary-standby pair of load balancer nodes. The nodes are deployed in separate availability domains. In regions that have a single availability domain, the load balancer nodes are created in separate fault domains. So the load balancer is not affected by hardware failures and data-center outages.
Provision redundant resources in the web tier, application tier, and database tier. If you decide to deploy the topology in a single availability domain, then you can distribute the resources across fault domains within the availability domain. If your region has multiple availability domains, then you can take advantage of the data-center isolation that such regions offer, and provision the production and redundant resources in separate availability domains.
For high availability of the databases, you can create a 2-node Virtual Machine DB system, which provides Oracle Real Applications Clusters (RAC). The two nodes are created in separate fault domains by default. You can explicitly choose a fault domain for the RAC nodes during database provisioning. So, the database nodes don't run on the same physical hardware. This deployment protects the databases against failures in the underlying physical hosts and the top-of-the-rack switch.
For disaster recovery, consider deploying a standby topology in a remote region.

Backup Strategy

Implement a robust backup strategy for the database and the applications, to enable efficient recovery of your data and applications in the event of any outage.

You can configure automatic and on-demand backups of your databases to Oracle Cloud Infrastructure Object Storage. All the database backups are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption. The automatic database backup service uses a weekly incremental backup strategy to backup databases, with a retention policy that you can customize.

For the applications, you can configure policy-based backups of the block volumes. Each backup policy has a predefined backup frequency and retention period. Choose a policy that helps you meet your compliance requirements and regulatory constraints.