WEBVTT 00:00:00.000 --> 00:00:03.359 Welcome back to the deep dive. You know, if you've 00:00:03.359 --> 00:00:06.080 ever had to stare down a list of database options 00:00:06.080 --> 00:00:10.839 like Postgresql, Myswap, MongoDB, it can feel... 00:00:10.890 --> 00:00:13.990 overwhelming, like trying to pick just one tool 00:00:13.990 --> 00:00:17.170 from this huge, confusing toolbox. Yeah, absolutely. 00:00:17.250 --> 00:00:19.129 And traditionally, figuring out your whole data 00:00:19.129 --> 00:00:21.769 infrastructure took serious time. Right. And 00:00:21.769 --> 00:00:23.690 setting up things like reliable backups, that 00:00:23.690 --> 00:00:26.269 was often a real administrative headache. Exactly. 00:00:26.289 --> 00:00:28.149 So our mission today is really to cut through 00:00:28.149 --> 00:00:30.170 some of that complexity, give you the critical 00:00:30.170 --> 00:00:32.369 shortcut. OK. We aren't trying to turn you into 00:00:32.369 --> 00:00:35.329 a full -blown database administrator or a SQL 00:00:35.329 --> 00:00:38.109 wizard overnight. Not in 15 minutes anyway. Right. 00:00:38.490 --> 00:00:41.289 The goal is more strategic. It's understanding 00:00:41.289 --> 00:00:44.530 the value proposition of the core AWS database 00:00:44.530 --> 00:00:47.009 services. The why and the when. Precisely. Why 00:00:47.009 --> 00:00:49.409 choose this one over that one? Especially because 00:00:49.409 --> 00:00:51.549 the big promise of AWS is that they handle a 00:00:51.549 --> 00:00:53.950 lot of that previous heavy lifting for you. Okay, 00:00:53.950 --> 00:00:55.890 let's unpack this then. I think we have to start 00:00:55.890 --> 00:00:59.109 with the fundamental concept, right? The big 00:00:59.109 --> 00:01:02.149 divide in the database world. Relational versus 00:01:02.149 --> 00:01:04.409 non -relational. That's the foundational split, 00:01:04.430 --> 00:01:06.030 yeah. It's kind of like the difference between 00:01:06.030 --> 00:01:09.769 a system built for, say, meticulous accounting 00:01:09.769 --> 00:01:12.849 versus one built for just astronomical speed. 00:01:13.129 --> 00:01:15.469 That's a good way to put it. And what's fascinating 00:01:15.469 --> 00:01:18.790 is that this choice, it really defines your data's 00:01:18.790 --> 00:01:21.709 integrity model, how reliable, how consistent 00:01:21.709 --> 00:01:24.170 your data needs to be. OK, so let's start with 00:01:24.170 --> 00:01:26.609 the meticulous accountant, relational databases 00:01:26.609 --> 00:01:30.629 or SQL. Why are these still sort of the go -to 00:01:30.629 --> 00:01:33.269 for critical transactional stuff? Well, they're 00:01:33.269 --> 00:01:35.709 the standard for a reason. relational databases 00:01:35.709 --> 00:01:38.689 enforce a pretty rigid schema. Everything has 00:01:38.689 --> 00:01:40.689 its place. Right. Everything's structured in 00:01:40.689 --> 00:01:42.810 predefined rows and columns, kind of like a very, 00:01:42.810 --> 00:01:45.250 very precise spreadsheet. But the really essential 00:01:45.250 --> 00:01:48.810 feature is ACID compliance. ACID -y. Okay, what's 00:01:48.810 --> 00:01:50.969 that stand for again? Tomicity, consistency, 00:01:51.170 --> 00:01:53.790 isolation, and durability. It's basically the 00:01:53.790 --> 00:01:56.689 promise that your transaction, whether it's transferring 00:01:56.689 --> 00:02:00.189 money or updating inventory, is reliable and 00:02:00.189 --> 00:02:02.329 safe. It either completes fully or it doesn't 00:02:02.329 --> 00:02:04.670 happen at all. Gotcha. So if I'm building a system 00:02:04.670 --> 00:02:07.329 to track inventory or maybe manage user finances, 00:02:07.609 --> 00:02:10.050 I absolutely need that ACID guarantee. Can't 00:02:10.050 --> 00:02:12.189 have partial updates messing things up. Exactly 00:02:12.189 --> 00:02:14.150 right. That consistency is paramount in those 00:02:14.150 --> 00:02:17.009 cases. Historically, though, the trade -off for 00:02:17.009 --> 00:02:21.250 that ironclad consistency was scaling. How so? 00:02:21.430 --> 00:02:23.050 Well, scaling usually meant scaling vertically, 00:02:23.229 --> 00:02:25.789 just making your one single server bigger, more 00:02:25.789 --> 00:02:29.009 powerful. adding more RAM, more CPU to the box. 00:02:29.069 --> 00:02:32.629 Yep. And these databases excel where you have 00:02:32.629 --> 00:02:35.770 complex relationships between data linking, say, 00:02:35.909 --> 00:02:38.490 an order to a specific customer, and that customer 00:02:38.490 --> 00:02:42.000 is linked to a specific address. Yeah. Lots of 00:02:42.000 --> 00:02:44.520 joints. Okay. But then, you know, the demands 00:02:44.520 --> 00:02:46.580 of the modern internet exploded. Mobile apps, 00:02:46.840 --> 00:02:48.580 millions of users all at once, social media. 00:02:48.599 --> 00:02:51.039 Right. And that rigid, structured file cabinet 00:02:51.039 --> 00:02:53.560 started struggling with these massive, often 00:02:53.560 --> 00:02:57.020 unpredictable data volumes. Which, I guess, brings 00:02:57.020 --> 00:03:00.280 us to the other side. The NoSQL world. Exactly. 00:03:00.439 --> 00:03:03.520 The non -relational or NoSQL world is almost 00:03:03.520 --> 00:03:05.900 the opposite in philosophy. It's dynamic, it's 00:03:05.900 --> 00:03:08.900 flexible, often described as schemaless. So less 00:03:08.900 --> 00:03:11.319 structure. Less enforced structure up front. 00:03:11.719 --> 00:03:14.699 Data can be stored as key value pairs or maybe 00:03:14.699 --> 00:03:17.960 JSON documents. It's much more fluid. And because 00:03:17.960 --> 00:03:21.080 they prioritize distribution and massive availability, 00:03:21.780 --> 00:03:24.379 often over that immediate strict consistency, 00:03:24.580 --> 00:03:27.199 they follow what's called the base model. OK, 00:03:27.379 --> 00:03:30.189 base, not asset. Right. Basically, available, 00:03:30.370 --> 00:03:33.669 soft state, and eventually consistent. The focus 00:03:33.669 --> 00:03:35.810 shifts. Right. That trade -off, giving up immediate 00:03:35.810 --> 00:03:38.009 consistency for speed, that probably sounds terrifying 00:03:38.009 --> 00:03:40.509 to a traditional database person. It can. But 00:03:40.509 --> 00:03:42.650 it's a conscious design choice. How often does 00:03:42.650 --> 00:03:47.479 that eventually consistent state? actually cause 00:03:47.479 --> 00:03:51.099 problems in a typical modern app. Well, it depends 00:03:51.099 --> 00:03:53.080 entirely on the use case. For something like 00:03:53.080 --> 00:03:55.680 a gaming leaderboard or maybe storing user session 00:03:55.680 --> 00:03:58.800 profiles, you can probably tolerate a second 00:03:58.800 --> 00:04:01.080 or two of eventual consistency if the payoff 00:04:01.080 --> 00:04:04.120 is handling, say, a million requests per second 00:04:04.120 --> 00:04:06.560 without falling over. OK, that makes sense. Availability 00:04:06.560 --> 00:04:09.449 trumps instant consistency there. Right. And 00:04:09.449 --> 00:04:11.889 new SQL databases, they primarily scale horizontally. 00:04:12.250 --> 00:04:15.009 Instead of one big server, you just add potentially 00:04:15.009 --> 00:04:17.829 thousands of smaller servers or nodes to distribute 00:04:17.829 --> 00:04:20.589 the load. Allowing for almost limitless scale, 00:04:20.829 --> 00:04:23.050 theoretically. Pretty much. Their sweet spot 00:04:23.050 --> 00:04:25.769 is anything demanding, just unprecedented performance 00:04:25.769 --> 00:04:28.670 or scale. Massive user profile stores, streams 00:04:28.670 --> 00:04:31.370 of IoT data, real -time recommendation engines, 00:04:31.449 --> 00:04:34.100 that kind of thing. Okay, that sets the stage 00:04:34.100 --> 00:04:36.660 really well for the strategic choices you have 00:04:36.660 --> 00:04:39.560 with an AWS. Now that we understand ACID and 00:04:39.560 --> 00:04:43.980 BASE, let's see how AWS helps manage those relational 00:04:43.980 --> 00:04:46.360 databases first. The value prop, as you said, 00:04:46.459 --> 00:04:49.160 is huge because AWS handles the patching, the 00:04:49.160 --> 00:04:51.899 OS updates, the backups. All that undifferentiated 00:04:51.899 --> 00:04:54.000 heavy lifting, yeah. The stuff that doesn't directly 00:04:54.000 --> 00:04:56.480 add business value but has to be done. Right. 00:04:56.670 --> 00:04:59.649 The grunt work. That's the core idea behind Amazon 00:04:59.649 --> 00:05:02.610 Relational Database Service, or RDS. It's important 00:05:02.610 --> 00:05:05.170 to remember, though, RDS itself isn't a database 00:05:05.170 --> 00:05:07.610 engine. Ah, OK. It's more like a management layer. 00:05:07.850 --> 00:05:09.949 Exactly. It's the managed service wrapper. It 00:05:09.949 --> 00:05:13.310 makes operating your choice of popular relational 00:05:13.310 --> 00:05:16.829 engines like PostgreSQL, MySQL, MariaDB, even 00:05:16.829 --> 00:05:19.470 Oracle or SQL Server much, much simpler. Got 00:05:19.470 --> 00:05:21.430 it. And this leads us right into something that 00:05:21.430 --> 00:05:23.290 I think confuses a lot of people when they're 00:05:23.290 --> 00:05:25.149 planning their infrastructure. The difference 00:05:25.149 --> 00:05:28.470 between high availability and scaling. Specifically, 00:05:29.009 --> 00:05:31.750 multi -AZ versus read replicas in RDS. Ah, yes. 00:05:31.850 --> 00:05:33.689 This is absolutely critical to understand. They 00:05:33.689 --> 00:05:35.629 serve very different purposes. Okay, break it 00:05:35.629 --> 00:05:38.470 down for us. So when you set up a multi -AZ deployment, 00:05:39.029 --> 00:05:41.750 AWS is focused almost purely on disaster recovery 00:05:41.750 --> 00:05:43.870 and high availability. Keeping the lights on 00:05:43.870 --> 00:05:46.470 if something fails. Precisely. They synchronously 00:05:46.470 --> 00:05:49.079 replicate your data, meaning... in real time 00:05:49.079 --> 00:05:51.779 to an identical standby instance in a completely 00:05:51.779 --> 00:05:54.180 separate availability zone, a different physical 00:05:54.180 --> 00:05:56.980 data center. Right. So if your primary instance 00:05:56.980 --> 00:06:00.519 fails or even the whole AZ has an issue, AWS 00:06:00.519 --> 00:06:02.759 automatically switches traffic over to that standby. 00:06:03.019 --> 00:06:06.600 usually in less than 60 seconds. Wow. Survival 00:06:06.600 --> 00:06:09.040 and continuity. That's a huge weight lifted. 00:06:09.220 --> 00:06:11.180 I mean, I remember the bad old days of trying 00:06:11.180 --> 00:06:14.480 to manually script and test disaster recovery 00:06:14.480 --> 00:06:17.540 failovers. 60 seconds is kind of magical compared 00:06:17.540 --> 00:06:20.120 to that. It really is a game changer for reliability. 00:06:20.360 --> 00:06:22.899 But the key insight here, and this is crucial, 00:06:23.579 --> 00:06:26.399 is that the standby instance is only for failover. 00:06:27.040 --> 00:06:29.540 During normal operation, it just sits there, 00:06:29.779 --> 00:06:31.800 waiting. You don't use it for reading or writing 00:06:31.800 --> 00:06:34.579 data. Ah, okay. So it doesn't help with performance 00:06:34.579 --> 00:06:37.500 bottlenecks if my main database is getting swamped 00:06:37.500 --> 00:06:40.079 with users. Correct. If you need to handle more 00:06:40.079 --> 00:06:42.980 user traffic, more read requests specifically, 00:06:43.600 --> 00:06:45.879 that's where you use read replicas. Okay, different 00:06:45.879 --> 00:06:48.819 tool. Different tool, different job. Read replicas 00:06:48.819 --> 00:06:50.959 are essentially copies of your database used 00:06:50.959 --> 00:06:53.740 exclusively to handle read traffic. They offload 00:06:53.740 --> 00:06:56.040 work from your primary instance. This is purely 00:06:56.040 --> 00:06:58.839 for performance and read scaling. So multi -AZ 00:06:58.839 --> 00:07:01.019 is like your insurance policy for disasters. 00:07:01.199 --> 00:07:03.579 Yep. And read replicas are like adding extra 00:07:03.579 --> 00:07:05.500 lanes to your highway to handle more traffic. 00:07:05.600 --> 00:07:08.139 That's a great analogy. And the replication for 00:07:08.139 --> 00:07:10.939 read replicas is typically asynchronous, meaning 00:07:10.939 --> 00:07:14.079 there might be a very slight delay, maybe milliseconds 00:07:14.079 --> 00:07:17.100 or seconds between the primary updating and the 00:07:17.100 --> 00:07:19.519 replica getting the change. Usually not an issue 00:07:19.519 --> 00:07:21.720 for reads, but something to be aware of. Got 00:07:21.720 --> 00:07:24.639 it. OK, so that clarifies RDS basics. Now let's 00:07:24.639 --> 00:07:27.560 talk about Amazon Aurora. AWS calls it their 00:07:27.560 --> 00:07:30.699 Cloud Native Relational Database. It's proprietary. 00:07:30.759 --> 00:07:33.579 but compatible with MySQL and Postgresql. What's 00:07:33.579 --> 00:07:37.120 the big deal there? Aurora is, well, it's a really 00:07:37.120 --> 00:07:40.199 significant architectural shift. AWS basically 00:07:40.199 --> 00:07:42.480 re -imagined how the storage layer works for 00:07:42.480 --> 00:07:45.079 a relational database in the cloud. Okay. The 00:07:45.079 --> 00:07:47.920 result is often massive performance gains. We're 00:07:47.920 --> 00:07:50.360 talking potentially up to five times faster than 00:07:50.360 --> 00:07:53.019 standard MySQL, maybe three times faster than 00:07:53.019 --> 00:07:55.540 standard Postgresful, often allowing you to use 00:07:55.540 --> 00:07:58.019 smaller, cheaper instance types for the same 00:07:58.019 --> 00:08:00.860 workload. How do they do that? The magic is really 00:08:00.860 --> 00:08:03.160 in its shared distributed storage layer. It's 00:08:03.160 --> 00:08:04.860 completely separate from the compute instances. 00:08:05.259 --> 00:08:07.399 Your data is automatically replicated six ways 00:08:07.399 --> 00:08:09.920 across three different availability zones. Six 00:08:09.920 --> 00:08:12.160 copies, wow. Yeah, for incredible durability. 00:08:12.360 --> 00:08:15.339 And the storage volume itself is self -healing 00:08:15.339 --> 00:08:18.459 and automatically grows as needed up to 128 terabytes 00:08:18.459 --> 00:08:21.660 without you doing anything. That automatic durability 00:08:21.660 --> 00:08:23.920 and scaling of storage is pretty incredible, 00:08:24.019 --> 00:08:27.160 but I think the concept that gets a lot of attention, 00:08:27.300 --> 00:08:29.800 especially for cost -conscious users, has to 00:08:29.800 --> 00:08:32.809 be... Aurora Serverless V2. Oh, absolutely. Aurora 00:08:32.809 --> 00:08:35.129 Serverless V2 is a huge deal, especially for 00:08:35.129 --> 00:08:37.269 workloads that aren't constant. Right, like dev 00:08:37.269 --> 00:08:39.970 test environments or apps with spiky traffic. 00:08:40.210 --> 00:08:42.549 Exactly. It's the answer to paying for a database 00:08:42.549 --> 00:08:45.309 capacity you're not using. It automatically scales 00:08:45.309 --> 00:08:47.970 the compute memory capacity up or down almost 00:08:47.970 --> 00:08:49.850 instantly based on what the application actually 00:08:49.850 --> 00:08:52.149 needs at that moment. So if your database sits 00:08:52.149 --> 00:08:55.049 idle overnight? It scales down potentially close 00:08:55.049 --> 00:08:57.450 to zero compute costs for that idle period. You 00:08:57.450 --> 00:08:59.490 only pay for the capacity you actually consume. 00:08:59.559 --> 00:09:02.620 minute by minute. It makes using really powerful 00:09:02.620 --> 00:09:05.500 enterprise -grade relational capacity much more 00:09:05.500 --> 00:09:08.320 viable financially for those unpredictable workloads. 00:09:08.940 --> 00:09:11.840 OK, fantastic. Let's completely shift gears now. 00:09:12.240 --> 00:09:14.220 We've talked a lot about relational databases 00:09:14.220 --> 00:09:16.860 and their limits, even with Aurora's improvements. 00:09:17.580 --> 00:09:19.659 What happens when your application needs scale 00:09:19.659 --> 00:09:22.519 and speed that, frankly, no traditional relational 00:09:22.519 --> 00:09:25.600 database can consistently deliver? Millions of 00:09:25.600 --> 00:09:28.750 users, instant responses. That sounds like we're 00:09:28.750 --> 00:09:31.549 entering Amazon DynamoDB territory. You got it. 00:09:31.870 --> 00:09:34.210 Amazon DynamoDB is really the hyperscale, non 00:09:34.210 --> 00:09:36.529 -relational powerhouse in the AWS portfolio. 00:09:37.090 --> 00:09:39.309 Its defining feature isn't just speed, but it's 00:09:39.309 --> 00:09:41.730 guarantee. A guarantee. Yeah. It's designed to 00:09:41.730 --> 00:09:43.870 deliver consistent, single -digit millisecond 00:09:43.870 --> 00:09:46.669 latency at any scale. Whether you have 10 requests 00:09:46.669 --> 00:09:49.289 a second or 10 million, the response time stays 00:09:49.289 --> 00:09:52.250 predictably fast. That consistency is often just 00:09:52.250 --> 00:09:54.620 as important as the raw speed. And crucially, 00:09:55.019 --> 00:09:57.259 unlike RDS where you still pick an instance size, 00:09:57.700 --> 00:10:00.019 DynamoDB is fully serverless, right? Completely. 00:10:00.240 --> 00:10:03.120 Zero servers to manage, patch, or scale. AWS 00:10:03.120 --> 00:10:05.360 handles all the underlying partitioning and horizontal 00:10:05.360 --> 00:10:07.539 scaling automatically behind the scenes. You 00:10:07.539 --> 00:10:09.960 just define your table and use it. That's a massive 00:10:09.960 --> 00:10:12.480 operational difference. It is. And the scale 00:10:12.480 --> 00:10:16.649 it operates at... is just staggering. AWS talks 00:10:16.649 --> 00:10:20.210 about it supporting peaks of over 20 million 00:10:20.210 --> 00:10:23.210 requests per second, handling trillions of requests 00:10:23.210 --> 00:10:26.049 per day across its fleet. So if my scenario involves 00:10:26.049 --> 00:10:28.409 scaling to potentially millions of concurrent 00:10:28.409 --> 00:10:31.750 users, needing super fast key lookups, like looking 00:10:31.750 --> 00:10:34.830 up a user profile or session data, and I don't 00:10:34.830 --> 00:10:37.690 need those complex relational joins. Then DynamoDB 00:10:37.690 --> 00:10:39.970 is almost certainly the answer. Think about things 00:10:39.970 --> 00:10:42.730 like massive shopping cart systems, gaming leaderboards, 00:10:42.830 --> 00:10:45.529 or preference stores, it's a perfect implementation 00:10:45.529 --> 00:10:47.789 of that base model prioritizing availability 00:10:47.789 --> 00:10:50.210 and scale. Okay. Now, when you look at DynamoDB, 00:10:50.289 --> 00:10:52.269 there are two main ways to pay for it, two capacity 00:10:52.269 --> 00:10:54.370 models. Can you quickly touch on those because 00:10:54.370 --> 00:10:56.269 they reflect different usage patterns? Sure. 00:10:56.429 --> 00:10:58.409 You've got two strategic choices for capacity. 00:10:59.070 --> 00:11:01.450 First, if your application traffic is pretty 00:11:01.450 --> 00:11:03.809 predictable and steady, maybe you know you'll 00:11:03.809 --> 00:11:05.929 need roughly a thousand reads and 500 writes 00:11:05.929 --> 00:11:08.549 per second. Consistently, you use provision capacity. 00:11:08.799 --> 00:11:11.419 You basically tell AWS what you need, and you 00:11:11.419 --> 00:11:13.100 pay for that capacity, whether you use it all 00:11:13.100 --> 00:11:15.019 or not. OK, predictable workload, predictable 00:11:15.019 --> 00:11:18.659 cost. Exactly. But if your traffic is bursty, 00:11:18.940 --> 00:11:21.220 highly variable, or just plain unpredictable, 00:11:21.440 --> 00:11:23.700 lots of peaks and valleys, you'd likely use the 00:11:23.700 --> 00:11:25.539 on -demand capacity model. How does that work? 00:11:25.779 --> 00:11:29.039 Simple. You just pay per request. Millions of 00:11:29.039 --> 00:11:31.820 requests, one hour, maybe only a few hundred 00:11:31.820 --> 00:11:34.899 the next. You pay for exactly what you use. No 00:11:34.899 --> 00:11:37.559 provisioning needed. This flexibility is key 00:11:37.559 --> 00:11:40.419 for cost optimization, matching the cost model 00:11:40.419 --> 00:11:43.200 to your actual usage profile. Makes perfect sense. 00:11:43.860 --> 00:11:47.379 Okay, so RDS and DynamoDB clearly cover a huge 00:11:47.379 --> 00:11:50.639 range of common application needs. But AWS didn't 00:11:50.639 --> 00:11:53.100 stop there, right? They recognize that sometimes 00:11:53.100 --> 00:11:55.600 you're forcing specific data types or query patterns 00:11:55.600 --> 00:11:58.899 into the wrong engine, which causes, well, inefficiency. 00:11:59.080 --> 00:12:00.940 Right. You wouldn't use a hammer to drive a screw. 00:12:01.120 --> 00:12:03.000 Exactly. And this is why we have the purpose 00:12:03.000 --> 00:12:05.480 -built database family. This is basically AWS 00:12:05.480 --> 00:12:07.419 saying, look, choose the right tool for this 00:12:07.419 --> 00:12:09.919 specific job. If the way you need to query your 00:12:09.919 --> 00:12:11.840 data is fundamentally different, like running 00:12:11.840 --> 00:12:14.659 complex analytics across vast datasets instead 00:12:14.659 --> 00:12:17.019 of quick transactional lookups, then you probably 00:12:17.019 --> 00:12:18.980 need a specialized engine optimized for that 00:12:18.980 --> 00:12:21.480 task. OK, so give us the quick rundown. What 00:12:21.480 --> 00:12:23.759 are the main specialized players and their core 00:12:23.759 --> 00:12:27.360 use case? Let's start with, say, massive analytical 00:12:27.360 --> 00:12:29.820 reporting, business intelligence. Right. For 00:12:29.820 --> 00:12:32.360 that, you're looking at Amazon Redshift. Think 00:12:32.360 --> 00:12:35.299 of it as the petabyte -scale data warehouse service. 00:12:35.529 --> 00:12:38.470 It's optimized specifically for business intelligence 00:12:38.470 --> 00:12:42.649 or BI reporting running really complex SQL queries 00:12:42.649 --> 00:12:45.789 across maybe months or years of historical sales 00:12:45.789 --> 00:12:48.309 data, for example. It's built for answering the 00:12:48.309 --> 00:12:51.070 big analytical questions, not for processing 00:12:51.070 --> 00:12:53.830 individual user transactions quickly. Got it. 00:12:53.970 --> 00:12:56.590 Data warehousing. Now, what if I just need to 00:12:56.590 --> 00:12:59.269 dramatically speed up my existing database, maybe 00:12:59.269 --> 00:13:02.350 an RDS instance, without rewriting my whole application, 00:13:02.850 --> 00:13:05.370 like caching frequently accessed data? Ah, that's 00:13:05.370 --> 00:13:07.429 the perfect use case for Amazon ElastiCache. 00:13:07.610 --> 00:13:09.929 It's a fully managed in -memory caching service. 00:13:10.129 --> 00:13:12.549 It supports popular engines like Redis and Memcache. 00:13:12.629 --> 00:13:15.289 So it keeps hot data in memory. Exactly. You 00:13:15.289 --> 00:13:17.830 dramatically speed up data access by fetching 00:13:17.830 --> 00:13:20.450 that highly requested data from super -fast memory 00:13:20.450 --> 00:13:22.909 instead of going all the way back to a slower 00:13:22.909 --> 00:13:26.230 disk -based database every single time. Essential 00:13:26.230 --> 00:13:28.950 for things like caching user session information 00:13:28.950 --> 00:13:32.100 or maybe popular product details. Makes sense. 00:13:32.559 --> 00:13:34.440 OK, what if the most important insight in my 00:13:34.440 --> 00:13:36.860 data isn't the individual records themselves, 00:13:37.279 --> 00:13:39.399 but the relationships between them, like how 00:13:39.399 --> 00:13:41.320 things are connected? Now you're talking about 00:13:41.320 --> 00:13:45.220 graph data. And for that, AWS offers Amazon Neptune. 00:13:45.450 --> 00:13:47.490 which is their fully managed graph database. 00:13:47.629 --> 00:13:49.789 The use case. Its sweet spot is analyzing these 00:13:49.789 --> 00:13:52.509 highly connected data sets. Think social networking 00:13:52.509 --> 00:13:54.590 graphs, who's friends with whom, who follows 00:13:54.590 --> 00:13:57.149 whom. Or recommendation engines, people who bought 00:13:57.149 --> 00:13:59.950 this also bought that. Or even sophisticated 00:13:59.950 --> 00:14:02.669 fraud detection, where tracing complex connections 00:14:02.669 --> 00:14:04.789 between accounts or transactions is paramount. 00:14:05.049 --> 00:14:07.690 Interesting. OK, one more specific one. What 00:14:07.690 --> 00:14:10.169 if my application heavily uses JSON documents? 00:14:10.309 --> 00:14:13.169 Is there something optimized for that? Yep. That 00:14:13.169 --> 00:14:15.840 would be Amazon DocumentDB. It's designed to 00:14:15.840 --> 00:14:19.059 be compatible with the MongoDB API, and it's 00:14:19.059 --> 00:14:21.639 specifically built for storing, querying, and 00:14:21.639 --> 00:14:25.779 indexing JSON or JSON -like documents efficiently. 00:14:26.799 --> 00:14:29.220 If your world revolves around document data structures, 00:14:29.740 --> 00:14:32.460 it's worth a look. OK, great overview of the 00:14:32.460 --> 00:14:34.940 purpose -built options. Let's zoom out a bit 00:14:34.940 --> 00:14:38.399 now to the operational side of things, security 00:14:38.399 --> 00:14:41.460 and cost. When we use all these fantastic managed 00:14:41.460 --> 00:14:45.019 services, RDS, DynamoDB, Aurora, et cetera, where 00:14:45.019 --> 00:14:47.159 does the responsibility actually lie? Thinking 00:14:47.159 --> 00:14:49.679 about the shared responsibility model. Ah, yes, 00:14:49.860 --> 00:14:52.470 the shared responsibility model. This is absolutely 00:14:52.470 --> 00:14:54.549 vital to understand when using any cloud service, 00:14:54.909 --> 00:14:57.549 especially databases. AWS handles the security 00:14:57.549 --> 00:14:59.590 of the cloud. Meaning the underlying infrastructure. 00:14:59.970 --> 00:15:01.629 Exactly. The physical security of the data centers, 00:15:02.070 --> 00:15:03.590 patching the operating system and the database 00:15:03.590 --> 00:15:05.769 engine itself, ensuring the underlying fault 00:15:05.769 --> 00:15:08.169 tolerance that makes things like multi -AZ deployments 00:15:08.169 --> 00:15:11.669 even possible. That's AWS's job. Okay. So what's 00:15:11.669 --> 00:15:13.990 left for us, the customer? We handle security 00:15:13.990 --> 00:15:16.129 in the cloud. What does that mean specifically 00:15:16.129 --> 00:15:18.070 when we're talking about these managed databases? 00:15:18.509 --> 00:15:20.889 It means you are still responsible for defining 00:15:20.889 --> 00:15:23.809 who can access the database, configuring things 00:15:23.809 --> 00:15:27.110 like AWS identity and access management, IAM 00:15:27.110 --> 00:15:30.429 policies, and crucially network access through 00:15:30.429 --> 00:15:32.809 security groups or VPC settings. Controlling 00:15:32.809 --> 00:15:35.330 gates, basically. Right. And perhaps most importantly, 00:15:35.590 --> 00:15:38.090 you are responsible for data protection. Meaning? 00:15:38.429 --> 00:15:40.690 Meaning you need to make the decision to enable 00:15:40.690 --> 00:15:43.610 encryption for your data. both encryption at 00:15:43.610 --> 00:15:45.850 rest when it's sitting on the disk, usually using 00:15:45.850 --> 00:15:48.450 AWS Key Management Service, KMS, and encryption 00:15:48.450 --> 00:15:51.690 in transit, using SSLTLS for connections to the 00:15:51.690 --> 00:15:55.590 database. AWS provides the tools, but you have 00:15:55.590 --> 00:15:57.809 to configure them. You also control things like 00:15:57.809 --> 00:15:59.549 choosing the maintenance window for when patches 00:15:59.549 --> 00:16:02.789 get applied. Got it. AWS secures the building, 00:16:03.169 --> 00:16:05.590 we secure the doors and the valuables inside. 00:16:05.870 --> 00:16:07.980 That's a pretty good analogy, yeah. Okay, let's 00:16:07.980 --> 00:16:10.320 wrap up then, my circling back to cost management. 00:16:10.539 --> 00:16:12.740 We've touched on a few things, but can you summarize 00:16:12.740 --> 00:16:15.320 the core strategies for optimizing spending on 00:16:15.320 --> 00:16:17.840 these AWS database services? Yeah, sure. There 00:16:17.840 --> 00:16:20.700 are really three main paths to think about for 00:16:20.700 --> 00:16:22.879 cost optimization. First, there's on -demand 00:16:22.879 --> 00:16:25.440 pricing. Pay as you go. Yep. Pay by the hour 00:16:25.440 --> 00:16:27.960 or second, depending on the service. Maximum 00:16:27.960 --> 00:16:30.919 flexibility, no long -term commitment. Usually 00:16:30.919 --> 00:16:33.759 the best fit for development, testing, or workloads, 00:16:34.220 --> 00:16:35.899 where you're just not sure about the long -term 00:16:35.899 --> 00:16:40.049 usage yet. OK. What's next for more stable workloads? 00:16:40.690 --> 00:16:42.610 For stable, predictable production workloads, 00:16:43.070 --> 00:16:44.970 you should definitely look at reserved instances, 00:16:45.389 --> 00:16:47.950 or IRIs. The commitment model. Right. You commit 00:16:47.950 --> 00:16:50.330 to using a certain instance type in a specific 00:16:50.330 --> 00:16:52.769 region for a one -year or a three -year term. 00:16:53.090 --> 00:16:55.610 And in exchange, you get a really significant 00:16:55.610 --> 00:16:58.710 discount compared to on -demand, often up to 00:16:58.710 --> 00:17:01.970 75%, potentially. You can save a lot if you know 00:17:01.970 --> 00:17:03.629 you'll be running that database consistently. 00:17:03.990 --> 00:17:07.029 Big savings for predictability. And the third 00:17:07.029 --> 00:17:09.329 strategy, which seems increasingly powerful, 00:17:09.710 --> 00:17:11.529 leverages those serverless options we talked 00:17:11.529 --> 00:17:13.950 about earlier. Absolutely. Things like Aurora's 00:17:13.950 --> 00:17:16.789 serverless v2 and DynamoDB on -demand capacity 00:17:16.789 --> 00:17:19.710 are often the ultimate cost savers, but specifically 00:17:19.710 --> 00:17:21.750 for those intermittent or highly unpredictable 00:17:21.750 --> 00:17:24.529 workloads. Because the database capacity automatically 00:17:24.529 --> 00:17:27.069 scales down, sometimes close to zero, when it's 00:17:27.069 --> 00:17:29.670 not being actively used, you start paying for 00:17:29.670 --> 00:17:32.250 idle infrastructure. This ensures you're really 00:17:32.250 --> 00:17:34.750 only paying for the exact resources consumed 00:17:34.750 --> 00:17:37.549 during peak usage, which can be dramatically 00:17:37.549 --> 00:17:39.690 cheaper than provisioning for peak all the time. 00:17:40.349 --> 00:17:43.430 Fantastic. So this deep dive, I think it really 00:17:43.430 --> 00:17:45.390 provided that strategic shortcut we were aiming 00:17:45.390 --> 00:17:50.069 for. The takeaways seem clear. Focus on the managed 00:17:50.069 --> 00:17:53.329 aspect. AWS handles the heavy lifting. Understand 00:17:53.329 --> 00:17:56.490 the core divide. Acid for transactional integrity 00:17:56.490 --> 00:17:59.269 versus base for massive scale and availability. 00:17:59.450 --> 00:18:02.380 Yeah. Know the difference between multi -AZ for 00:18:02.380 --> 00:18:05.059 failover insurance and read replicas for boosting 00:18:05.059 --> 00:18:07.619 read performance. And recognize when something 00:18:07.619 --> 00:18:10.339 like DynamoDB, with its guaranteed single -digit 00:18:10.339 --> 00:18:13.180 millisecond latency at any scale, is the right 00:18:13.180 --> 00:18:16.390 tool. Exactly. Maybe the central insight to leave 00:18:16.390 --> 00:18:19.049 everyone with is this. Fundamentally, every database 00:18:19.049 --> 00:18:20.829 service choice you make in the cloud is a cost 00:18:20.829 --> 00:18:22.930 -benefit analysis. It's almost always a trade 00:18:22.930 --> 00:18:25.450 -off, usually between that strict data consistency 00:18:25.450 --> 00:18:27.630 of ACID and the massive scale and availability 00:18:27.630 --> 00:18:29.829 focus of BASE. So the provocative thought might 00:18:29.829 --> 00:18:33.210 be, how does fully internalizing that? How might 00:18:33.210 --> 00:18:35.450 realizing that the BASE model can potentially 00:18:35.450 --> 00:18:38.910 support almost unlimited users? How might that 00:18:38.910 --> 00:18:40.809 fundamentally change the way you architect your 00:18:40.809 --> 00:18:43.619 next consumer -facing application? Especially 00:18:43.619 --> 00:18:46.019 in situations where maybe a few milliseconds 00:18:46.019 --> 00:18:49.259 of data lag is perfectly tolerable, but downtime 00:18:49.259 --> 00:18:52.940 or even just slowness is absolutely not. That's 00:18:52.940 --> 00:18:55.339 a great question to ponder. Thinking about designing 00:18:55.339 --> 00:18:57.920 for base from the start rather than defaulting 00:18:57.920 --> 00:18:59.920 to ACID? It's definitely where a lot of modern 00:18:59.920 --> 00:19:02.079 cloud architecture is heading. It opens up different 00:19:02.079 --> 00:19:04.599 ways of thinking about building resilient scalable 00:19:04.599 --> 00:19:04.920 systems.