1 00:00:00,110 --> 00:00:01,500 Okay, so let's get started 2 00:00:01,500 --> 00:00:04,180 with our first solution architecture discussion, 3 00:00:04,180 --> 00:00:05,820 and I'm really excited 'cause we're going to see 4 00:00:05,820 --> 00:00:07,920 so many different topics all together, 5 00:00:07,920 --> 00:00:09,347 and we'll really understand how they fit 6 00:00:09,347 --> 00:00:12,540 and what other challenges we have as a solutions architect. 7 00:00:12,540 --> 00:00:15,280 So the first website is WhatIsTheTime.com, 8 00:00:15,280 --> 00:00:18,700 and WhatIsTheTime.com allows people to know what time it is. 9 00:00:18,700 --> 00:00:20,170 I know, it sounds stupid, 10 00:00:20,170 --> 00:00:22,310 but at least it's so easy that everyone understands it, 11 00:00:22,310 --> 00:00:24,470 and we'll be able to talk about it at length. 12 00:00:24,470 --> 00:00:26,550 So we don't need a database because it's so simple. 13 00:00:26,550 --> 00:00:29,840 Each instance, each server knows what time it is, 14 00:00:29,840 --> 00:00:31,380 and we want to start small. 15 00:00:31,380 --> 00:00:33,960 We're willing to accept downtime, but overall, 16 00:00:33,960 --> 00:00:35,930 maybe our app will get more and more popular. 17 00:00:35,930 --> 00:00:37,960 People really wanna know the time around the world, 18 00:00:37,960 --> 00:00:41,090 and so we'll need to scale vertically and horizontally, 19 00:00:41,090 --> 00:00:42,770 maybe remove downtime, 20 00:00:42,770 --> 00:00:44,100 and let's go through 21 00:00:44,100 --> 00:00:46,220 the Solutions Architect journey for this app. 22 00:00:46,220 --> 00:00:49,880 You'll see, we'll see a lot of things on how we can proceed. 23 00:00:49,880 --> 00:00:52,100 So let's start really simple. 24 00:00:52,100 --> 00:00:54,810 Okay, let's start from the very beginning. 25 00:00:54,810 --> 00:00:57,440 You're a social architect and you say, 26 00:00:57,440 --> 00:00:58,730 you know what would be great? 27 00:00:58,730 --> 00:01:02,090 You have a t2.micro instance and you have a user, 28 00:01:02,090 --> 00:01:04,450 and the user says what time it is, 29 00:01:04,450 --> 00:01:07,450 and say okay, it's 5:30 p.m. 30 00:01:07,450 --> 00:01:08,710 Done, this is my app. 31 00:01:08,710 --> 00:01:11,010 So we have a public EC2 instance, 32 00:01:11,010 --> 00:01:13,670 and because we wanna make the EC2 instance 33 00:01:13,670 --> 00:01:16,380 have a static IP address in case something happens 34 00:01:16,380 --> 00:01:17,540 and we need to restart it, 35 00:01:17,540 --> 00:01:20,880 then I will attach an elastic IP address to it. 36 00:01:20,880 --> 00:01:22,600 So this is my first PoC. 37 00:01:22,600 --> 00:01:24,100 It's written really great. 38 00:01:24,100 --> 00:01:26,230 Our users are able to access our application, 39 00:01:26,230 --> 00:01:28,330 and we're getting great feedback. 40 00:01:28,330 --> 00:01:31,390 So now, what's happening is that our users 41 00:01:31,390 --> 00:01:33,970 are really having a good time using our application, 42 00:01:33,970 --> 00:01:35,370 so they said to their friends, 43 00:01:35,370 --> 00:01:36,890 hey, you should also use the application. 44 00:01:36,890 --> 00:01:39,380 So another friend comes in and says what time is it? 45 00:01:39,380 --> 00:01:40,520 And 7:30 p.m., 46 00:01:40,520 --> 00:01:42,500 and another friend comes in, what time is it? 47 00:01:42,500 --> 00:01:43,570 6:30 p.m., 48 00:01:43,570 --> 00:01:45,330 and so we realize here that 49 00:01:45,330 --> 00:01:47,750 our application is getting more and more traffic, 50 00:01:47,750 --> 00:01:51,500 and certainly, the t2.micro instance isn't enough, 51 00:01:51,500 --> 00:01:54,490 and so, as a solution architect, we say, wait a minute. 52 00:01:54,490 --> 00:01:57,600 Maybe we should replace that t2.micro instance 53 00:01:57,600 --> 00:01:59,320 by something a little bit bigger 54 00:01:59,320 --> 00:02:01,630 to handle the load, so that's called vertical scaling. 55 00:02:01,630 --> 00:02:05,280 Maybe we'll make it an m5.large type of instance. 56 00:02:05,280 --> 00:02:08,350 So what we do is that we stop the instance, 57 00:02:08,350 --> 00:02:10,000 we change the instance type, 58 00:02:10,000 --> 00:02:11,590 and then, we start again the instance, 59 00:02:11,590 --> 00:02:12,423 and here we go. 60 00:02:12,423 --> 00:02:15,320 This is an M5 type of instance. 61 00:02:15,320 --> 00:02:17,980 So what happened here is that is has the same public IP 62 00:02:17,980 --> 00:02:19,550 because it has an elastic IP address, 63 00:02:19,550 --> 00:02:22,430 so people are still able to access our application, 64 00:02:22,430 --> 00:02:24,820 but we have experienced downtime 65 00:02:24,820 --> 00:02:26,447 while upgrading to an M5, 66 00:02:26,447 --> 00:02:28,910 and so, our users were not really happy. 67 00:02:28,910 --> 00:02:29,743 During that moment, 68 00:02:29,743 --> 00:02:32,430 they were not able to access our application. 69 00:02:32,430 --> 00:02:35,450 So this works, but this isn't great, right? 70 00:02:35,450 --> 00:02:38,380 So next, we're going really popular, 71 00:02:38,380 --> 00:02:40,670 and it's time to scale horizontally, 72 00:02:40,670 --> 00:02:43,740 so we get, remember, this application M5 73 00:02:43,740 --> 00:02:46,280 has one public IP, elastic IP attached to it, 74 00:02:46,280 --> 00:02:48,120 and now, we're getting tons of users, 75 00:02:48,120 --> 00:02:49,830 and so, they're all asking what time is it? 76 00:02:49,830 --> 00:02:52,230 And so now, we wanna scale horizontally, 77 00:02:52,230 --> 00:02:54,420 so we start adding EC2 instances. 78 00:02:54,420 --> 00:02:55,930 They're all m5.large, 79 00:02:55,930 --> 00:02:58,410 and they all have an elastic IP attached to it. 80 00:02:58,410 --> 00:03:01,060 So now, on top of having three EC2 instance, 81 00:03:01,060 --> 00:03:02,700 we have three elastic IP, 82 00:03:02,700 --> 00:03:06,070 and so our users, they need to be aware of the, 83 00:03:06,070 --> 00:03:09,200 the exact values of these three elastic IP 84 00:03:09,200 --> 00:03:11,390 to talk to our instances, 85 00:03:11,390 --> 00:03:13,120 and so, that's called horizontal scaling. 86 00:03:13,120 --> 00:03:15,950 We're doing not bad, but we see we starting kinda 87 00:03:15,950 --> 00:03:16,783 reach some limits. 88 00:03:16,783 --> 00:03:19,800 Now the users need to be aware of more and more IPs, 89 00:03:19,800 --> 00:03:22,400 and we have to manage more infrastructure, 90 00:03:22,400 --> 00:03:24,190 and it's, it's pretty tricky, right? 91 00:03:24,190 --> 00:03:26,950 So okay, let's change the approach. 92 00:03:26,950 --> 00:03:30,410 Now we have three EC2 instances, M5, 93 00:03:30,410 --> 00:03:32,110 and let's remove elastic IP 94 00:03:32,110 --> 00:03:33,900 because it's something that we can't really manage. 95 00:03:33,900 --> 00:03:36,410 There's only five elastic IP per region per account 96 00:03:36,410 --> 00:03:38,150 by default so it's not real lot, 97 00:03:38,150 --> 00:03:41,160 and so, instead, our users, what they're going to do 98 00:03:41,160 --> 00:03:43,500 is that they're going to leverage Route 53, 99 00:03:43,500 --> 00:03:45,180 so we've set up Route 53, 100 00:03:45,180 --> 00:03:49,310 and the website URL is api.whatisthetime.com, 101 00:03:49,310 --> 00:03:52,050 and we've decided it's going to be an A Record 102 00:03:52,050 --> 00:03:54,030 with a TTL of one hour. 103 00:03:54,030 --> 00:03:56,573 An A Record means that from a DNS like this, 104 00:03:56,573 --> 00:03:58,640 it's going to give me a list of IPs, 105 00:03:58,640 --> 00:04:01,700 so remember, Route 53, A Record is IP. 106 00:04:01,700 --> 00:04:04,780 So great, so the users query Route 53, 107 00:04:04,780 --> 00:04:08,180 and then, they get the IP addresses of our EC2 instances, 108 00:04:08,180 --> 00:04:09,240 and they can change over time. 109 00:04:09,240 --> 00:04:10,530 It doesn't really matter 110 00:04:10,530 --> 00:04:12,550 because Route 53 will get updated. 111 00:04:12,550 --> 00:04:14,490 We'll update it and keep it in sync, 112 00:04:14,490 --> 00:04:18,430 and so, our users are now able to access our EC2 instances, 113 00:04:18,430 --> 00:04:20,730 and we don't have any elastic IP to manage anymore, 114 00:04:20,730 --> 00:04:25,010 so using Route 53, we've done some good improvement, 115 00:04:25,010 --> 00:04:28,010 but what happens is that now, we wanna be able to scale, 116 00:04:28,010 --> 00:04:29,810 you know, and be able to add and remove 117 00:04:29,810 --> 00:04:31,190 instances on the fly, 118 00:04:31,190 --> 00:04:34,950 and so, when we do remove an instance, aw, what happens? 119 00:04:34,950 --> 00:04:37,310 Well, it seems like these users at the top, 120 00:04:37,310 --> 00:04:39,910 they were talking to this m5.large instance, 121 00:04:39,910 --> 00:04:41,300 but now, it's gone, 122 00:04:41,300 --> 00:04:45,560 and it turns out that if they do a Route 53 query, 123 00:04:45,560 --> 00:04:47,470 because the TTL was one hour, 124 00:04:47,470 --> 00:04:49,410 they're using the same response for one hour. 125 00:04:49,410 --> 00:04:52,110 So for one hour, they'll try to connect to that instance, 126 00:04:52,110 --> 00:04:54,060 and that instance is gone, 127 00:04:54,060 --> 00:04:55,680 and so, here, it's not really great 128 00:04:55,680 --> 00:04:58,840 because even though these users are having a good time, 129 00:04:58,840 --> 00:04:59,810 and maybe after one hour, 130 00:04:59,810 --> 00:05:02,600 these user will be able to connect to these two instances, 131 00:05:02,600 --> 00:05:03,790 they're not having a good time right now 132 00:05:03,790 --> 00:05:06,220 'cause they think that our application is down, 133 00:05:06,220 --> 00:05:07,740 and that's really, really bad. 134 00:05:07,740 --> 00:05:10,050 So okay, so this is an architecture, 135 00:05:10,050 --> 00:05:11,410 and we see the limit of it. 136 00:05:11,410 --> 00:05:14,220 So how can we push this a little bit further? 137 00:05:14,220 --> 00:05:17,300 So let's talk about adding a load balancer. 138 00:05:17,300 --> 00:05:19,120 So instead, now having, 139 00:05:19,120 --> 00:05:21,790 we don't have public instances anymore. 140 00:05:21,790 --> 00:05:24,140 We have private EC2 instances, 141 00:05:24,140 --> 00:05:26,530 and we're going to launch them in the same Availability Zone 142 00:05:26,530 --> 00:05:28,040 because we don't know any better. 143 00:05:28,040 --> 00:05:29,440 So we've launched them manually. 144 00:05:29,440 --> 00:05:31,870 We have three m5.large instances, 145 00:05:31,870 --> 00:05:34,220 and we are following this course, 146 00:05:34,220 --> 00:05:36,550 and we said okay, let's use a load balancer, 147 00:05:36,550 --> 00:05:37,383 and you know what? 148 00:05:37,383 --> 00:05:39,260 On top of it, it's going to have health checks 149 00:05:39,260 --> 00:05:41,810 such as if one instance is down or not working, 150 00:05:41,810 --> 00:05:43,220 at least we won't send traffic 151 00:05:43,220 --> 00:05:45,250 from our users to the instance. 152 00:05:45,250 --> 00:05:47,470 So okay, we're linking the two together, 153 00:05:47,470 --> 00:05:50,310 so my ELB is going to be public-facing, 154 00:05:50,310 --> 00:05:53,630 whereas my private EC2 instances are in the back, 155 00:05:53,630 --> 00:05:56,160 and so, they restrict traffic between these two 156 00:05:56,160 --> 00:05:59,410 using maybe a security group rule that we've seen before, 157 00:05:59,410 --> 00:06:01,130 using security group as a reference. 158 00:06:01,130 --> 00:06:02,860 Okay, that sounds pretty good. 159 00:06:02,860 --> 00:06:04,670 So now, our users, they're going to query 160 00:06:04,670 --> 00:06:06,370 for WhatIsTheTime.com, 161 00:06:06,370 --> 00:06:09,150 but this time, it cannot be a A Record 162 00:06:09,150 --> 00:06:12,580 because a load balancer has its IP changing all the time, 163 00:06:12,580 --> 00:06:14,650 and so, instead, because it's a load balancer, 164 00:06:14,650 --> 00:06:16,640 we can use an Alias Record, 165 00:06:16,640 --> 00:06:18,750 and this Alias Record is perfect 166 00:06:18,750 --> 00:06:21,230 because it will point from Route 53 to the ELB, 167 00:06:21,230 --> 00:06:23,160 and everything will work really great, 168 00:06:23,160 --> 00:06:25,320 and so, here we change our DNS, but now, 169 00:06:25,320 --> 00:06:27,920 the users connect to our load balancer, 170 00:06:27,920 --> 00:06:32,080 and our load balancers redirects us to our EC2 instances 171 00:06:32,080 --> 00:06:35,300 and balances the traffic out and it's really great 172 00:06:35,300 --> 00:06:37,723 'cause now we can add and remove these instances, 173 00:06:37,723 --> 00:06:39,640 and we just sort them with our load balancer, 174 00:06:39,640 --> 00:06:41,920 and we won't have any downtime for our users 175 00:06:41,920 --> 00:06:43,840 thanks to the health checks feature. 176 00:06:43,840 --> 00:06:45,700 So really, really good, 177 00:06:45,700 --> 00:06:48,720 but now, adding and removing instances manually 178 00:06:48,720 --> 00:06:50,820 is pretty, pretty hard to do, 179 00:06:50,820 --> 00:06:52,900 so what about, we just leverage something 180 00:06:52,900 --> 00:06:54,730 we just learned in this class, 181 00:06:54,730 --> 00:06:57,750 and we'll launch an auto-scaling group. 182 00:06:57,750 --> 00:06:59,860 So now, we have our API on the left-hand side. 183 00:06:59,860 --> 00:07:02,300 It's the same thing, a Route 53, ELB, 184 00:07:02,300 --> 00:07:04,030 but on the right-hand side now, 185 00:07:04,030 --> 00:07:06,260 we're gonna have an Availability Zone, 186 00:07:06,260 --> 00:07:08,350 and we're going to launch private EC2 instances, 187 00:07:08,350 --> 00:07:10,360 but this time, they're going to be managed 188 00:07:10,360 --> 00:07:11,830 by an auto-scaling group, 189 00:07:11,830 --> 00:07:13,990 and so, this allows our auto-scaling group 190 00:07:13,990 --> 00:07:15,290 to basically scale on demand. 191 00:07:15,290 --> 00:07:17,700 Maybe in the morning, no one wants to know the time, 192 00:07:17,700 --> 00:07:19,650 and maybe at night, when people want to leave work, 193 00:07:19,650 --> 00:07:20,910 they wanna know the time. 194 00:07:20,910 --> 00:07:23,170 So we're able to scale based on the demand, 195 00:07:23,170 --> 00:07:24,900 scale in and scale out, 196 00:07:24,900 --> 00:07:26,920 and this is really, really great 197 00:07:26,920 --> 00:07:29,200 because now, we have an application, no downtime, 198 00:07:29,200 --> 00:07:31,730 auto-scaling, load-balanced. 199 00:07:31,730 --> 00:07:34,730 It seems like a really stable architecture, and it is, 200 00:07:34,730 --> 00:07:36,910 but what happens is that, ugh! 201 00:07:36,910 --> 00:07:38,950 There's an earthquake that happens, 202 00:07:38,950 --> 00:07:42,190 and Availability 1 goes down, Zone 1 goes down, 203 00:07:42,190 --> 00:07:43,330 and guess what? 204 00:07:43,330 --> 00:07:44,810 Our application is entirely down. 205 00:07:44,810 --> 00:07:46,740 Our users are not happy, 206 00:07:46,740 --> 00:07:48,580 and so, Amazon comes to us and says, 207 00:07:48,580 --> 00:07:50,050 yes, it's because you haven't 208 00:07:50,050 --> 00:07:51,930 implemented a multi-AZ application, 209 00:07:51,930 --> 00:07:54,150 and we recommend you to implement multi-AZ 210 00:07:54,150 --> 00:07:55,920 to be highly available. 211 00:07:55,920 --> 00:07:57,320 So okay, we say all right. 212 00:07:57,320 --> 00:07:59,540 Let's change a little bit the things. 213 00:07:59,540 --> 00:08:01,100 Now we're gonna have to ELB, 214 00:08:01,100 --> 00:08:02,430 and on top of having health checks, 215 00:08:02,430 --> 00:08:04,670 it's also going to be multi-AZ, 216 00:08:04,670 --> 00:08:07,430 and it's going to be launched on AZ 1 to 3, 217 00:08:07,430 --> 00:08:09,640 so three AZs for this ELB, 218 00:08:09,640 --> 00:08:11,430 and our auto-scaling group as well 219 00:08:11,430 --> 00:08:14,420 is going to span across multiple AZ, 220 00:08:14,420 --> 00:08:16,370 and this allows us maybe to have 221 00:08:16,370 --> 00:08:18,210 two instances in AZ 1, 222 00:08:18,210 --> 00:08:20,593 two instances in AZ 2, and one instance in AZ 3, 223 00:08:20,593 --> 00:08:22,510 and so, the cool thing now is that, 224 00:08:22,510 --> 00:08:25,030 ah, great, like, if AZ 1 goes down, 225 00:08:25,030 --> 00:08:27,080 well, we'll still have AZ 2 and AZ 3 226 00:08:27,080 --> 00:08:29,500 to serve our traffic to our users, 227 00:08:29,500 --> 00:08:32,669 and we've effectively made our app multi-AZ 228 00:08:32,669 --> 00:08:35,980 and highly available and resilient to failure. 229 00:08:35,980 --> 00:08:36,813 Pretty awesome, right? 230 00:08:36,813 --> 00:08:38,440 Okay, how far can we go with this? 231 00:08:38,440 --> 00:08:39,669 Let's keep on going. 232 00:08:39,669 --> 00:08:41,330 So we have two AZ, 233 00:08:41,330 --> 00:08:43,000 and we know that at least one instance 234 00:08:43,000 --> 00:08:44,610 will be running in each AZ, 235 00:08:44,610 --> 00:08:46,410 so why don't we reserve capacity? 236 00:08:46,410 --> 00:08:48,860 Why don't we start basically 237 00:08:48,860 --> 00:08:50,910 diminishing the cost of our application 238 00:08:50,910 --> 00:08:52,610 because we know that for sure, 239 00:08:52,610 --> 00:08:56,030 two instances must be running at all time during the year? 240 00:08:56,030 --> 00:08:57,850 And so, by reserving instance, 241 00:08:57,850 --> 00:09:01,080 maybe for the minimum capacity of our auto-scaling group, 242 00:09:01,080 --> 00:09:04,510 then we're going to save a lot of cost in the future 243 00:09:04,510 --> 00:09:06,420 whereas the new instances that get launched, 244 00:09:06,420 --> 00:09:08,940 maybe they're gonna be temporary, so on demand is fine, 245 00:09:08,940 --> 00:09:12,020 or if we're a bit crazy, we could even use spot instances 246 00:09:12,020 --> 00:09:13,960 for a less, less cost, 247 00:09:13,960 --> 00:09:16,830 but we might have the instances being terminated, 248 00:09:16,830 --> 00:09:18,910 and so, it's really interesting, right, 249 00:09:18,910 --> 00:09:21,450 because we've seen an architecture 250 00:09:21,450 --> 00:09:24,240 going from a very small application 251 00:09:24,240 --> 00:09:26,040 all the way to a, you know, 252 00:09:26,040 --> 00:09:27,660 load-balanced, auto-scaling group, 253 00:09:27,660 --> 00:09:29,520 multi-AZ, health checks, 254 00:09:29,520 --> 00:09:31,770 reserved instances that with our application, 255 00:09:31,770 --> 00:09:33,290 and so, to me, that's, 256 00:09:33,290 --> 00:09:36,150 as a solutions architect, your journey. 257 00:09:36,150 --> 00:09:39,180 It's up to understand what are the requirements? 258 00:09:39,180 --> 00:09:41,380 And what should we architect 259 00:09:41,380 --> 00:09:42,980 in returns to these requirements? 260 00:09:42,980 --> 00:09:44,820 And this is where the exam will test you. 261 00:09:44,820 --> 00:09:46,940 Now this is the first architecture discussion. 262 00:09:46,940 --> 00:09:50,000 Trust me, there will be many others in the next lecture, 263 00:09:50,000 --> 00:09:52,430 but for now, let's just review what we've discussed. 264 00:09:52,430 --> 00:09:54,300 What we've discussed, for example, 265 00:09:54,300 --> 00:09:56,260 what it is to, for an EC2 instance, 266 00:09:56,260 --> 00:09:58,730 to have a public IP and a private IP. 267 00:09:58,730 --> 00:10:01,550 You know, where does it fit in our architecture diagram? 268 00:10:01,550 --> 00:10:05,110 We also seen what is the benefit of having an elastic IP 269 00:10:05,110 --> 00:10:08,880 versus using Route 53 versus maybe using a load balancer 270 00:10:08,880 --> 00:10:10,340 for our application. 271 00:10:10,340 --> 00:10:14,170 We've also seen that thanks, because of the Route 53 TTL, 272 00:10:14,170 --> 00:10:16,350 we couldn't really use A Records, 273 00:10:16,350 --> 00:10:19,890 so we had to use an load balancer and Alias Record 274 00:10:19,890 --> 00:10:21,370 and so that we'll be able to see 275 00:10:21,370 --> 00:10:23,870 how Route 53 can fit in this whole picture. 276 00:10:23,870 --> 00:10:26,830 We've seen how to maintain EC2 instances manually, 277 00:10:26,830 --> 00:10:28,780 and then, we say, all right, it's too much maintenance. 278 00:10:28,780 --> 00:10:30,700 Let's use auto-scaling groups, and you know what? 279 00:10:30,700 --> 00:10:33,030 It's actually gonna provide us even better costing 280 00:10:33,030 --> 00:10:34,802 because it will just scale on demand, 281 00:10:34,802 --> 00:10:36,390 and we'll just have the perfect amount 282 00:10:36,390 --> 00:10:38,370 of EC2 instances at any time, 283 00:10:38,370 --> 00:10:41,000 and then, we said okay, let's go into multi-AZ. 284 00:10:41,000 --> 00:10:43,080 We can survive disasters this way, 285 00:10:43,080 --> 00:10:45,200 and let's enable ELB health checks 286 00:10:45,200 --> 00:10:48,840 such as only the instances that are correctly responding 287 00:10:48,840 --> 00:10:50,250 do get traffic, 288 00:10:50,250 --> 00:10:52,620 and we've seen how to set up security group rules 289 00:10:52,620 --> 00:10:55,720 so that the EC2 instances will only receive traffics 290 00:10:55,720 --> 00:10:57,280 coming from the ELB, 291 00:10:57,280 --> 00:10:58,980 and finally, we said, you know what? 292 00:10:58,980 --> 00:11:00,510 Let's look at capacity. 293 00:11:00,510 --> 00:11:01,850 Let's do some cost-saving. 294 00:11:01,850 --> 00:11:04,030 We always know that we want two EC2 instances 295 00:11:04,030 --> 00:11:04,950 running at any time, 296 00:11:04,950 --> 00:11:06,810 so let's reserve these instances, 297 00:11:06,810 --> 00:11:09,850 and they will bring lots of cost savings, 298 00:11:09,850 --> 00:11:12,270 and so, all this discussion right here, 299 00:11:12,270 --> 00:11:13,103 there's the thing called 300 00:11:13,103 --> 00:11:15,710 the Well-Architected Framework in AWS, 301 00:11:15,710 --> 00:11:17,270 and we'll be talking about it 302 00:11:17,270 --> 00:11:19,570 at length as well in the dedicated section, 303 00:11:19,570 --> 00:11:21,000 but there's five pillars to it, 304 00:11:21,000 --> 00:11:22,760 and there's cost, performance, reliability, 305 00:11:22,760 --> 00:11:24,780 security, and operational excellence, 306 00:11:24,780 --> 00:11:26,710 and so, through these discussion, 307 00:11:26,710 --> 00:11:27,980 I want to educate you 308 00:11:27,980 --> 00:11:30,730 that we have actually seen these five pillars. 309 00:11:30,730 --> 00:11:33,300 So cost, cost has many different purpose, 310 00:11:33,300 --> 00:11:36,060 so maybe we're scaling up our instance vertically. 311 00:11:36,060 --> 00:11:37,850 Maybe we're using ASG to just have 312 00:11:37,850 --> 00:11:40,630 the right amount of instances based on the load, 313 00:11:40,630 --> 00:11:43,840 and maybe we wanna reserve instances as well 314 00:11:43,840 --> 00:11:45,280 to optimize cost. 315 00:11:45,280 --> 00:11:48,120 In terms of performance, well, we've seen vertical scaling. 316 00:11:48,120 --> 00:11:50,930 We've seen ELBs, we've seen auto-scaling groups, 317 00:11:50,930 --> 00:11:53,570 basically how we can adapt to performance over time. 318 00:11:53,570 --> 00:11:56,820 Reliability, we'll seen how Route 53 can be used 319 00:11:56,820 --> 00:11:58,700 to basically reliably direct the traffic 320 00:11:58,700 --> 00:12:00,380 to the right EC2 instances, 321 00:12:00,380 --> 00:12:02,950 and maybe using multi-AZ for the ELB 322 00:12:02,950 --> 00:12:05,610 and multi-AZ for the ASG as well. 323 00:12:05,610 --> 00:12:08,420 For security, we've seen how we can use security groups 324 00:12:08,420 --> 00:12:09,960 to basically link the load balancer 325 00:12:09,960 --> 00:12:11,750 to our instances reliably, 326 00:12:11,750 --> 00:12:13,270 and operational excellence, 327 00:12:13,270 --> 00:12:16,940 how we can evolve from a very clunky, manual process 328 00:12:16,940 --> 00:12:19,070 all the way to having it fully automated 329 00:12:19,070 --> 00:12:21,780 with auto-scaling groups, et cetera, et cetera. 330 00:12:21,780 --> 00:12:23,410 So really awesome. 331 00:12:23,410 --> 00:12:24,840 I think this is a good discussion, 332 00:12:24,840 --> 00:12:25,760 and we'll have many others, 333 00:12:25,760 --> 00:12:27,270 but as a solutions architect, 334 00:12:27,270 --> 00:12:30,470 start understanding what other technology we've seen 335 00:12:30,470 --> 00:12:33,140 and how they fit together and how they solve problems 336 00:12:33,140 --> 00:12:36,250 all together when, when configured correctly. 337 00:12:36,250 --> 00:12:37,083 So that's it. 338 00:12:37,083 --> 00:12:39,653 I hope you liked it, and I will see you in the next lecture.