Amazon Aurora is fully managed relational database engine that’s compatible with MySQL and PostgreSQL.
With some workloads, Amazon Aurora can deliver up to five times the throughput of MySQL and up to three times the throughput of PostgreSQL.
Aurora includes a high-performance storage subsystem. The underlying storage grows automatically as needed, up to 128 terabytes. The minimum storage is 10GB.
Aurora will keep your database up-to-date with the latest patches.
Aurora supports quick, efficient cloning operations.
You can share your Amazon Aurora DB clusters with other AWS accounts for quick and efficient database cloning.
Aurora is fault-tolerant and self-healing.
Amazon Aurora is “AWS cloud optimized” and claims 5x performance improvement over MySQL on RDS, over 3x the performance of Postgres on RDS.
Aurora storage automatically grows in increments of 10GB, up to 64 TB.
Aurora can have 15 replicas while MySQL has 5, and the replication process is faster (sub 10 ms replica lag)
Failover in Aurora is instantaneous. It’s HA (High Availability) native.
Aurora costs more than RDS (20% more) – but is more efficient
An Aurora DB cluster consists of one or more DB instances and a cluster volume that manages the data for those DB instances.
An Aurora cluster volume is a virtual database storage volume that spans multiple AZs, with each AZ having a copy of the DB cluster data.
Primary DB instance – Supports read and write operations, and performs all of the data modifications to the cluster volume. Each Aurora DB cluster has one primary DB instance.
Aurora Replica – Connects to the same storage volume as the primary DB instance and supports only read operations. Each Aurora DB cluster can have up to 15 Aurora Replicas in addition to the primary DB instance. Aurora automatically fails over to an Aurora Replica in case the primary DB instance becomes unavailable. You can specify the failover priority for Aurora Replicas. Aurora Replicas can also offload read workloads from the primary DB instance.
Cluster endpoint – connects to the current primary DB instance for a DB cluster. This endpoint is the only one that can perform write operations. Each Aurora DB cluster has one cluster endpoint and one primary DB instance.
Reader endpoint – connects to one of the available Aurora Replicas for that DB cluster. Each Aurora DB cluster has one reader endpoint. The reader endpoint provides load-balancing support for read-only connections to the DB cluster. Use the reader endpoint for read operations, such as queries. You can’t use the reader endpoint for write operations.
Custom endpoint – represents a set of DB instances that you choose. When you connect to the endpoint, Aurora performs load balancing and chooses one of the instances in the group to handle the connection. You define which instances this endpoint refers to, and you decide what purpose the endpoint serves.
Instance endpoint – connects to a specific DB instance within an Aurora cluster. The instance endpoint provides direct control over connections to the DB cluster. The main way that you use instance endpoints is to diagnose capacity or performance issues that affect one specific instance in an Aurora cluster.
When you connect to an Aurora cluster, the host name and port that you specify point to an intermediate handler called an endpoint.
Benefits of Amazon Aurora
The benefits of Aurora remain the same for both MySQL compatible and PostgreSQL compatible.
- Scalability: Autoscaling feature can be enabled. Whenever your storage needs are increasing, it will automatically increase your database size and decreases the size when there is a major decrease in need for storage space.
- Cost-Effective: You only pay for the storage space, and processing power you use. There is no upfront costs and other costs. It is just simple monthly payments.
- Security: You can isolate your network where your database is running using Amazon VPC.
Usage of AWS Key management service to create encryption keys for protecting your data
- High Availability and Durability: Replicas of your Aurora can be created in multiple Availability zones.
It is a global database which can be distributed across multiple AWS regions which could reduce the local read/write speed.
- Migration Support: You can use pg-dump and mysql dump commands to migrate your local database into Aurora
- Fully Managed: Very easy to start with Aurora. You just have to start an instance with AWS RDS console or call a API in your code.
Aurora provides monitoring using Amazon Cloudwatch for no additional cost.
You do not need to worry about updating, upgrading, or provisioning. Everything is under Amazon’s control and they do all the software patching when required.
Features of Aurora:
- Automatic fail-over
- Backup and Recovery
- Isolation and security
- Industry compliance
- Push-button scaling
- Automated Patching with Zero Downtime
- Advanced Monitoring
- Routine Maintenance
- Backtrack: restore data at any point of time without using backups
Storage and Reliability in Amazon Aurora:
Aurora data is stored in the cluster volume, which is designed for reliability. A cluster volume consists of copies of the data across multiple Availability Zones in a single AWS Region.
Aurora automatically detects failures in the disk volumes that make up the cluster volume. When a segment of a disk volume fails, Aurora immediately repairs the segment. When Aurora repairs the disk segment, it uses the data in the other volumes that make up the cluster volume to ensure that the data in the repaired segment is current.
Aurora preloads the buffer pool with the pages for known common queries that are stored in an in-memory page cache when a database starts up after it has been shut down or restarted after a failure.
Aurora is designed to recover from a crash almost instantaneously and continue to serve your application data without the binary log. Aurora performs crash recovery asynchronously on parallel threads, so that your database is open and available immediately after a crash.
High Availability and Fault Tolerance in Amazon Aurora:
An Aurora DB cluster is fault tolerant by design. If the primary instance in a DB cluster fails, Aurora automatically fails over to a new primary instance in one of two ways:
By promoting an existing Aurora Replica to the new primary instance.
By creating a new primary instance.
Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically.
Aurora backs up your cluster volume automatically and retains restore data for the length of the backup retention period, from 1 to 35 days.
Aurora automatically maintains 6 copies of your data across 3 Availability Zones and will automatically attempt to recover your database in a healthy AZ with no data loss.
Aurora has a Backtrack feature that rewinds or restores the DB cluster to the time you specify.
Amazon Aurora Global Database:
An Aurora global database spans multiple AWS Regions, enabling low latency global reads and disaster recovery from region-wide outages.
Consists of one primary AWS Region where your data is mastered, and one read-only, secondary AWS Region.
Aurora global databases use dedicated infrastructure to replicate your data.
Aurora global databases introduce a higher level of failover capability than a default Aurora cluster.
An Aurora cluster can recover in less than 1 minute even in the event of a complete regional outage. This provides your application with an effective Recovery Point Objective (RPO) of 5 seconds and a Recovery Time Objective (RTO) of less than 1 minute.
Aurora Cross Region Read Replicas:
- Useful for disaster recovery
- Simple to put in place
Aurora Global Database (recommended):
- 1 Primary Region (read / write)
- Up to 5 secondary (read-only) regions, replication lag is less than 1 second
- Up to 16 Read Replicas per secondary region
- Helps for decreasing latency
- Promoting another region (for disaster recovery) has an RTO of < 1 minute
Amazon Aurora High Availability and Read Scaling:
- 6 copies of your data across 3 AZ:
3 copies out of 6 need for reads.
Self healing with peer-to-peer replication.
4 copies out of 6 needed for writes.
Storage is striped across 100s of volumes.
- One Aurora Instance takes writes (master)
- Automated failover for master in less than 30 seconds
- Support for Cross Region Replication
- Master + up to 15 Aurora Read Replicas serve reads
- Similar to RDS because uses the same engines
- Encryption at rest using KMS
- Automated backups, snapshots and replicas are also encrypted
- Encryption in flight using SSL (same process as MySQL or Postgres)
- Possibility to authenticate using IAM token (same method as RDS)
- You are responsible for protecting the instance with security groups
- You can’t SSH
Aurora Serverless is an on-demand, autoscaling configuration for Amazon Aurora (supports both MySQL and PostgreSQL). An Aurora Serverless DB cluster automatically starts up, shuts down, and scales up or down capacity based on your application’s needs.
A non-Serverless DB cluster for Aurora is called a provisioned DB cluster.
Aurora Serverless does not support fast failover, but it supports automatic multi-AZ failover.
Automated database instantiation and autoscaling based on actual usage.
Good for infrequent, intermittent or unpredictable workloads.
No capacity planning needed.
Pay per second, can be more cost-effective.
Limitations of Aurora Serverless:
Aurora Serverless supports specific MySQL and PostgreSQL versions only.
The port number for connections must be:
3306 for Aurora MySQL
5432 for Aurora PostgreSQL
You can’t give an Aurora Serverless DB cluster a public IP address. You can access an Aurora Serverless DB cluster only from within a virtual private cloud (VPC) based on the Amazon VPC service.
Each Aurora Serverless DB cluster requires two AWS PrivateLink endpoints. If you reach the limit for PrivateLink endpoints within your VPC, you can’t create any more Aurora Serverless clusters in that VPC.
A DB subnet group used by Aurora Serverless can’t have more than one subnet in the same Availability Zone.
Aurora Serverless doesn’t support the following features:
- Loading data from an Amazon S3 bucket
- Saving data to an Amazon S3 bucket
- Invoking an AWS Lambda function with an Aurora MySQL native function
- Aurora Replicas
- Multi-master clusters
- Database cloning
- IAM database authentication
- Restoring a snapshot from a MySQL DB instance
- Amazon RDS Performance Insights
Deletion protection is enabled by default when you create a production DB cluster using the AWS Management Console. However, deletion protection is disabled by default if you create a cluster using the AWS CLI or API.
Happy Learning !!