Introduction
AWS Added Relational Database Services (RDS) to their service offering portfolio in the year 2009 starting by providing MySQL as a managed service. The service offering widened with Microsoft SQL and Oracle, Enterprise grade Databases MySQL , PostgreSQL and Maria DB, open source databases. As RDS adoption intensified, AWS introduced Cloud Relational Database, Aurora to their database stream with plenty of advanced features.
There are plethora of lighting features added to the RDS during last couple of years. Through this blog, I intend to organize these rich feature sets mapped with AWS Well Architecture framework pillars
*Why AWS Well Architecture Framework *
AWS Well Architecture Framework is a well-established architectural best practice for designing and operating application in secure, reliable, efficient and cost-effective, fashion in the AWS Cloud.
Centralized backup through AWS Backup
AWS backup is centralized and automated data protection services to backup RDS instances across your accounts and regions. It offers a cost-effective, fully managed, policy-based service that further simplifies data protection at scale.
Certain features to enhance the protection of your critical databases are :-
1) Multiple backups: - As per your organizations protection policy ,weekly, monthly and yearly dedicated full backups to be scheduled through AWS backup policies
2) Cross Region and Account replication: - You should protect one copy at a central and a dedicated account to restore in case of any account damages, Ransomware attacks or regional failure.
3) Backup Vault lock: - To protect for any accidental deletion of your backup copies as well as to adhere compliance requirements, protect backup vault as per the compliance policy.
Please refer this blog post for AWS backup capabilities. https://www.linkedin.com/pulse/how-sustain-from-ransomware-attacks-using-aws-backup-technics-nair/?trackingId=jJlZdHitYDTw6trbOS86%2FA%3D%3D
Monitoring and alert management
You should utilize “performance insight”, database aware deep monitoring capabilities along with the default AWS CloudWatch to monitor, record events and alert management for your RDS instances. “Performance insight” gives a single dashboard with detailed metrics like database load, active sessions, Wait Events, TOP SQL Statements etc.
To Learn more about Performance insight, Visit:- https://aws.amazon.com/rds/performance-insights/
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html
Log management
It is a best practice to store the database transaction logs for longer duration based on your company policy. By Default, these logs will be rotated based on the specific database engine configuration. You can publish Database logs to be stored on “AWS Cloud Watch Logs” .
Please refer this link to enable log publishing: - https://aws.amazon.com/premiumsupport/knowledge-center/rds-aurora-mysql-logs-cloudwatch/
Event Management
It is imperative to know the status /events of the RDS instances and act swiftly to curtail downtimes or inadvertently. AWS Event Subscription can be configured to alert status change in Snapshots, Instances, Security Group cluster and Parameter Group. Some of the best practice can be
Auto start and Stop using Systems manager
To drive best cost saving on your non-production RDS instance, configure Auto start and stop. In parallel, you can also manually stop RDS instance if they are not used .
Start and Stop using AWS Systems manager: - https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automatically-stop-and-start-an-amazon-rds-db-instance-using-aws-systems-manager-maintenance-windows.html
Amazon Aurora Autoscaling
Prepend compute power based on the real need, the foundational principle of Cloud computing has extended to the Amazon Aurora (both MySQL and PostGre SQL) through addition of “Replica” nodes in the cluster. When the connectivity or workload (CPU threshold) decreases, Aurora Auto Scaling removes unnecessary Aurora Replicas.
How to configure Aurora autoscaling:- https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html#Aurora.Integrating.AutoScaling.AddConsole
RDS High Availability and Disaster Recovery
Based on the RDS DB Engines (Aurora or others), distinct methodologies are available for High Availability. Both options use a replica/stand-by DB instance in distinct availability zone (in relation to the primary/master/writer DB instance), transparently and instantaneously switch from the primary/master DB instance in the event of a failure.
The default model for HA is provided within the region, however the DR capabilities can be extended across multiple regions using Replica/Read Replicas for both RDS and RDS Aurora. Read replicas can be created in any region/regions that asynchronously replicate change records from the master/primary instance. Converting the read replicas to Read/Write instance is activity needs to trigger in the DR scenario.
Aurora Global Databases
Aurora Global Database is a single Amazon Aurora database span across multiple AWS Regions. An Aurora global database has a primary DB cluster in one Region, and up to five secondary DB clusters in different Regions. Globally Distributed applications are regional failure are few use-cases where Aurora Global Database can be leveraged.
Aurora Fault Injection Simulator
You can test the fault tolerance of your Aurora PostgreSQL DB cluster by using fault injection queries. Fault injection queries are issued as SQL commands to an Amazon Aurora instance. Fault injection queries enable you to schedule simulated tests of the following events:
• Testing an instance crash
• Testing an Aurora Replica failure
• Testing a disk failure
• Testing disk congestion
When a fault injection query specifies a crash, it forces a crash of the Aurora PostgreSQL DB instance. The other fault injection queries result in simulations of failure events, but don't cause the event to occur. When you submit a fault injection query, you also specify an amount of time for the failure event simulation to occur.
AWS Native Security Controls
You can leverage AWS native security controls like Security Groups to protect at instance level, i.e you can control which source IP, Subnet, Security Group can communicate with your DB instance. While Security Group provides network level protection for your DB instances (RDS), Key Management Systems (KMS) provides encryption services for your DB instances. You can have your own Keys or customer generated key materials as features to enhance security controls.
AWS Identity and Access Control (IAM)
AWS IAM can be used to authenticate at the database level in addition to the default authentication capabilities at the RDS level (Platform). This credential management will be a better choice than management at the individual database layer. With this authentication method, you don't need to use a password when you connect to a DB instance. Instead, you use an authentication token. Which is a unique string of characters that Amazon RDS generates on request using AWS Signature Version 4 with lifetime of 15 minutes.
Please refer: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html
There are limitations for this feature, To know about limitation, please refer:- https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html#UsingWithRDS.IAMDBAuth.Availability
Secret Manager for RDS
AWS Secrets Manager protect secrets needed to access your RDS database instance. This service enables you to easily rotate, manage, and retrieve database credentials and other secrets throughout their lifecycle. This service eliminates the need of DB credentials stored as plan text in application configuration file.
To learn more and integration with RDS: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
SSL Enforcement on RDS instance
To enhance security, use SSL or Transport Layer Security (TLS) while connecting from your source systems to a DB instance running MySQL, MariaDB, Microsoft SQL Server, Oracle, or PostgreSQL. Amazon RDS creates an SSL certificate and installs the certificate on the DB instance that is signed by a Certificate Authority.
You must configure the RDS DB instance to accept ONLY SSL connection through RDS parameter group configuration, this ensures that any non-SSL connection attempts are always failed .
Note:- Each DB engine configuration will be different. The below screenshot is of MY SQL Parameter group.
The above configuration is of PostGreSQL 11.0
Read Replicas
Segregating read and write requests into separate databases (ensuring data consistency) is one of the models adopted to achieve best performance. Read replicas are available for MySQL, PostgreSQL , Maria DB and Aurora. To extend the capability of the Read Replicas for HA, we must deploy them into multiple Availability Zones (AZs), this provides AZ level failure protection
AWS Aurora supports load balancing of read replicas and quick conversion of read replica as writer instance in the event of master failure (HA). You can also independently scale replicas based on your read requirements.
Amazon Aurora Serverless
It was a breakthrough achievement when autoscaling on database succeeded, incredible value of cloud became reality when elasticity implemented in Database technologies through Serverless. With Aurora Serverless, you create a database, specify the desired database capacity range, and connect your applications. Amazon Aurora Serverless scales instantly to hundreds of thousands of transactions in a fraction of a second. As it scales, it adjusts capacity in fine-grained increments to provide the right amount of database resources that the application needs.
In case you want to explore serverless Aurora on your existing provisioned Aurora cluster, you can add a new Reader node as serverless. Through this model, you can leverage the capability of serverless in your existing Aurora cluster and learn how often the reader DB instances scale up and down.
Distinct strategies are being adopted in industry with the serverless, few use cases are applications that have infrequent, intermittent, or unpredictable workloads to the most demanding, business critical applications that require high scale and rapid incremental scale, unpredictable database capacity needs, Infrequent critical applications etc.
To learn more about Aurora serverless, please refer: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html
Conclusion
As detailed above, there are wealth of capabilities and features added to AWS RDS platform to superlatively support your application demand, scalability needs, security requirements and cost efficiency.
Top comments (0)