1. Amazon Aurora

1. Amazon Aurora is a fully managed relational database(not a key-value database) service.
2. Compatible only with MySQL and PostgreSQL database engines.
3. Support self-healing storage system.
4. Replicates data storage across 6 copies in 3 AZs, meaning each AZ gets 2 copies of data. This ensures high fault tolerance.
5. Data storage can scale up to 128TB per database instance.
6. Automatically scales in response to database growth, without manual intervention.
7. Allows to create up to 15 read replicas for a single database cluster to increased read throughput and high availability.
8. These read replicas are separate database instances that serve read-only queries. Replicas are synchronized with the primary instance using the shared Aurora storage layer.
9. During a failover, Aurora promotes a read replica to the primary instance automatically, ensuring minimal downtime.
10. Aurora uses priority tiers (0-15) to determine the order of read replica promotion. The replica with the lowest priority number (e.g., tier 0) is promoted first.
11. If multiple replicas share the same priority tier, Aurora promotes the largest instance size for optimized performance.
12. If replicas have the same tier and size, Aurora promotes one arbitrarily.
13. Provides continuous backups to Amazon S3, supporting point-in-time recovery for data safety.
14. Offers enhanced performance compared to traditional databases, with up to 5x faster throughput for MySQL and 3x faster for PostgreSQL.
15. Detects and repairs storage failures automatically, maintaining system health without user intervention.
16. Ensures data security with encryption at rest and in transit, and integrates with IAM for access control.
17. Aurora Read Replicas are independent endpoints in an Aurora DB cluster, best used for scaling read operations and increasing availability.

2. Aurora Global Database

Amazon Aurora Global Database is designed for globally distributed applications. It enables a single Amazon Aurora database to span multiple AWS regions, providing:

1. Global Data Replication: Data is replicated across multiple AWS regions without impacting the performance of the database.
2. Low Latency Reads: Allows fast local reads in each region.
3. Disaster Recovery: In case of a region-wide outage, automatically redirecting traffic to a healthy region.

3. Cloning Databases in an Aurora DB Cluster

1. Aurora enables fast database cloning, creating an exact copy of a database without duplicating data, using Copy-on-Write (CoW) technology.
2. CoW makes cloning faster and more storage-efficient compared to full backups/restores.
3. How Copy-on-Write (CoW) Works
   1. Initial State:
      1. The cloned and source databases share the same data blocks (read-only).
      2. No actual data copying occurs unless data is modified.
   2. Write on Clone:
      1. If the clone modifies data, CoW creates a new copy of the changed block.
      2. The source database remains unchanged.
   3. Write on Source:
      1. Similarly, changes to the source database affect only its own copy.
      2. The cloned database remains unaffected.
   4. Isolation:Shared blocks act as a baseline, but each database keeps independent copies of modified data.
4. Examples of CoW
   1. Aurora Cloning: Clone shares the source’s storage initially; changes are stored separately.
   2. Virtual Machines: Multiple VMs from the same image share storage until modifications are made.
5. Cloning vs. Backups
   1. Cloning: Fast and efficient for operational tasks like testing or analytics.
   2. Backups to S3: Suitable for long-term storage, compliance, or disaster recovery.
6. Question: A company runs its production database on an Aurora MySQL DB cluster and the performance testing team wants access to multiple test databases that must be re-created from production data.
   • Ans: Use database cloning to create multiple clones of the production database and use each clone as a test database

4. Aurora failover Handling

1. Amazon Aurora: Does not standby instances. Instead, it promotes one of its read replicas to primary during failover.
2. Amazon RDS: Provisions a standby instance (used only for failover) in Multi-AZ deployments.

Questions - EC2 Reserved Instances & Aurora DB

A company needs to migrate a legacy application from an on-premises data center to the AWS Cloud because of hardware capacity constraints. The application runs 24 hours a day & days a week. The application database storage continues to grow over time.

What should a solution architect do to meet these requirements MOST cost-affectivity?

1. Migrate the application layer to Amazon FC2 Spot Instances Migrate the data storage layer to Amazon S3.
2. Migrate the application layer to Amazon EC2 Reserved Instances Migrate the data storage layer to Amazon RDS On-Demand Instances.
3. Migrate the application layer to Amazon EC2 Reserved instances Migrate the data storage layer to Amazon Aurora Reserved Instances. (Correct Ans)
4. Migrate the application layer to Amazon EC2 On Demand Amazon Migrate the data storage layer to Amazon RDS Reserved instances.

Explanation:

1. Application Layer (Amazon EC2 Reserved Instances):
   • The application runs 24/7, indicating a steady and predictable workload. EC2 Reserved Instances provide significant cost savings (up to 75% compared to On-Demand Instances) for such consistent workloads by committing to a 1- or 3-year term.
   • Spot Instances are not suitable because they are interruptible and not ideal for a 24/7 application requiring high availability.
   • On-Demand Instances are more expensive than Reserved Instances for continuous workloads, making them less cost-effective.
   • Data Storage Layer (Amazon Aurora Reserved Instances):
2. The database storage grows over time, and Amazon Aurora is a managed, scalable, and cost-effective relational database service compatible with MySQL and PostgreSQL, suitable for legacy applications.
   • Aurora Reserved Instances offer cost savings for predictable database workloads, similar to EC2 Reserved Instances, and are more cost-effective than RDS On-Demand Instances.
   • Amazon S3 is not suitable for a relational database workload, as it is an object storage service, not a database engine.
   • RDS Reserved Instances could be an option, but Aurora is generally more cost-effective and scalable for growing storage needs due to its architecture (e.g., automatic storage scaling and lower I/O costs).