This whitepaper is for historical reference only. Some content might be outdated and some links might not be available.
# Architecting for security and performance
Whether you choose to run Oracle Database on Amazon RDS or Amazon EC2, optimizing every component of the infrastructure will enhance security, performance, and reliability. In the following sections, the best practices for optimizing network configuration, instance type, and database storage in an Oracle Database implementation on AWS are discussed.
**Topics**
+ [Network configuration](network-configuration.md)
+ [Amazon EC2 instance type](amazon-ec2-instance-type.md)
+ [Database storage](database-storage.md)
# Network configuration
With Amazon Virtual Private Cloud (Amazon VPC), you can provision a logically isolated section of the AWS Cloud that is dedicated to your account. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, security settings, and configuration of route tables and network gateways.
A *subnet* is a range of IP addresses in your Amazon VPC. You can launch AWS resources into a subnet that you select. Use a public subnet for resources that must be connected to the internet, and a private subnet for resources that won't be connected to the internet.
To protect the AWS resources in each subnet, you can use multiple layers of security, including security groups and network access control lists (ACLs).
The following table describes the basic differences between security groups and network ACLs.
| **Security group** | **Network ACL** |
| --- | --- |
| Operates at the instance level (first layer of defense) | Operates at the subnet level (second layer of defense) |
| Supports allow rules only | Supports allow rules and deny rules |
| Stateful: Return traffic is automatically allowed, regardless of any rules | Stateless: Return traffic must be explicitly allowed by rules |
| Evaluates all rules before deciding whether to allow traffic | Processes rules in numerical order when deciding whether to allow traffic |
| Applies to an instance only if someone specifies the security group when launching the instance, or associates the security group with the instance later on | Automatically applies to all instances in the subnets it's associated with (backup layer of defense, so you don't have to rely on someone specifying the security group) |
Amazon VPC provides isolation, additional security, and the ability to separate Amazon EC2 instances into subnets, and allows the use of private IP addresses. All of these are important in database implementation.
Deploy the Oracle Database instance in a private subnet and allow only application servers within the Amazon VPC, or a bastion host within the Amazon VPC, to access the database instance.
Create appropriate security groups that allow access only to specific IP addresses through the designated ports. These recommendations apply to Oracle Database regardless of whether you’re using Amazon RDS or Amazon EC2.
![\[Oracle Database in private subnet of an Amazon VPC\]](http://docs.aws.amazon.com/whitepapers/latest/oracle-database-aws-best-practices/images/oracle-db-private-subnet.png)
Oracle Database in private subnet of an Amazon VPC
# Amazon EC2 instance type
AWS has a large number of Amazon EC2 instance types available, so you can choose the instance type that best fits your workload. However, not all the available instance types are best suited for running Oracle Database.
If you use Amazon RDS for your Oracle Database, AWS filters out some of the instance types based on best practices, and gives you the various options in T- class, M-class and R-class instances. AWS recommends that you choose db.m- based or r-based Amazon RDS instances for any enterprise database workloads. R5 instances are well suited for memory intensive applications such as high-performance databases.
For the latest information about RDS instances, refer to [Amazon RDS for Oracle Database Pricing](https://aws.amazon.com/rds/oracle/pricing/). Your choice of the Amazon RDS instance type should be based on the database workload and the Oracle Database licenses available.
If you’re running your self-managed database on Amazon EC2, you have many more choices available for the Amazon EC2 instance type. This is often one of the reasons users opt to run Oracle Database on Amazon EC2 instead of using Amazon RDS.
Very small instance types are not suitable because Oracle Database is resource-intensive when it comes to CPU usage. Instances with a larger memory footprint help improve database performance by providing better caching and a bigger system global area (SGA). AWS recommends that you choose instances that have a good balance of memory and CPU.
Choose the instance type that matches the Oracle Database licenses you are planning to use and the architecture you are planning to implement. For architectures best suited for your business needs, refer to the whitepaper [Advanced Architectures for Oracle Database on Amazon EC2.](https://d1.awsstatic.com/whitepapers/aws-advanced-architectures-for-oracle-db-on-ec2.pdf)
Oracle Database uses disk storage heavily for read/write operations, so AWS highly recommends that you use only instances optimized for Amazon Elastic Block Store (Amazon EBS). Amazon EBS-optimized instances deliver dedicated throughput between Amazon EC2 and Amazon EBS. Bandwidth and throughput to the storage subsystem is crucial for good database performance. Choose instances with higher network performance for better database performance.
The following instance families are best suited for running Oracle Database on Amazon EC2.
| **Instance family** | **Features** |
| --- | --- |
| M family | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| X family | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| R family | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| I family | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| Z1d family | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
# Database storage
Most users typically use Amazon EBS for database storage. For some very high-performance architectures, you can use instance storage SSDs, but they should be augmented with Amazon EBS storage for reliable persistence.
For high and consistent IOPS and database performance, AWS highly recommends using General Purpose (GP2) volumes or Provisioned IOPS (PIOPS) volumes. GP2 and PIOPS volumes are available for both Amazon EC2 and Amazon RDS. Refer to [ Amazon RDS DB instance storage ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) for the latest limits of IOPS per volume for both GP2 and PIOPS volume types. GP2 volumes provide an excellent balance of price and performance for most database needs. When your database requires higher IOPS than what GP2 can provide, PIOPS volumes are the right choice.
For PIOPS volumes, you specify an IOPS rate when you create the volume, and Amazon EBS delivers within 10% of the Provisioned IOPS performance 99.9% of the time over a given year. The ratio of IOPS provisioned to the volume size requested can be a maximum of 30. For example, to get 3,000 IOPS your volume size should be at least 100 GB.
Similar to PIOPS volumes, GP2 volumes are also SSD-based, but the IOPS you get from GP2 volumes can vary from a baseline IOPS up to a maximum burstable 3,000 IOPS per volume. This works very well for most database workloads because the IOPS performance needed from the database varies many times during a period of time based on the load size and the number of queries being executed.
General Purpose (SSD) volume performance is governed by volume size, which dictates the base performance level of the volume and how quickly it accumulates I/O credits. Larger volumes have higher base performance levels and accumulate I/O credits faster.
I/O credits represent the available bandwidth that your General Purpose (SSD) volume can use to burst large amounts of I/O when more than the base performance is needed. The more credits your volume has for I/O, the more time it can burst beyond its base performance level and the better it performs when more performance is needed.
Throughput Optimized HDD volumes (st1) offers low-cost HDD volume designed for intensive workloads that require less IOPS but high throughput. Oracle databases used for data warehouses and data analytics purposes can leverage st1 volumes.
Any log processing or data staging areas like Oracle external tables or external BLOB storage that require high throughput can leverage st1 volumes. Throughput optimized (st1) volumes can handle max 500 IOPS per volume.
Cold HDD volumes (sc1) are suitable for handling legacy systems, which are kept around for occasional reference or archive purposes. These systems are accessed less frequently and a few scans are performed per day on the volume.
A good approach is to estimate the amount of IOPS consistently needed for your database, and allocate enough GP2 storage to obtain that many IOPS. Any additional IOPS needed for periodic spikes should be covered by the burst performance based on the available credits.
For information about estimation methods you can use to determine the IOPS needs of your Oracle Database, refer to the [Determining the IOPS Needs for Oracle Database on AWS](https://docs.aws.amazon.com/whitepapers/latest/determining-iops-needs-oracle-db-on-aws/determining-iops-needs-oracle-db-on-aws.html) whitepaper.
The burst duration of a volume is dependent on the size of the volume, the burst IOPS required, and the credit balance when the burst begins. If you notice that your volume performance is frequently limited to the base level (due to an empty I/O credit balance), you should consider using a larger General Purpose (SSD) volume (with a higher base performance level) or switching to a Provisioned IOPS (SSD) volume for workloads that require sustained IOPS performance greater than 10,000 IOPS. For additional details about GP2 volumes, refer to [Amazon EBS volume types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html).
For Amazon RDS, General Purpose (SSD) storage delivers a consistent baseline of 3 IOPS per provisioned GB and provides the ability to burst up to 3,000 IOPS. If you are already using magnetic storage for Amazon RDS, you can convert to General Purpose (SSD) storage, but you will encounter a short availability impact when doing so. Using Provisioned IOPS, you can provision up to the current maximum storage limit and the maximum IOPS per database instance.
Your actual realized IOPS may vary from the amount you provisioned based on your database workload, instance type, and database engine. For more information, refer to [Factors That Affect Realized IOPS Rates in the *Amazon RDS User Guide*](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
For Oracle Database on Amazon EC2, stripe multiple volumes together for more IOPS and larger capacity. You can use multiple Amazon EBS volumes individually for different data files, but striping them together allows better balancing and scalability.
Oracle Automatic Storage Management (ASM) can be used for striping. Keep data files, log files, and binaries on separate Amazon EBS volumes, and take snapshots of log file volumes on a regular basis. Choosing an instance type with local SSD storage allows you to boost the database performance by using Smart Flash Cache (if the operating system is Oracle Linux) and by using local storage for temporary files and table spaces.
For Oracle Database on VMware Cloud on AWS, vSAN provides necessary virtualized storage striped across the bare metal hosts. vSAN virtualized storage capability can be used in Oracle RAC for high-performance shared storage.
The VMDK (virtual machine disk) files created for Oracle RAC have to be provisioned for eager zero thick and be multi-writer flag enabled. VMware has published a [detailed performance study](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/solutions/oracle/vmw-oracle-performance-on-the-vmware-cloud-on-aws.pdf) for Oracle databases on VMware Cloud on AWS.