Episode 9: AWS Databases: RDS, Aurora & ElastiCache Deep Dive | SAA-C03 Exam Prep

Hey everyone, Balu here, welcome back to Tech Talk with Balu, your complete guide to Asing the AWS Solutions Architect Associate Exam. We are on Episode 9 and today we are diving into AWS Databases, specifically Rora and Elastic Cash. If you're building applications on AWS, you need databases and understanding which database service to use is absolutely critical. Here's why this matters. Databases are the heart of most applications. You choose the wrong database service and you get slow performance, high cost or data loss during failures. Choose the right one and you get high availability, great performance and automatic scaling. So today we are covering three managed database services. Number one is Ardeus, which is relational database service. That's managed my SQL PostgreSQL Oracle or SQL Server. Then we are covering Aurora, which is AWS's proprietary high performance database. And finally we are covering Elastic Cash, which is an in-memory caching with Redis and Memcached. We will cover what each service is when to use it, how multi-az works for high availability, read replicas for scaling reads, backup and restore strategies, security and of course exam traps. By the end of this episode, you will know exactly which database service to choose for any scenario, how to design for high availability and how to scale database workloads. So let's dive straight in. Let's start with Ardeus, relational database service. So what is Ardeus? Ardeus is AWS's managed relational database service. It supports six database engines, PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server and Aurora. Aurora is actually a separate product so we will cover it in detail later. This is for databases that use SQL as a query language, think traditional relational databases with tables, rows, columns, primary keys, foreign keys, the databases you're already familiar with. Now what does the term managed mean? When you run a database on easy to yourself, you're responsible for everything, installing the database software, applying the patches, taking backups, setting up replication, monitoring, handling failures and all of that. Now with Ardeus, AWS manages all of that for you. Here's what AWS handles automatically. Automated provisioning, Ardeus sets up the database for you. You choose your engine, instant size, storage and you're done. Always patching. AWS automatically patches the operating system and database software during maintenance windows you define. Continuous backups. Ardeus automatically takes backups every day during a backup window plus it backs up transaction logs every five minutes, giving you point in time restore capability, point in time restore. You can restore your database to any point in time within your backup retention period. That's if someone accidentally deleted a table at 247 pm, no problem. You restore it to 246 pm and you get the database back monitoring dashboards. This provides cloud watch metrics showing CPU, memory, disk IO operations, connections and more. Read replicas, easily create read replicas to scale your read workload. It provides a multi easy setup that means it automatically fail overs to a standby database in another availability zone for disaster recovery. It provides maintenance windows that's to schedule when upgrades happen so they don't impact production during peak hours. It also provides scaling capability that scale up to larger instance types vertically. Scale reads horizontally with read replicas. It provides storage backed by eBS that's your data lives on reliable eBS volumes with automatic backups. Now here is the trade off. You cannot SSH into your ardeus instances. They are fully managed by AWS. You don't have operating system access. If you need that level of control you have to use EC2 and run the database yourself or use RDS custom which gives you OS access for Oracle and SQL server. So for the exam remember, RDS is managed. You get automation and high availability but you lose low level control. Now when do you use RDS? You want to use RDS when you need a relational database and want AWS to handle the operational overhead. Most production applications use ardeus instead of self-managed databases on EC2. You would use EC2 with self-managed databases only when you need very specific custom database configurations or you need OS level access. Now let's talk about read replicas. This is a critical topic for the exam. What are read replicas? Read replicas are copies of your primary database that handle read traffic. They take the load off your main database by serving select queries. Here's how it works. You have your main ardeus database instance. Let's call it primary. Applications write to the primary and read from the primary. Now traffic increases. You're getting thousands of read queries per second. The primary is getting overwhelmed. The solution is to create read replicas. You can create up to 15 read replicas per primary database. These replicas can be in the same availability zone in different Asis in the same region or even in different regions entirely. Replication from primary to replicas is asynchronous. The primary writes data. Then that data is replicated to replicas with a small delay, usually milliseconds to a few seconds. Because replication is asynchronous, reads are eventually consistent. If you write data to the primary and immediately read from a replica, you might not see the new data just yet. It's propagating. A few milliseconds later, it will be there. Now how do applications use read replicas? Applications must update their connection strings. You point right traffic to the primary endpoint and read traffic to the replica endpoints. The application code needs to handle this. Now, let's talk about a common use case. Imagine you have a production database handling your normal application load. Everything is just fine. Now the business team wants to run analytics. They want to run complex queries aggregating millions of rows. These queries will slam the database. If they run these queries on the production database, your application slows down. Users see terrible performance. So a solution would be to create read replicas specifically for analytics. The business team connects to the replica and runs their heavy queries there. The production database is unaffected, perfect separation. So here is an important point. Read replicas are for select statements only reads, not writes. You cannot insert, update, or delete on a read replica. It's read only. Remember that. Well there is an exception. You can promote a read replica to become its own standalone database. After promotion, it's a full read write database and replication stops. This is useful for creating new environments or disaster recovery scenarios. Now, let's discuss network costs. In AWS, when data transfers between availability zones, there's usually a network cost. But for RDS, read replicas within the same region, even across different Asis, you don't have to pay that fee. It's free. However, if you create a cross-region read replica, for example, primary in US East 1, and replica in EU West 1, you pay for cross-region data transfer. For the exam, remember these key points. You can have up to 15 read replicas per primary. Replication is asynchronous, that means it gives you eventual consistency. Replicas can be in the same AZ, cross-AZ, same region, or cross region. Applications must update connection strings to use replicas. Read replicas are for select operation only. You can promote replica to a standalone database. Modern region replication is free, but cross-region costs money. Now, let's talk about multi-AZ. This is different from read replicas. Multi-AZ is for disaster recovery, not for scaling reads. So now, what is multi-AZ? Multi-AZ means your database has a standby replica in a different availability zone. If your primary database fails, RDS automatically fails over to a standby. Your application keeps running with minimal disruption. Here's how it works. You enable multi-AZ on your RDS database. RDS creates a standby replica in a different availability zone. Let's say primary is in US East 1A, and the standby is in US East 1B. Replication from primary to standby is synchronous. That's every right to the primary is immediately replicated to the standby before the right is acknowledged. This ensures that the standby is always kept up to date. You get one DNS name for the database. Your application connects to that DNS name. Behind the scenes, it points to the primary. Now if the primary fails, whether it's an instance failure, AZ failure, network failure, or storage failure, RDS automatically fails over to a standby. The DNS name now points to the standby. Your application reconnects and continues working. The entire failover happens automatically. There is no manual intervention needed. This failover transition typically takes and completes. it's in about a minute to two minutes. So here's what's critical for the exam. Multi-AZ is for availability, not for performance. The standby instance does not serve read traffic. It's just sitting there staying synchronized ready to take over if the primary fails. You cannot connect to it directly. If you want to scale reads, you want to use read replica instead. If you want high availability and automatic failover, you want to use multi-AZ. And here's something important. You can combine them. You can have multi-AZ enabled for high availability and then create read replicas for read scaling. The read replicas themselves can be multi-AZ for even more durability. So let's compare multi-AZ and read replicas side by side. Multi-AZ, the purpose is high availability. Just for disaster recovery. Replication is synchronous. It's a standby. It's not accessible for reads. Failure is automatic. It can be used in the same region only. Whereas read replicas, the purpose is read scaling. Replication is asynchronous. Replication serve read traffic. The promotion is manual, but it can be cross region. OK, so now how do you enable multi-AZ? You can enable it when you create the database or you can modify an existing database to enable multi-AZ later. The great thing is enabling multi-AZ on an existing database is zero downtime. You don't need to stop the database. So here's what happens behind the scenes. RDS takes a snapshot of your primary database. It restores that snapshot in a different AZ to create the standby. It establishes synchronous replication between primary and standby. And it's done. Your application keeps running the entire time. So for the exam, remember, again, multi-AZ is for high availability and disaster recovery. Synchronous replication to standby possible. One DNS name with automatic failure. Standby does not serve traffic. It's only for failure. Remember that. Failure happens automatically in about a minute or two. Zero downtime to enable on existing database. So for the next section, let's look at RDS backups and restore. RDS provides two types of backups, automated backups, and manual snapshots. First, let's look at automated backups. RDS automatically takes a full daily backup of your database during a backup window you define. Let's say you set your backup window to between 2am and 3am. Every night at 2am, RDS takes a full backup. In addition to daily backups, RDS also backs up transaction logs every five minutes. This gives you point-in-time restore capability. With point-in-time restore, you can restore your database to any specific timestamp. Someone dropped a table at 3.47 pm on Tuesday. You can restore that to 3.46 pm right before it happened. The retention period for automatic backups is between one to 35 days. You choose the retention. Default is seven days. If you set it to zero, automated backups are disabled entirely. Second, manual snapshots. You can manually trigger a snapshot at any time. This creates a backup that you control. Manual snapshots are kept as long as you want. There is no automatic deletion. Use manual snapshots before any major changes that you're about to make. About to run a risky migration script, then you want to take a manual snapshot first. If something goes wrong, then you can restore from the snapshot. So here is an important cost consideration I want to remember. If you stop an RDS database to save cost, you still pay for storage. The storage doesn't go away when the database is stopped. If you're stopping a database for a long time, that's weeks or months, it's cheaper generally to take a snapshot, then delete the database, and restore from the snapshot when you need it again. Snapshots generally cost less than the provision's storage. Now, let's talk about restoring. When you restore from a backup or snapshot, RDS creates a new database instance. It doesn't restore in place over the existing database. And why is this the case? This is done normally for safety. If you restore and something is wrong, your original database is still there untouched. This means after restoring, you need to update your application to point to the new database endpoint, or you can rename the databases to swap them. Now, what about migrating databases to RDS? You can restore my SQL databases from S3. Here is the process. Back up your on-premises my SQL database. Upload the backup file then to S3. Restore the backup into a new RDS for my SQL instance and your done. Your on-premises database is now in RDS. So for the exam I want you to remember, automated backups mean daily full backup plus transaction logs every five minutes. Point in time, restore means restoring to any time stamp in the retention period that you've chosen, which is typically between one to 35 days. Manual snapshots is user triggered. It's kept as long as you want. Restoring creates a new database instance. Stopped databases still cost money. There is storage charges that you incur. You can restore my SQL from S3 backups. Next, let's look at RDS storage and security. Let's quickly cover two important topics, storage, auto scaling and security. First, storage, auto scaling. When you create an RDS database, you provision a certain amount of storage. Let's say 100 GB. Your database grows over time. At some point you will run out of space. Now with storage, auto scaling enabled, RDS automatically increases storage when you're running low. You don't have to manually modify the database itself. So how does it all work? You first set a maximum storage threshold. That's the maximum amount RDS can scale to. Let's say you set it to 1 TB. RDS monitors the free storage. When the free storage falls below 10% of the allocated storage and stays that way for at least five minutes and at least six hours of past since the last modification is done, RDS automatically scales the storage. This is perfect for applications with unpredictable growth. Your database automatically gets more space as needed up to your defined maximum. Now for security, RDS provides multiple layers of security. First, encryption address. You can encrypt your database using AWS KMS. This must be enabled at database creation time. If the primary is encrypted, read replicas or also encrypt it. Now here's a go-cha. If you have an unencrypted database and want to encrypt it, you can't just enable encryption. You need to create a snapshot, copy the snapshot with encryption enabled, restore the encrypted snapshot, then point your app to the new encrypted database. It's a bit of a process there. There is also encryption in flight. RDS supports TLS encryption for connections. Your applications can connect to using TLS to encrypt data in transit. This is enabled by default. You just need to use AWS TLS certificates on the client side. Now let's look at IM authentication. Instead of using username and password, you can use IAM roles to authenticate to the database. Your applications authenticate with IAM, get temporary credentials, then connect to the database. This is more secure than storing database passwords itself. Let's look at security groups. Just like EC2 we discussed earlier on, RDS uses security groups to control network access. The security group defines which IP addresses or security groups can connect to your database. There's no SSH, remember you cannot SSH into RDS instances. They're fully managed. This is by design, AWS handles the OS. Audit logs, RDS can send audit logs to cloud watch logs for long-term retention and analysis. This helps with compliance requirements. So for the exam you want to remember, storage auto scaling, automatic storage increases based on usage. Encryption address, KMS encryption is used, must be set at creation time. Unencrypted to encrypted, you want to create snapshot, copy with encryption, and you'll have to restore. For encryption in flight, TLS is supported by default. For IAM authentication, you want to use IAM roles instead of passwords. For security groups, you want to use control network access. Remember, no SSH access to RDS instances is possible. Okay, so now let's talk about Aurora. Aurora is AWS's proprietary high performance relational database. This is one of AWS's flagship services and it appears constantly on the exam. So what is Aurora? Aurora is a cloud optimized relational database built from the ground up by AWS. It's compatible with MySQL and Postgres SQL, meaning your existing MySQL or Postgres SQL applications work with Aurora without any code changes. Users change the connection string. Aurora is fast, AWS claims five X performance improvements over MySQL or RDS and three X performance improvement over Postgres SQL or RDS. In benchmarks, Aurora really does perform significantly better. Now, here's what makes Aurora special. It's storage architecture. Aurora storage automatically grows in increments of 10 gigs up to 256 TV. You never run out of space. As your database grows, storage expands automatically. Aurora stores six copies of your data across three availability zones. That's two copies per AZ. This provides incredible durability. Now for writes, Aurora needs 4 out of 6 copies to acknowledge this. the right. For reads, Aurora needs three out of six copies. This means Aurora can tolerate losing and enter easy and still keep functioning. Aurora also has self-healing storage. If a storage block gets corrupted, Aurora detects it and automatically repairs it using peer-to-peer replication from healthy copies. That is no human intervention is needed. Now what about the high availability factor. Aurora is highly available by design. You have one writer instance, the primary that handles writes. You can have up to 15 read replicas that handle read traffic. If the writer instance fails, Aurora automatically fails over to read replica, promoting it to be the new writer. Failure happens in less than 30 seconds. It's much faster than RDS multi-AZ. Aurora provides two endpoints. There is a writer endpoint that always points to the current writer instance. Your application writes to this endpoint. Then there is the read endpoint. It does the connection load balancing across all the read replicas. That's your application reads from this endpoint and Aurora distributes the load across these replicas. This makes application code simple. Write a writer endpoint, read from the read endpoint. Aurora handles everything else. Now let's talk about Aurora auto scaling. As read traffic increases, you might need more read replicas. Aurora can automatically add these read replicas based on CPU usage and connections. Set a target, for example, keep CPU below 70%. When CPU exceeds 70%, Aurora automatically adds a read replica. When traffic decreases, Aurora removes replicas. It's fully automatic. Now what about custom endpoints? You can define custom endpoints that point to specific replicas. Now why would you do this? Imagine you have analytical queries that are resource intensive. You don't want this running on your general purpose replicas. So a solution would be to create larger replicas specifically for analytics and define a custom endpoint pointing to them. Your application then sends analytical queries to the custom endpoint and regular queries to the reader endpoint. That's perfect workload separation there. Now let's discuss Aurora serverless. Aurora serverless is a version of Aurora where you don't need to manage instances at all. AWS automatically provisions database capacity based on your actual usage. If your database is idle, Aurora scales down to minimal capacity or even pauses completely. If the traffic spikes on the other hand, Aurora automatically scales up. This is perfect for infrequent workloads intermittent traffic patterns or applications that you truly don't know the load ahead of time. You pay per second of usage by the way, which can be more cost effective than running instances 24/7 for load traffic applications. What about Aurora global databases? Aurora global database gives you cross region replication with very low latency. You have one primary region that handles right. You can have up to 10 secondary read-only regions. Replication lag is typically less than a second. That's incredibly fast for cross-region replication. Each secondary region can have up to 16 read replicas giving you global read scalability. Why would you use this? This is typically used for disaster recovery. If your primary region fails, you can promote a secondary region to become primary with recovery time of less than a minute. Also low latency for global users, users in Europe, read from European region, users in Asia can read from the Asian region, writes go to the primary but reads are served locally. Now let's talk about Aurora cloning. You can clone an entire Aurora database cluster. The clone initially shares the same underlying storage as the original database using copy on right protocol. That's no actual copying happens initially. The clone just points to the same data. When you make changes to the clone, only then is the data copied. This makes cloning incredibly fast. So now let's look at a use case. Creating a staging database from production. You want to test a risky migration on production data. So what you could do with this is to clone the production database to staging in seconds. Run your tests on the clone. Production is thereby completely unaffected. Now Aurora costs money. Aurora is more expensive than the regular RDS about 20 percent more. But you get much better performance, automatic storage scaling, faster replication, sub-32nd failure and all the other benefits we talked about. For many workloads, the performance improvements mean you can use smaller instances which offsets the higher per instance cost. So for the exam, remember Aurora is my SQL and Postgres SQL compatible. It's got 5x my SQL performance and 3x times Postgres SQL performance. Storage auto scales up to 256 TB. Six copies across three AZs possible to per AZ. One writer plus up to 15 read replicas. Failure in less than 30 seconds. Writer endpoint and read run point. Autoscaling of read replicas. Aurora serverless for variable workloads. Aurora global for cross-region replication that gives you under one second lag. Aurora cloning for fast database copies. And it costs 20 percent more than RDS but is technically more efficient. Now let's look at elastic cache in memory caching. Elastic cache is completely different from RDS and Aurora. It's not a database for persistent storage. It's a caching layer. So what is elastic cache? Elastic cache is AWS's managed caching service. It gives you in-memory data stores with micro-second latency. Elastic cache supports two engines that's redis and memcached. The same way RDS is managed relational database. Elastic cache is managed caching. AWS handles the setup, the patching, the monitoring, failure recovery, and all the backups for you. Now why would you use caching anyway? Caches dramatically reduce load on databases. Instead of hitting the database for every read you cache frequently access data in memory. Reads come from the cache which is much faster and takes load of your database. Caches also make applications stateless. You store user session data in elastic cache. That way users can hit any application server and the session is retrieved from the cache. There's no need for sticky sessions on the load balancer. Let's look at a common caching pattern. It's called database caching. Your application needs to read data. First it checks elastic cache. If the data is in the cache which is a cache hit then you return it immediately. It's micro-second response time. If the data is not available in the cache what we term as cache miss the application reads from rds then writes that data to the cache for future requests. Next time someone needs that data it's in the cache. It's a cache hit this faster response. This pattern dramatically reduces database load like we discussed. You might reduce database queries by about 80% or more with effective caching. But there's a challenge to all of that. It's called cache invalidation. You also need a strategy to ensure that cache doesn't serve stale data. When data is updated in the database you need to either update or delete it in the cache. Otherwise users would see all data. As the famous code says there are only two hard things in computer science cache invalidation and naming things. Another common pattern user session store. When a user logs in store their session data in elastic cache the session includes user ID authentication tokens preferences shopping cart contents whatever your application needs. Now the user's next request hits a different application server no problem that server retrieves the session from elastic cache the user can still stay logged in. Without elastic cache you at need sticky sessions on the load balancer to ensure users always hit the same server or you at store sessions in a database which is slower so elastic cache is perfect for all of these kind of scenarios. Now let's compare redis and memcache. Redis is the most feature rich option. Redis supports multi-az with automatic failure. You have a primary node and replica nodes. If the primary fails a replica is automatically promoted. Redis supports read replicas for scaling reads and high availability. Redis provides data durability using a OF append only file persistence even though it's in memory Redis can persist data to disk for durability. Redis has backup and restore features you can take snapshots of your redis data. Redis supports advanced data structures like sets and sorted sets. It's perfect for use cases like leaderboards, pub sub messaging, geospatial queries and so on and so forth. So when do you want to use redis? When you need high availability when you need data persistence when you need backups or when you want to use advanced data structures you want to use redis. On the other hand memcache is simpler and focused on pure caching. Memcache supports multi-node partitioning also called sharding. You can partition your data across multiple nodes. Memcache has no replication that's there is no high availability functionality. If a node fails that data is lost. Memcache does not persistent data lives only in the memory if the cache restarts that the data is gone. Memcache does multi-thread it. It can utilize multiple CPU cores per node more efficiently than redis. Now when do you want to use memcache? When you want simple caching with sharding don't need high availability. availability and data loss is acceptable. It's just a cache after all. You won't use memcache. For the exam, the choice is usually redis. Remember that because most scenarios require high availability. Now, let's talk about security for a bit. Elastic cache with redis supports IAM authentication. You can use IAM policies to control who can manage the cache. Redis also supports redis auth, password-based authentication for cache access. That is, you set a password when creating the cluster. Applications must provide the password to access the cache. Redis supports SSL-TLS encryption for data in flight. Connections are encrypted. Memcache supports SASL-based authentication for more advanced use cases. Both Redis and Memcache use security groups to control network access, just like RDS and EC2. There's also a specific Redis use case I want to mention here, gaming leaderboards. Gaming leaderboards are complex to compute. You need to rank potentially millions of players in real time, maintaining both uniqueness and correct ordering. Redis sorted sets up perfect for this. Sorted sets guarantee uniqueness and automatically maintains ordering. When a player score updates, redis re-ranks them in real time and places them in the correct position. Many gaming companies use redis specifically for leaderboards because of this particular feature. So for the exam, remember, elastic cache is managed in memory caching. Supports redis and Memcache. Redis uses database load by caching frequently access data, makes applications stateless by storing session data, common patterns you use that for is database caching and session store. Remember what redis supports multi-AZ read replicas, data durability, backups, and advanced data structures. Memcache on the other side is simple caching, multi-node sharding, non-persistent, and it is multi-threaded. Usually choose redis for the exam questions because like we mentioned, most of the questions talk about high availability. Remember also redis supports IAM authentication, redis auth password, and SSL encryption. Redis sorted sets are perfect for leaderboards. Now for the favorite section, exam traps and gotchas. Let's cover common exam traps for databases. Trap number one, RDS multi-AZ versus read replicas. People confuse these constantly. Multi-AZ is for high availability and disaster recovery. The standby does not serve traffic. Read replicas are for scaling reads. They do serve traffic. Question, application has high read load. Do you want to use multi-AZ? Wrong, multi-AZ doesn't help with read scaling. Remember that, you want to use read replicas. Another question, if you need automatic fail-over, if database fails, do you want to use read replicas? Wrong, read replicas don't provide automatic fail-over. You want to use multi-AZ instead. Trap number two, read replica replication is asynchronous. The question is, write data to Adius, immediately read from replica. Will you see the new data? The answer is maybe not. Replication is asynchronous with a small lag. Reads are eventually consistent. That means you will see all data for a few milliseconds until replication catches up. Trap number three, read replicas are read only. The question is, can you use read replica for write operations to scale writes? The answer is no, read replicas only serve select queries. They are read only. You cannot write into them. The only way to scale writes is to use Aurora with multiple writer notes or partition your data across multiple databases, starting. Trap number four, Aurora fail-over is faster than Adius. Question is, you need fastest fail-over time. Do you use Adius multi-AZ or Aurora database? The answer is Aurora database. Adius multi-AZ fail-over is about one to two minutes. Aurora fail-over is under 30 seconds. Trap number five, Aurora storage auto scales. Question is, does Aurora run out of storage? It's a trick question. Aurora storage automatically grows up to 256 TB. You don't need to provision storage. It just grows as needed. Trap number six, elastic cache versus Adius. Question is, you need to reduce database load. You add more Adius read replicas or do you add elastic cache? The answer is it depends, read replicas help, but elastic cache can reduce load more dramatically by caching data in memory. Elastic cache is specifically designed for this particular use case. Trap number seven, redis versus memcached. You need high availability caching. Do you want to use redis or memcached? The answer is redis. Redis supports multi-AZ with automatic fail-over memcached has no high availability. And the question, you need simple caching with multi-note sharding. The answer could be either, but memcached is simpler for this particular use case. Trap number eight, question is, you have an unencrypted Adius database. Do you enable encryption? The answer is, you cannot enable encryption on existing unencrypted database. You must create a snapshot, copy snapshot with encryption, restore from encrypted snapshot. Then switch the applications to the new database. It's a long round way. Trap number nine, stopped Adius still costs money. Question is, you stop Adius database to save costs during downtime. Will that help? The answer is, you stop paying for compute, but storage charges will continue. For long term shutdowns, you snapshot and delete the database then restore later when you need them. Trap number 10, Adius backups are automatic. The question is, do you need to manually backup Adius every day? No, you don't need to Adius automatically takes daily backups during your backup window. Retention is one to 35 days. You can also take manual snapshots as you need for additional control. Trap number 11, restoring creates new database. Question is, you restore Adius backup. Does it restore or existing database? No, it doesn't. Remember that, original database remains unchanged. You need to update application connection strings though. And finally for Trap number 12, Aurora is not free tier eligible. The question is, can you test Aurora on AWS free tier? No, you cannot. Aurora is not included in the free tier. Adius with MySQL or Postgres SQL is free tier eligible, but Aurora costs money from day one. Okay, onto our final section, exam quick tips. These are rapid fire exam tips for databases. Tip number one, use Adius for managed relational databases. Got six engines, Postgres SQL, MySQL, MariaDB Oracle, SQL Server and Aurora. Tip number two, use Multi-AZ for high availability. It's called synchronous replication, automatic failure, about one to two minutes of recovery time. Tip number three, use read replicas for read scaling. It's asynchronous replication up to 15 replicas, eventually consistent reads. Tip number four, use Aurora for high performance. It's 5x times faster than MySQL performance, three x times faster than Postgres SQL performance. It's supposed up to 15 read replicas, auto scaling storage, and Scott under 30 seconds failover. Tip number five, use Aurora serverless for variable workloads. There's automatic scaling based on usage and it's pay per second. Tip number six, use Aurora global for cross region. It's got under one second replication lag, disaster recovery is within under a minute article. Tip number seven, use elastic cache for caching, read is for high availability and advanced features and memcached for simple caching use cases. Tip number eight, use read is auth for security. It's password based on the dedication, plus IAM policy supported. Tip number nine, use point in time restore, daily backups plus five minute transaction logs, restore to any point within retention period. And tip number nine, storage auto scaling. RDS automatically increases storage when running low. Aurora automatically grows to 256 TB. All right, everyone, that is episode nine on AWS databases, RDS, Aurora, and elastic cache. We covered a lot today. We started with RDS fundamentals and what managed databases mean. We dove deep into read replicas for scaling up to 15 replicas, asynchronous replication. That's perfect for separating production and analytics workloads. We then explored multi-easy for high availability, synchronous replication, automatic failover, one DNS name for seamless failure handling and so forth. We covered RDS backups, automatic daily backups, point in time restore and manual snapshots for full control. We examined Aurora, AWS's high performance databases with high performance, which is auto scaling, supports up to 15 replicas and provides a failover in under 30 seconds. We learned then about Aurora serverless for variable workloads and Aurora global for cross-region replication with under a second lag. We dove into elastic cache, in memory caching with redis and memcached, perfect for reducing database load and storing session data. And then we finally covered 12 exam traps that trip people up on the test date. So the key takeaway I want to leave you with is to choose the right database service for your use case. RDS for managed relational databases, Aurora when you need maximum performance, Elastic cache when you need to reduce database load with caching, multi-AZ for high availability, read replicas for read scaling. So in our next episode, episode 10, we are diving into Amazon Route 53 that's AWS's DNS service. We'll cover routing policies, health checks, DNS failover, and how to design globally distributed applications with intelligent traffic routing. If this episode helped you master AWS databases, please do consider to leave a five-star rating on Spotify and share it with anyone studying for the AWS exam. So until next time, keep studying, keep practicing, and I will see you in episode 10. This is Baloo signing off, bye.