# Managing a Multi-AZ deployment for RDS Custom for Oracle
Managing a Multi-AZ deployment for RDS Custom for Oracle
**Note**
End of support notice: On March 31, 2027, Amazon will end support for Amazon RDS Custom for Oracle. After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. For more information, see [RDS Custom for Oracle end of support](RDS-Custom-for-Oracle-end-of-support.md).
In a Multi-AZ DB instance deployment for RDS Custom for Oracle, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone (AZ). The primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide data redundancy.
A Multi-AZ DB instance deployment enhances availability during planned system maintenance. If planned database maintenance or unplanned service disruption occurs, Amazon RDS automatically fails over to the up-to-date standby DB instance. Database operations can resume quickly without manual intervention. The primary and standby instances use the same endpoint, whose physical network address transitions to the standby replica as part of the failover process. You don't need to reconfigure your application when a failover occurs.
The following diagram shows the Multi-AZ architecture for RDS Custom for Oracle:
![\[Amazon RDS architecture with primary DB instance and standby replica in separate availability zones.\]](http://docs.amazonaws.cn/en_us/AmazonRDS/latest/UserGuide/images/custom-oracle-multiaz-architecture.png)
The Amazon RDS console shows the Availability Zone of the standby replica (the secondary AZ). You can also use the `describe-db-instances` CLI command or the `DescribeDBInstances` API operation to find the secondary AZ.
## Region and version availability for a Multi-AZ deployment for RDS Custom for Oracle
Region and version availability
Multi-AZ deployments for RDS Custom for Oracle are supported for the following releases for both Enterprise Edition (EE) and Standard Edition 2 (SE2):
+ Oracle Database 19c
+ Oracle Database 12c Release 2 (12.2)
+ Oracle Database 12c Release 1 (12.1)
**Note**
Multi-AZ deployments for RDS Custom for Oracle aren't supported on Oracle Database 18c.
Multi-AZ deployments for RDS Custom for Oracle are available in all Regions where RDS Custom for Oracle is available. For more information on Region availability of Multi-AZ deployments for RDS Custom for Oracle, see [Supported Regions and DB engines for RDS Custom for Oracle](Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.md#Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.ora).
## Limitations for a Multi-AZ deployment in RDS Custom for Oracle
Limitations
Multi-AZ deployments with RDS Custom for Oracle have the following limitations:
+ If your DB instance was created before June 30, 2025, you can't convert from a Single-AZ to Multi-AZ deployment. Your underlying Custom Engine Version (CEV) was built with an older service-provided AMI that lacks Multi-AZ support. You must migrate your database to a new DB instance using a CEV that you create with a service-provided AMI after June 30, 2025. For details, see [Migration steps for DB instances using CEVs created before June 30, 2025](custom-oracle-multiaz-prerequisites.md#migration-using-older-CEVs).
+ You can't create cross-Region Multi-AZ deployments.
+ You can't configure the standby DB instance to accept database read activity.
+ When you use a Custom Engine Version (CEV) with a Multi-AZ deployment, your standby DB instance uses the same CEV. The standby DB instance can't use a different CEV.
+ You can't create a read replica on a Multi-AZ deployment instance and you also cannot modify the primary instance of the read replica to have a Multi-AZ deployment.
+ RDS Custom for Oracle DB instances with Multi-AZ deployment can have increased write and commit latency compared to a Single-AZ deployment. This increase can happen because of the synchronous data replication between DB instances. You might have a change in latency if your deployment fails over to the standby replica, although Amazon is engineered with low-latency network connectivity between Availability Zones.
## Creating a Multi-AZ deployment in RDS Custom for Oracle
Creating a Multi-AZ deployment
To create an RDS Custom for Oracle DB instance with a Multi-AZ deployment, follow the steps in [Setting up your environment for Amazon RDS Custom for Oracle](custom-setup-orcl.md) to set up your environment with the prerequisites.
**Important**
To simplify setup, we recommend that you use the latest Amazon CloudFormation template file provided in the network setup instructions. For more information, see [Deploying RDS Custom for Oracle with Amazon CloudFormation](custom-oracle-multiaz-deployment.md).
You can create an RDS Custom for Oracle instance with a Multi-AZ deployment by choosing the **Multi-AZ** option during the database instance creation in the Amazon RDS console. Alternatively, you can specify the `--multi-az` parameter in the Amazon RDS `create-db-instance` command in the Amazon CLI.
# Prerequisites for a Multi-AZ deployment in RDS Custom for Oracle
Prerequisites
**Note**
End of support notice: On March 31, 2027, Amazon will end support for Amazon RDS Custom for Oracle. After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. For more information, see [RDS Custom for Oracle end of support](RDS-Custom-for-Oracle-end-of-support.md).
A Multi-AZ deployment for RDS Custom for Oracle is different from Multi-AZ for RDS for Oracle. Unlike Multi-AZ for RDS for Oracle, you must meet the prerequisites for RDS Custom for Oracle before you create your Multi-AZ DB instance. This is because RDS Custom runs inside your own account, which requires permissions. Also, you need to create the Multi-AZ instance on the CEV with the latest service-provided AMI, which supports the Multi-AZ deployments.
If you don't complete the prerequisites, your Multi-AZ DB instance might fail to run, or automatically revert to a Single-AZ DB instance. For more information about prerequisites, see [Prerequisites for a Multi-AZ deployment in RDS Custom for Oracle](#custom-oracle-multiaz-prerequisites).
RDS Custom for Oracle requires specific prerequisites when converting from Single-AZ to Multi-AZ deployment. Incomplete prerequisites cause Multi-AZ setup to fail. Use either manual setup or the latest Amazon CloudFormation template file provided in the network setup instructions. For more information, see [Step 3: Extract the CloudFormation templates for RDS Custom for Oracle](custom-setup-orcl.md#custom-setup-orcl.cf.downloading).
To complete the prerequisites manually, follow the steps in [Converting a Single-AZ deployment to a Multi-AZ deployment in RDS Custom for Oracle](custom-oracle-multiaz-modify-single-to-multi.md) and note the following:
+ Make sure your RDS Custom for Oracle DB instance uses a CEV created after June 30, 2025 with the latest service-provided AMI.
+ Update the Amazon RDS security group inbound and outbound rules to allow port 1120.
+ Create new Amazon SQS VPC endpoints that allow the Amazon RDS RDS Custom for Oracle DB instance to communicate with Amazon SQS.
+ Update the Amazon SQS permissions in the instance profile role.
**Important**
Don't reboot your Multi-AZ primary DB instance manually by logging into the instance without pausing RDS Custom for Oracle automation.
## Migration steps for DB instances using CEVs created before June 30, 2025
Migration for CEVs before 06.30.2025
If you created your RDS Custom for Oracle DB instance before June 30, 2025, you can't directly modify it to Multi-AZ deployment because the underlying CEV was built with an older service-provided AMI that lacks Multi-AZ support. You must migrate your database to a new instance using a CEV you create after June 30, 2025. Do the following for the migration.
1. **Create CEV from source** with the latest service-provided AMI (after June 30, 2025).
1. **Launch a new DB instance** with the new CEV.
1. **Migrate your database** from the existing DB instance that doesn’t support Multi-AZ deployment to the newly created instance using one of following methods:
+ [Physical migration of Oracle databases to Amazon RDS Custom using Data Guard](https://aws.amazon.com/blogs//database/physical-migration-of-oracle-databases-to-amazon-rds-custom-using-data-guard/)
+ [Physical migration of Oracle databases to Amazon RDS Custom using RMAN duplication](https://aws.amazon.com/blogs//database/physical-migration-of-oracle-databases-to-amazon-rds-custom-using-rman-duplication/)
# Converting a Single-AZ deployment to a Multi-AZ deployment in RDS Custom for Oracle
Converting Single-AZ to Multi-AZ
**Note**
End of support notice: On March 31, 2027, Amazon will end support for Amazon RDS Custom for Oracle. After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. For more information, see [RDS Custom for Oracle end of support](RDS-Custom-for-Oracle-end-of-support.md).
You can convert an existing multi-AZ compatible RDS Custom for Oracle instance from a Single-AZ deployment to a Multi-AZ deployment. When you modify the DB instance, Amazon RDS performs several actions:
+ Takes a snapshot of the primary DB instance.
+ Creates new volumes for the standby replica from the snapshot. These volumes initialize in the background, and maximum volume performance is achieved after the data is fully initialized.
+ Turns on synchronous block-level replication between the primary and standby DB instances.
**Important**
We recommend that you avoid modifying your RDS Custom for Oracle DB instance from a Single-AZ to a Multi-AZ deployment on a production DB instance during periods of peak activity.
Amazon uses a snapshot to create the standby instance to avoid downtime when you convert from Single-AZ to Multi-AZ, but performance might be impacted during and after converting to Multi-AZ. This impact can be significant for workloads that are sensitive to write latency. While this capability allows large volumes to quickly be restored from snapshots, it can cause increase in the latency of I/O operations because of the synchronous replication. This latency can impact your database performance.
## Configuring prerequisites to modify a Single-AZ to a Multi-AZ deployment using CloudFormation
Follow [Step 3: Extract the CloudFormation templates for RDS Custom for Oracle](custom-setup-orcl.md#custom-setup-orcl.cf.downloading) to setup your VPC and IAM profile again to add SQS VPC endpoint and SQS permission in IAM profile.
## Configuring prerequisites to modify a Single-AZ to a Multi-AZ deployment manually
If you choose to configure the prerequisites manually, perform the following tasks.
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)
1. Choose **Endpoint**. The **Create Endpoint** page appears.
1. For **Service Category**, choose **Amazon services**.
1. In **Services**, search for `SQS`.
1. In **VPC**, choose the VPC where your RDS Custom for Oracle DB instance is deployed.
1. In **Subnets**, choose the subnets where your RDS Custom for Oracle DB instance is deployed.
1. In **Security Groups**, choose the security group where your RDS Custom for Oracle DB instance is deployed.
1. For **Policy**, choose **Custom**.
1. In your custom policy, replace the `AWS partition`, `Region`, `accountId`, and `IAM-Instance-role` with your own values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Condition": {
"StringLike": {
"aws:ResourceTag/AWSRDSCustom": "custom-oracle"
}
},
"Action": [
"SQS:SendMessage",
"SQS:ReceiveMessage",
"SQS:DeleteMessage",
"SQS:GetQueueUrl"
],
"Resource": "arn:aws-cn:sqs:us-east-1:111122223333:do-not-delete-rds-custom-*",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws-cn:iam::111122223333:role/{IAM-Instance-role}"
}
}
]
}
```
------
Update the **Instance profile** with permission to access Amazon SQS. Replace the `AWS partition`, `Region`, and `accountId` with your own values.
```
{
"Sid": "13",
"Effect": "Allow",
"Action": [
"SQS:SendMessage",
"SQS:ReceiveMessage",
"SQS:DeleteMessage",
"SQS:GetQueueUrl"
],
"Resource": [
{
"Fn::Sub": "arn:${AWS::Partition}:sqs:${AWS::Region}:${AWS::AccountId}:do-not-delete-rds-custom-*"
}
],
"Condition": {
"StringLike": {
"aws:ResourceTag/AWSRDSCustom": "custom-oracle"
}
}
}
```
Update the Amazon RDS security group inbound and outbound rules to allow port 1120.
+ In **Security Groups**, choose the group where your RDS Custom for Oracle DB instance is deployed.
+ For **Inbound Rules**, create a **Custom TCP** rule to allow port `1120` from the source group.
+ For **Outbound Rules**, create a **Custom TCP** rule to allow port `1120` to the destination group.
## Modify using the RDS console, Amazon CLI, or RDS API
After you've completed the prerequisites, you can modify an RDS Custom for Oracle DB instance from a Single-AZ to Multi-AZ deployment using the Amazon RDS console, Amazon CLI, or Amazon RDS API.
### Console
**To modify an existing RDS Custom for Oracle Single-AZ to Multi-AZ deployment**
1. Sign in to the Amazon Management Console and open the Amazon RDS console at [https://console.amazonaws.cn/rds/](https://console.amazonaws.cn/rds/).
1. In the Amazon RDS console, choose **Databases**. The **Databases** pane appears.
1. Choose the RDS Custom for Oracle DB instance that you want to modify.
1. For **Actions**, choose **Convert to Multi-AZ deployment**.
1. On the **Confirmation** page, choose **Apply immediately** to apply the changes immediately. Choosing this option doesn't cause downtime, but there is a possible performance impact. Alternatively, you can choose to apply the update during the next maintenance window. For more information, see [Using the schedule modifications setting](USER_ModifyInstance.ApplyImmediately.md).
1. On the **Confirmation** page, choose **Convert to Multi-AZ**.
### Amazon CLI
To convert to a Multi-AZ DB instance deployment by using the Amazon CLI, call the [modify-db-instance](https://docs.amazonaws.cn//cli/latest/reference/rds/modify-db-instance.html) command and set the `--multi-az` option. Specify the DB instance identifier and the values for other options that you want to modify. For information about each option, see [Settings for DB instances](USER_ModifyInstance.Settings.md).
**Example**
The following code modifies `mycustomdbinstance` by including the `--multi-az` option. The changes are applied during the next maintenance window by using `--no-apply-immediately`. Use `--apply-immediately` to apply the changes immediately. For more information, see [Using the schedule modifications setting](USER_ModifyInstance.ApplyImmediately.md).
For Linux, macOS, or Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mycustomdbinstance \
--multi-az \
[--no-apply-immediately | --apply-immediately]
```
For Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mycustomdbinstance ^
--multi-az ^
[--no-apply-immediately | --apply-immediately]
```
### RDS API
To convert to a Multi-AZ DB instance deployment with the Amazon RDS API, call the [ModifyDBInstance](https://docs.amazonaws.cn/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) operation and set the `MultiAZ` parameter to true.
# Converting a Multi-AZ deployment to a Single-AZ deployment in RDS Custom for Oracle
Converting Multi-AZ to Single-AZ
**Note**
End of support notice: On March 31, 2027, Amazon will end support for Amazon RDS Custom for Oracle. After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. For more information, see [RDS Custom for Oracle end of support](RDS-Custom-for-Oracle-end-of-support.md).
You can modify an existing RDS Custom for Oracle DB instance from a Multi-AZ to a Single-AZ deployment.
## Console
**To modify an RDS Custom for Oracle DB instance from a Multi-AZ to Single-AZ deployment**
1. Sign in to the Amazon Management Console and open the Amazon RDS console at [https://console.amazonaws.cn/rds/](https://console.amazonaws.cn/rds/).
1. In the Amazon RDS console, choose **Databases**. The **Databases** pane appears.
1. Choose the RDS Custom for Oracle DB instance that you want to modify.
1. For **Multi-AZ deployment**, choose **No**.
1. On the **Confirmation** page, choose **Apply immediately** to apply the changes immediately. Choosing this option doesn't cause downtime, but there is a possible performance impact. Alternatively, you can choose to apply the update during the next maintenance window. For more information, see [Using the schedule modifications setting](USER_ModifyInstance.ApplyImmediately.md).
1. On the **Confirmation** page, choose **Modify DB Instance**.
## Amazon CLI
To modify a Multi-AZ deployment to a Single-AZ deployment by using the Amazon CLI, call the [modify-db-instance](https://docs.amazonaws.cn//cli/latest/reference/rds/modify-db-instance.html) command and include the `--no-multi-az` option. Specify the DB instance identifier and the values for other options that you want to modify. For information about each option, see [Settings for DB instances](USER_ModifyInstance.Settings.md).
**Example**
The following code modifies `mycustomdbinstance` by including the `--no-multi-az` option. The changes are applied during the next maintenance window by using `--no-apply-immediately`. Use `--apply-immediately` to apply the changes immediately. For more information, see [Using the schedule modifications setting](USER_ModifyInstance.ApplyImmediately.md).
For Linux, macOS, or Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mycustomdbinstance \
--no-multi-az \
[--no-apply-immediately | --apply-immediately]
```
For Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mycustomdbinstance ^
--no-multi-az ^
[--no-apply-immediately | --apply-immediately]
```
## RDS API
To modify a Multi-AZ deployment to a Single-AZ deployment by using the Amazon RDS API, call the [ModifyDBInstance](https://docs.amazonaws.cn/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) operation and set the `MultiAZ` parameter to `false`.
# Customizing the OS in an RDS Custom for Oracle Multi-AZ deployment
OS customization
**Note**
End of support notice: On March 31, 2027, Amazon will end support for Amazon RDS Custom for Oracle. After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. For more information, see [RDS Custom for Oracle end of support](RDS-Custom-for-Oracle-end-of-support.md).
With RDS Custom for Oracle Multi-AZ deployments, you can customize the operating system and install third-party software on both primary and standby EC2 instances. Unlike Amazon RDS, RDS Custom for Oracle provides administrative access to the database environment and underlying operating system, allowing you to install monitoring tools, security agents, or custom applications in addition to Oracle databases.
When you customize the OS on a Multi-AZ deployment, you're responsible for ensuring that customizations exist on both primary and standby instances. This approach ensures application continuity during Multi-AZ failover and maintains consistent functionality across both instances.
## Requirements for customizing the OS in an RDS Custom for Oracle Multi-AZ deployment
OS customization requirements
Before you customize the OS in a Multi-AZ deployment, be aware of the following requirements:
+ Install third-party software only on the `/rdsdbdata` mount point. The data volume (`/rdsdbdata`) is the only data that is replicated in a Multi-AZ deployment. The root volume (`/`) is replaced during OS patching, and the binary volume (`/rdsdbbin`) is replaced during database patching. Software installed on the root and binary volumes is lost during patching.
+ Ensure all customizations comply with Amazon and Oracle licensing terms and conditions.
+ Before you convert from Single-AZ to Multi-AZ, make sure the HugePages settings in `/etc/sysctl.conf` work correctly.
## Identifying EC2 instances in an RDS Custom for Oracle Multi-AZ deployment
Identifying EC2 instances
When customizing your Multi-AZ instances, identify which Amazon EC2 instances serve as the primary and standby for your RDS Custom for Oracle deployment.
**To identify primary and standby EC2 instances**
1. Open the Amazon RDS console at [https://console.amazonaws.cn/rds/](https://console.amazonaws.cn/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose your Multi-AZ RDS Custom for Oracle DB instance.
1. In the **Configuration** section, note the **Resource ID** (format: `db-nnnnnnn`).
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. In the navigation pane, choose **Instances**.
1. In the search box, enter the Resource ID from step 4.
1. The search results show two instances: your primary and secondary. The instance with the active RDS Custom for Oracle database is the primary.
## Customizing the OS before creating an RDS Custom for Oracle Multi-AZ deployment
Customizing the OS before deploying Multi-AZ
In this scenario, your current deployment is a Single-AZ DB instance. You can customize the OS and then convert your DB instance to a Multi-AZ deployment. If you're installing third-party software, and you have modified files on multiple volumes, this technique is recommended.
**To customize the OS before converting your Single-AZ to Multi-AZ**
1. Connect to the EC2 instance in your Single-AZ deployment using Amazon Systems Manager Session Manager or SSH.
1. Perform either of the following customizations:
+ Install third-party software on the data volume (`/rdsdbdata`).
+ Customize files on the root volume (`/`).
1. Test your software or root volume customizations to ensure they work correctly.
1. Convert the Single-AZ DB instance to a Multi-AZ deployment by following the instructions in [Converting a Single-AZ deployment to a Multi-AZ deployment in RDS Custom for Oracle](custom-oracle-multiaz-modify-single-to-multi.md).
1. Verify that your customizations exist on both instances in the Multi-AZ deployment. For more information, see [Identifying EC2 instances in an RDS Custom for Oracle Multi-AZ deployment](#cfo-os-maz-identify-instances).
## Customizing the OS after creating an RDS Custom for Oracle Multi-AZ deployment
Customizing the OS after deploying Multi-AZ
If you have an exiting Multi-AZ deployment, you can deploy your customizations using Amazon Systems Manager or using manual techniques.
### Customizing the OS in a Multi-AZ deployment using Amazon Systems Manager
Customizing the OS using Systems Manager
For existing Multi-AZ DB instances, we recommend Systems Manager as the most reliable way to apply customizations simultaneously to both primary and standby instances. This approach ensures consistency. For a general introduction to this service, see [What is Amazon Systems Manager?](https://docs.amazonaws.cn/systems-manager/latest/userguide/what-is-systems-manager.html). To learn how to install software on both DB instances simultaneously, see [Install or update Distributor packages](https://docs.amazonaws.cn/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html).
### Customizing the OS in a Multi-AZ deployment manually
Customizing the OS manually
In this scenario, your Multi-AZ deployment already exists, but you don't use Amazon Systems Manager to deploy the customizations. You can customize your OS manually in either of the following ways:
**Customize the OS on the primary instance and replicate the changes**
Multi-AZ deployment automatically replicates the `rdsdbdata` volume. You can customize the OS in the following ways:
+ Install third-party software directly on the `/rdsdbdata` mount point.
+ To modify files on the root volume (`/`), create files on the data volume and then create a symbolic link from the root volume files to the data volume files.
**Customize the OS on the primary and standby instances separately**
In this approach, you customize the OS on the primary instance. Then you perform the same customizations on the standby instance.
**To customize the OS on the primary instance so that they are replicated automatically**
1. Identify the primary and standby DB instances using the procedure in [Identifying EC2 instances in an RDS Custom for Oracle Multi-AZ deployment](#cfo-os-maz-identify-instances).
1. Connect to the primary EC2 instance using Session Manager or SSH.
1. Use either of the following techniques, depending on your business requirements:
**Install third-party software**
Install your software on the `/rdsdbdata` mount point.
```
sudo mkdir -p /rdsdbdata/custom-software
cd /rdsdbdata/custom-software
# Install your software here
```
**Customize the root volume**
Create symbolic links from OS configuration files on the root volume to files on the data volume. For example, create file `/rdsdbdata/customizations/sysctl.conf`, and then create a symbolic link at `/etc/sysctl.conf` that points to `/rdsdbdata/customizations/sysctl.conf`.
```
sudo mkdir -p /rdsdbdata/customizations
sudo mv /etc/sysctl.conf /rdsdbdata/customizations/sysctl.conf
sudo ln -sf /rdsdbdata/customizations/sysctl.conf /etc/sysctl.conf
```
1. Test your software or root volume customizations to ensure they work correctly.
1. Connect to the standby instance and verify that the synchronous replication has copied your software or root volume customizations to the `/rdsdbdata` directory.
## Customizing the binary volume in an RDS Custom for Oracle Multi-AZ deployment
Customizing the binary volume
You can apply a database patch to the binary volume (`/rdsdbbin`) in an RDS Custom for Oracle Multi-AZ deployment. You must apply the patch to the primary and standby instances. Consider the following guidelines:
+ When you perform a one-off patch, we recommend that you create a new CEV with the new one-off patch included in the manifest.
+ To apply a one-off patch manually, make sure to unzip the one-off patch in both the primary and secondary EC2 instances. Applying the patch and running `datapatch` is required only on the primary Multi-AZ instance.
+ If you patch the database using a different CEV, the binary volume is replaced. Make sure to include the one-off patch in the manifest of the new CEV.
## Best practices for customizing the OS
Follow these best practices when customizing the OS on RDS Custom for Oracle Multi-AZ instances:
**Test in non-production environments**
Always test customizations in a non-production environment before applying them to production instances.
**Document all changes**
Maintain detailed documentation of all customizations for future reference and troubleshooting. We recommend that you store your customizations in a script that you can be applied anytime, just in case.
**Verify on both instances**
Regularly verify that customizations are present and functioning correctly on both primary and standby instances.
**Use Systems Manager for consistency**
Use Systems Manager for consistent application of changes across instances, especially for existing Multi-AZ deployments.
# Deploying RDS Custom for Oracle with Amazon CloudFormation
Deploy with Amazon CloudFormation
**Note**
End of support notice: On March 31, 2027, Amazon will end support for Amazon RDS Custom for Oracle. After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. For more information, see [RDS Custom for Oracle end of support](RDS-Custom-for-Oracle-end-of-support.md).
Automate your RDS Custom for Oracle deployment using the provided Amazon CloudFormation template. Complete the following prerequisites before deploying the resources.
## Prerequisites
Prerequisites
**Download required Oracle files**
You need specific Oracle installation files before you can create the Amazon CloudFormationtemplate. Download these files before you deploy.
1. Navigate to [Oracle Database 19c (19.3)](https://www.oracle.com/database/technologies/oracle19c-linux-downloads.html)
1. Locate and download the file `LINUX.X64_193000_db_home.zip`
1. Rename the file to`V982063-01.zip`
1. Download the remaining patches, selecting **Platform or Language** as `Linux x86-64`
### Latest OPatch utility
OPatch
[Patch 6880880](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=6880880)
### January 2023 PSU Patches
January 2023 Patches
**Database PSU & RU Patches**
+ [Patch 34765931](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=34765931)
+ [Patch 34786990](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=34786990)
**Additional Required Patches**
+ [Patch 35099667](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=35099667)
+ [Patch 35099674](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=35099674)
+ [Patch 28730253](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=28730253)
+ [Patch 29213893](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=29213893)
+ [Patch 35012866](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=35012866)
### April 2023 PSU Patches
April 2023 Patches
**Database PSU & RU Patches**
+ [Patch 35042068](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=35042068)
+ [Patch 35050341](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=35050341)
**Additional Required Patches**
+ [Patch 28730253](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=28730253)
+ [Patch 29213893](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=29213893)
+ [Patch 33125873](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=33125873)
+ [Patch 35220732](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=35220732)
+ [Patch 35239280](https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=35239280)
### Amazon S3 bucket setup
Amazon S3 setup
1. Create an Amazon S3 bucket in your Amazon Web Services account, or choose an existing bucket.
1. Create a folder structure in the bucket similar to example below.
```
/
└── oracle_cev/
├── V982063-01.zip
├── p6880880_190000_Linux-x86-64.zip
├── p34765931_190000_Linux-x86-64.zip
├── p34786990_190000_Linux-x86-64.zip
├── p35099667_190000_Linux-x86-64.zip
├── p35099674_190000_Generic.zip
├── p28730253_190000_Linux-x86-64.zip
├── p29213893_1918000DBRU_Generic.zip
├── p35012866_1918000DBRU_Linux-x86-64.zip
├── p35042068_190000_Linux-x86-64.zip
├── p35050341_190000_Linux-x86-64.zip
├── p29213893_1919000DBRU_Generic.zip
├── p33125873_1919000DBRU_Linux-x86-64.zip
├── p35220732_190000_Linux-x86-64.zip
└── p35239280_190000_Generic.zip
```
1. Upload all of Oracle files that you previously downloaded to the appropriate folders.
## Deploy RDS Custom for Oracle using Amazon CloudFormation
Deployment steps
### Step 1: Prepare the Amazon CloudFormation template
Before you can deploy RDS Custom for Oracle, you need to download and configure the Amazon CloudFormation template that creates the necessary prerequisites.
**Copy and save the template**
1. Go to [Deploying RDS Custom for Oracle with single and multiple Availability Zones](https://docs.amazonaws.cn/AWSCloudFormation/latest/TemplateReference/aws-resource-rds-dbinstance.html#aws-resource-rds-dbinstance--examples--Deploying_RDS_Custom_for_Oracle_with_single_and_multiple_Availability_Zones)
1. Copy the template in your preferred format (YAML or JSON)
1. Save the file in YAML or JSON format. For example, `rds-custom-oracle-prereqs.yaml`
**Launch the stack in the Amazon console**
1. Open the Amazon Console and navigate to Amazon CloudFormation
1. Choose **Create stack** > **With new resources (standard)**
1. Select **Choose an existing template**
1. Select **Upload a template file** > **Choose file**
1. Select the template file you previously downloaded
1. Keep the default parameter values
1. Select **Next** to create the stack
**Alternative: Using Amazon CLI**
Instead of using the console, you can create the stack using the Amazon CLI:
```
aws cloudformation create-stack \
--stack-name rds-custom-oracle \
--template-body file://rds-custom-oracle-prereqs.yaml \
--capabilities CAPABILITY_NAMED_IAM
```
### Step 2: Create the Custom Engine Versions (CEVs) and Amazon RDS instances
Step 2: Create CEVs and Amazon RDS instances
**Copy and save the template**
1. Go to [Deploying RDS Custom for Oracle with single and multiple Availability Zones](https://docs.amazonaws.cn/AWSCloudFormation/latest/TemplateReference/aws-resource-rds-dbinstance.html#aws-resource-rds-dbinstance--examples--Deploying_RDS_Custom_for_Oracle_with_single_and_multiple_Availability_Zones)
1. Copy the template in your preferred format (YAML or JSON)
1. Update the following parameters in the template if needed:
+ `BucketName`
+ `CEVS3Prefix`
+ Database master password (replace \$1\$1\$1\$1\$1\$1\$1\$1\$1\$1\$1\$1\$1)
1. Save the file in YAML or JSON format
### Step 3: Deploy using the Amazon console
Step 3: Console deployment
1. Open the Amazon Console and navigate to Amazon CloudFormation
1. Choose **Create stack** > **With new resources (standard)**
1. Select **Choose an existing template**
1. Select **Upload a template file** > **Choose file**
1. Select the template file you previously downloaded
1. Leave the parameters as default values
1. Fill in the parameters as follows:
```
BucketName: rds-custom-id
CEVS3Prefix: oracle_cev
CEVCreation: Yes
```
1. Review the configuration and select **Next** to create the stack
**Optional: Deploy Using Amazon CLI**
```
aws cloudformation create-stack \
--stack-name rds-custom-oracle \
--template-body file://rds-custom-oracle.yaml \
--parameters \
ParameterKey=BucketName,ParameterValue=rds-custom-id \
ParameterKey=CEVS3Prefix,ParameterValue=oracle_cev \
ParameterKey=CEVCreation,ParameterValue=Yes \
--capabilities CAPABILITY_NAMED_IAM
```
## Deployment resources created
Resources Created
The template creates the following resources:
+ Amazon VPC with public and private subnets
+ Security groups
+ Amazon VPC endpoints
+ IAM roles and policies
+ Amazon KMS key for encryption
+ Custom Engine Versions (CEVs)
+ RDS Custom for Oracle instances for both single-AZ and multi-AZ configurations
## Monitor your deployment progress
After you create the Amazon CloudFormation stack, monitor its progress to ensure successful deployment. The deployment process includes creating Custom Engine Versions (CEVs) and RDS instances.
To monitor deployment progress:
1. Open the Amazon CloudFormation console.
1. Choose your stack name.
1. Choose the **Events** tab to view progress and identify any errors.
**Note**
CEV creation typically requires 2-3 hours. After CEV creation completes successfully, Amazon RDS automatically begins creating the Amazon RDS instance.
## Post-Deployment
Post-Deployment
After the stack creation process completes, perform the following post-deployment verification and configuration steps:
1. From the Amazon RDS console page, navigate to **Custom engine versions** to verify CEV creation.
1. Confirm Amazon RDS instances are created and available
1. Test connectivity to the Amazon RDS instances
1. Set up monitoring and backup strategies as needed
## Cleanup
Cleanup
To remove all resources, run the following Amazon CLI command:
```
aws cloudformation delete-stack --stack-name rds-custom-oracle
```
## Troubleshooting
Troubleshooting
If you encounter issues during deployment, use the following solutions to resolve common problems.
CEV creation fails
+ Verify all required patches are uploaded to Amazon S3
+ Check IAM permissions
+ Verify the patch versions are correct; see the [Prerequisites](#custom-oracle-prerequisites) for the list of required patches.
Amazon RDS instance creation fails
+ Check VPC/subnet configurations
+ Verify security group rules
+ Confirm CEV is available