CloudiQS AWS RDS Deployment Guide
1. Overview
This guide provides step-by-step instructions for deploying CloudiQS applications using Amazon RDS (Relational Database Service) on AWS to maximize uptime and reliability.
It includes explanations of different deployment configurations (Single-AZ, Multi-AZ, and Multi-Region) and offers best practices to ensure your database is resilient and highly available.
2. Step-by-Step Deployment Instructions
2.1 Configuring Multi-AZ Deployment
Objective – Increase fault tolerance by automatically replicating your RDS database across multiple availability zones (AZs).
Instructions:
- Log into the AWS Management Console: Navigate to the RDS Dashboard.
- Create a New RDS Instance:
- Select the database engine (e.g., MySQL, PostgreSQL, MariaDB, Oracle, SQL Server).
- Choose the appropriate instance class based on your application’s requirements.
- Enable Multi-AZ Deployment:
- Under “Availability & durability”, select the Multi-AZ deployment option.
- AWS will automatically create a standby instance in a different AZ for automatic failover.
- Configure Storage and Performance:
- Choose the storage type (General Purpose SSD, Provisioned IOPS).
- Set the allocated storage and enable auto-scaling if needed.
- Launch the Instance: Review the configuration and launch the RDS instance. AWS will handle the setup and replication across AZs.
2.2 Setting Up Automated Backups
Objective: Ensure regular backups of your RDS database to protect against data loss.
Instructions:
- Enable Automated Backups:
- During the RDS instance creation, ensure that Automated backups are enabled.
- Specify the backup retention period (from 1 to 35 days).
- Configure Backup Window:
- Define a preferred backup window when database usage is low to minimize impact on performance.
- Manual Snapshots:
- In addition to automated backups, you can create manual snapshots for critical data before major updates or changes.
- Go to the RDS Dashboard, select the instance, and choose “Take Snapshot.”
2.3 Implementing Disaster Recovery
Objective: Prepare for data recovery in the event of a catastrophic failure by using cross-region replication and other strategies.
Instructions:
- Enable Cross-Region Read Replicas:
- Create a read replica of your RDS database in a different AWS region for disaster recovery.
- Select the RDS instance, choose “Actions”, and then “Create read replica”.
- Choose a different region and configure the replica as needed.
- Set Up Manual Failover:
- In the event of a disaster, promote the read replica to a standalone database by selecting “Promote Read Replica”.
- This will make the replica writable and ready to handle the application’s workload.
- Regular Testing:
- Periodically test your disaster recovery plan by simulating failover scenarios and verifying that the replica can be promoted without data loss.
3. Deployment Configurations
3.1 Single-AZ Deployment
Description: Deploy the RDS instance in a single availability zone.
Pros:
- Lower cost
- Simpler setup and management
Cons:
- Vulnerable to AZ-level failures
Recommended for: Development and testing environments.
3.2 Multi-AZ Deployment
Description: Distribute the RDS instance across multiple availability zones within the same region.
Pros:
- Higher availability and fault tolerance
- Automatic failover to the standby instance in case of an outage
Cons:
- Slightly higher cost
Recommended for: Production environments requiring high availability.
3.3 Multi-Region Deployment
Description: Deploy read replicas of the RDS instance in different regions.
Pros:
- Maximum fault tolerance and disaster recovery capabilities
- Improved latency for global users
Cons:
- Higher cost
- Complexity in data synchronization and management
Recommended for: Mission-critical applications requiring the highest level of redundancy and global reach.
4. Best Practices for Uptime and Reliability
- Enable Multi-AZ for Production Databases: Always enable Multi-AZ for production environments to ensure high availability.
- Automate Backups: Use automated backups and set an appropriate retention period to protect your data.
- Implement Cross-Region Replication: For critical applications, use cross-region replication to safeguard against regional outages.
- Monitor with Amazon CloudWatch: Set up detailed monitoring and alerts for your RDS instances to quickly respond to any issues.
5. RDS Instance Limits
Limitations:
- Maximum Number of RDS Instances – By default, up to 40 RDS DB instances can be created in a single AWS region. This limit includes all instance classes and database engines.
- Read Replicas – Each RDS instance supports a maximum of 5 read replicas. This applies to MySQL, PostgreSQL, and MariaDB engines.
- Multi-AZ Deployments – Only one standby instance is created in another AZ when Multi-AZ is enabled.
Note: CloudiQS can help to increase these limits can be increased by submitting a request to AWS Support.
6. Data Types and Replication Limits
Unsupported Data Types for Replication:
- BLOB/CLOB Data- Replication for large binary or character objects (BLOB/CLOB) may not be supported depending on the database engine and size of the data.
- Spatial Data – Certain spatial data types may not be fully supported for replication in MySQL or PostgreSQL.
- JSONB Data – Replication of JSONB data types may be restricted in specific versions of PostgreSQL.
Other Replication Limits:
- Replication Lag – Under high-load conditions, there may be a delay in data replication, especially in cross-region scenarios.
- Cross-Region Replication – Replication between regions may incur latency and additional costs, and is subject to network limitations.
