Free Webinar: Architecting on AWS

IT Training and Development Resources
Webinars
Free Webinar: Architecting Resilient and Scalable Solutions on AWS [Webinar]

In this informative session, Ryan Dymek, AWS expert and seasoned trainer will guide you through:

Discovering the five pillars of the AWS Well-Architected Framework.
Understanding the business benefits of a well-architected cloud environment.
Learning practical strategies for designing and deploying secure and scalable applications on AWS.
Identifying common architectural pitfalls and learn how to avoid them.
Exploring real-world case studies of successful AWS implementations.

About the presenter, Ryan Dymek:

Ryan Dymek is a seasoned enterprise technology expert with 25 years of experience helping companies leverage creative data solutions. Since 2009, he has been a leading cloud trainer and consultant and is an AWS Authorized Instructor Champion and GCP Authorized Instructor. In addition to expertise in AI/ML, automated workflows, and DevSecOps security, Ryan possesses every available AWS Certification, numerous GCP Certifications, and various independent DevOps and Security certifications.

00:00:03.670 --> 00:00:17.149
Axcel ILT: Hi, everybody! Welcome to this aws, Webinar! I'm here with my colleague, Ryan Demock, and he will be talking about how to architect resilient and scalable solutions on aws here in just a moment.

2
00:00:17.660 --> 00:00:40.290
Axcel ILT: Just want to welcome everybody, and also thanks Ryan for being here, and thank you all for joining us as well. My name is Anne, and on behalf of Excel instructor led training. I'd like to welcome you to this webinar, and just in case you didn't know who we are. We are accelerate, exit certified, and webage solutions, and among us we have more than 60 years of experience in the it training business.

3
00:00:40.290 --> 00:00:55.619
Axcel ILT: which is great news for you, because that means you get access to all of our certificates, all of our partners, curriculum trainers. We do have a little little nuances here and there accelerate focuses on customized courses for teams.

4
00:00:55.620 --> 00:01:18.000
Axcel ILT: exit certified, has all the vendor authorized certification courses and webage solutions, focuses a lot on upskilling programs for entire organizations exit certified. And webage also has public online courses. We do teach a lot of aws. All 3 of us do, plus a lot of other technologies, but it doesn't matter who you contact.

5
00:01:18.000 --> 00:01:21.759
Axcel ILT: We'll we'll get you the right people, and we'll get you the training that you need

6
00:01:22.179 --> 00:01:43.169
Axcel ILT: and speaking of training, we are running an architecting on aws course that maps very well to this webinar it will be a live public course running November 19th to the 21.st So it's 3 days live. Instructor led hands on. And we are offering for these dates a 60% off with the promo code. Save aws!

7
00:01:43.170 --> 00:02:02.080
Axcel ILT: I will put that in the chat, and I'll also put that URL is a bit long in the chat, and then you can find the dates. Go there and register if you'd like. If that course is not exactly what you're looking for, or you need other dates. Don't worry. You can also get 25% off any other training, public or private.

8
00:02:02.080 --> 00:02:27.350
Axcel ILT: almost any other technology with promo code train 25. And I'll put that in the chat, too. I know that's a lot of information. We are. We are running a lot of end of year. Deals right now. And let's meet Ryan. I've had the pleasure of working with Ryan for at least maybe 6 months to a year. He teaches a lot of our aws courses with rave reviews. He's a cloud expert with 25 years of experience.

9
00:02:27.350 --> 00:02:52.250
Axcel ILT: He's also an Aws authorized instructor. Champion. He has almost yeah, pretty much every available Aws certification, and if we listed them all, I think we'd be here for more than an hour. So you know, we'll just say that there it's all. And I think that's that's kind of a unicorn. I don't know how many people are able to boast that, so I really can't think of a better person to be leading this webinar, and luckily for us, he teaches aws and

10
00:02:52.250 --> 00:02:58.690
Axcel ILT: other courses for excel. Ilt. Okay. So with that, Ryan, I'm going to go ahead and

11
00:02:59.284 --> 00:03:04.629
Axcel ILT: stop my share and pass the torch to you.

12
00:03:04.630 --> 00:03:08.079
Ryan Dymek: Fantastic. So let me go ahead and reshare here.

13
00:03:16.390 --> 00:03:17.270
Ryan Dymek: Right?

14
00:03:17.900 --> 00:03:33.780
Ryan Dymek: Okay. So today's talk. So this is an architecting talk. But I have to tell you. Obviously, we can't do the 3 day architecture that we would normally do the architecting on. Aws, course, it's a 3 day course we would, of course, go. You know much, much cheaper, obviously, than we do in 1 h.

15
00:03:33.970 --> 00:03:39.140
Ryan Dymek: But the whole premise of architecting in aws is actually based

16
00:03:39.270 --> 00:03:43.120
Ryan Dymek: off of these, what we call 6 pillars of the well architected framework.

17
00:03:43.250 --> 00:04:07.740
Ryan Dymek: and that's kind of the core to everything we do in aws. Quite frankly, whether you're talking specifically the architecting on aws course or certification as well. But really everything in aws comes down to architecture. It doesn't matter if you're architecting. If you're designing a piece of software like, maybe you're a developer or developer team, maybe your security engineers, maybe your data engineers.

18
00:04:07.740 --> 00:04:14.239
Ryan Dymek: maybe your data analysts, whatever it might be. There's probably some level of of architecture taking place.

19
00:04:14.653 --> 00:04:17.469
Ryan Dymek: Let me see, not able to view the screen.

20
00:04:17.680 --> 00:04:22.140
Ryan Dymek: Can others, just to just check in real quick before I get too far down this path? Are we able to see the screen? Okay.

21
00:04:22.920 --> 00:04:26.260
Axcel ILT: Yes, Ryan, I can see it. Let me see if I can. Wonderful.

22
00:04:26.260 --> 00:04:29.698
Ryan Dymek: Okay, good. Just making sure. So we just had a comment in the chat. I just wanted to make sure.

23
00:04:29.890 --> 00:04:53.469
Ryan Dymek: All good, fantastic. Thank you everybody. So in all reality, as we're designing and architecting solutions. And, by the way, when you take training, you have the architecting on aws, course, we've got other courses like data engineering. We've got courses around, you know, around advanced architecting or devops, or all these things. At the end of the day they almost all come down to architecture, though. And so this is actually one of the things I tell people.

24
00:04:53.942 --> 00:04:55.240
Ryan Dymek: No matter what

25
00:04:55.340 --> 00:05:17.700
Ryan Dymek: discipline or what direction you're going to be heading in Aws. The architecting on Aws course itself is actually a fundamental course that I would suggest everybody take at some point because it doesn't. You don't have to be an architect for that class to be extremely valuable. You could be a developer. You could be again devops, engineer, any number of things. And so at the end of the day all this stuff comes down to architecture.

26
00:05:17.880 --> 00:05:24.610
Ryan Dymek: and in Amazon there's what we call the 6 pillars of the well architected framework, and everything kind of comes back to this

27
00:05:24.650 --> 00:05:31.446
Ryan Dymek: under most conditions. And and so so what's what we're talking about here is that there's kind of these different

28
00:05:32.020 --> 00:05:44.700
Ryan Dymek: best practices of sorts. And when I say that loosely talk about that, a best practice in aws is not a recipe for success. A best practice in Amazon is not like a prescription.

29
00:05:44.870 --> 00:06:02.120
Ryan Dymek: Okay, it's actually a set of principles that we kind of abide by. It's not about. We're not going to say under all conditions. Do this or do that. Okay? Because every situation is different. So it's more about being able to evaluate

30
00:06:02.300 --> 00:06:07.999
Ryan Dymek: what outcome. You want. Right? Let's let's let's evaluate the design and meet the outcome.

31
00:06:08.170 --> 00:06:11.818
Ryan Dymek: If that outcome is focused more on

32
00:06:12.500 --> 00:06:34.910
Ryan Dymek: cost or security. Other things. These are all factors that we should be considering. It doesn't help us if we're building the most cost, effective solution. But it's insecure. It doesn't help us if we're building the most secure solution. That's not useful. Right? I always tell people the most secure solution you can come up with. Imagine this. I write some really sensitive data to a hard drive.

33
00:06:35.250 --> 00:06:47.499
Ryan Dymek: I take that hard drive. We encase it in a bunch of cement. We take that cement, and we go find the deepest point in the ocean that we can find, and then we go a mile below that we dig a mile down underneath the earth's crust. Bury it, you know.

34
00:06:48.150 --> 00:07:01.877
Ryan Dymek: Sure it's secure. Nobody's getting access to it at that point, but nobody's getting access to it. Even the people that need it, right? So we have to find some balance at all times right? And so this is a great kind of guide to helping us.

35
00:07:02.180 --> 00:07:06.300
Ryan Dymek: achieve what we're trying to achieve in aws through our designs.

36
00:07:06.340 --> 00:07:29.050
Ryan Dymek: But we can't just have a myopic view of just one of these things. I can't just be a security minded person only and not care about cost or not care about performance. But we also need to make sure we're still secure. So we need to find a balance of all of these things. And so Amazon has produced these 6 pillars of the well architected framework, and each one of these actually calls out very specific best practices that we really should be looking at.

37
00:07:29.090 --> 00:07:56.739
Ryan Dymek: Obviously, in 1 HI don't have time to go through all of these and give all kinds of great examples to the degree that I would love to do. And of course this is not an official Aws training course. That's what the coming architecting aws course would be for. But here we're kind of just giving you kind of a big picture of some of the stuff that maybe matters, and how we how we have to think about these things different in the cloud. So our way of thinking has to be substantially different than it is on premises.

38
00:07:56.960 --> 00:08:02.809
Ryan Dymek: and we can get into the why. Why, that is, if we had more time. But high level.

39
00:08:03.204 --> 00:08:10.780
Ryan Dymek: You're essentially just renting these resources for a moment in time. Right? So when I go to run some workload in aws.

40
00:08:10.820 --> 00:08:16.220
Ryan Dymek: I might pay to literally just run that action at that exact moment in time.

41
00:08:16.310 --> 00:08:27.119
Ryan Dymek: Well, why does that matter in in our architectures? Well, when I'm building things on premises, I'm buying hardware. I'm I'm building these things out. It might even take me months to get that stuff right

42
00:08:27.200 --> 00:08:45.030
Ryan Dymek: in. Aws, I just run the action and I pay for the action. So that means how I use it is probably going to be different. What kind of things does that action explicitly need access to? How does that affect my performance? Is there a positive or a negative to the performance here. These are all things we really kind of need to be looking at right.

43
00:08:45.040 --> 00:08:58.059
Ryan Dymek: If you go to build things in aws the way you built them on. Prem, the way you used to build them. If you build them the same way here, you're probably going to have a huge expense.

44
00:08:58.469 --> 00:09:05.120
Ryan Dymek: That's that's going to come up right. Huge expense. You're gonna have some security concerns, and so on.

45
00:09:05.442 --> 00:09:08.220
Ryan Dymek: And so we got to be careful with that, all right.

46
00:09:08.430 --> 00:09:14.230
Ryan Dymek: So what we'll let's gonna walk through a couple of these, I'm not going to be able to get through all of them in the hour that we have.

47
00:09:14.520 --> 00:09:26.109
Ryan Dymek: I'm gonna give you a couple of examples that we're gonna talk about operational excellence. We'll talk about security. I'm just gonna jump down and talk a little bit about costs as well as just some examples of things that that we we need to consider. Okay.

48
00:09:26.487 --> 00:09:32.640
Ryan Dymek: and so that's that's kind of the big picture there. I'm not gonna get into all of these. We would be here for quite some time.

49
00:09:32.820 --> 00:09:35.890
Ryan Dymek: so let me slightly shift gears.

50
00:09:38.536 --> 00:09:43.429
Ryan Dymek: Well, actually, yeah, let me share my other screen. Here, there we go, perfect.

51
00:09:43.670 --> 00:09:48.700
Ryan Dymek: So these are again. This is an Amazon page. Here the well architected page from Amazon.

52
00:09:49.134 --> 00:09:54.990
Ryan Dymek: In this case, it's kind of calls out each each pillar. Okay? And there's just a real quick summary on each one.

53
00:09:55.010 --> 00:10:01.429
Ryan Dymek: and then, of course, you could dive into each one of these. If I go into the operational Excellence pillar, I click into it on the HTML.

54
00:10:01.470 --> 00:10:12.239
Ryan Dymek: It's kind of a breakdown on all of this, and you'll see that there's actually best practices outlined here. Okay? And, interestingly enough, the very first, st best practice

55
00:10:12.350 --> 00:10:15.980
Ryan Dymek: is that we actually start with our customer needs go figure

56
00:10:16.880 --> 00:10:28.789
Ryan Dymek: a lot of traditional. It designs don't do this ironically enough, right and kind of I've been working in the it landscape and the Enterprise landscape, you know, for over 25 years the amount of times I've seen

57
00:10:29.420 --> 00:10:35.409
Ryan Dymek: great brilliant designs that don't meet the business requirements. It happens all the time. Okay.

58
00:10:35.676 --> 00:10:42.090
Ryan Dymek: it's it's it's like we build in this vacuum. And and we can't do that in the cloud the whole point of the cloud. The whole

59
00:10:42.310 --> 00:10:49.260
Ryan Dymek: point of a lot of this stuff is to actually fulfill the business requirements. And so we start with that right? And then let's figure out what we need to build according.

60
00:10:49.830 --> 00:11:10.830
Ryan Dymek: And so we have these customer needs. Let's take a look at them and look at, and then we work backwards from the customer outcomes. So we actually start with, what is it that we are building? What is this thing that we're we're building here. And this is going to be unique on a case by case basis. Right? The thing that we're producing here is going to be very different from one project to another project, or from one app to another. App

61
00:11:11.080 --> 00:11:22.809
Ryan Dymek: and look at this right here level of risk exposed. If this is not established. Right? I mean, this is going to cause a huge risk. And what kind of risk are we talking about? This could actually be security risks, cost risks.

62
00:11:23.231 --> 00:11:31.509
Ryan Dymek: availability risks, all kinds of things that could actually stem from this if we don't, if we aren't careful with how we manage this right?

63
00:11:31.580 --> 00:11:43.019
Ryan Dymek: And so the operational excellence pillar is actually all about operating the system. And this is an important one. Because I'm not just a trainer. Actually, I do plenty of training. We do, we work, we're great. We do a lot of different classes.

64
00:11:43.040 --> 00:11:54.009
Ryan Dymek: but also a portion of my time is actually spent consulting with customers. And so I work with this space. I don't just train it. I actually work in in it on a day, day by day basis with many customers

65
00:11:54.300 --> 00:12:06.359
Ryan Dymek: and the the amount of times I'm hired for a project. I I this is this is absolutely crazy. The amount of times I've been hired for a project where a customer says, let's build X, okay, so we build that

66
00:12:06.740 --> 00:12:09.220
Ryan Dymek: or focused on building that, I should say.

67
00:12:09.290 --> 00:12:18.089
Ryan Dymek: And I started asking questions around operations. I started asking questions around how it's going to be supported. And I've had a few customers. Say, Ryan.

68
00:12:18.230 --> 00:12:31.700
Ryan Dymek: we hired you to to build this thing or help us build this thing. We we didn't. We didn't bring you on to to work with support, like support is we can deal with that later, you know. And and that's kind of the message.

69
00:12:31.780 --> 00:12:52.189
Ryan Dymek: And I go. On the contrary, we can't build this until we know how we're going to run it. Okay, what is this going to look like from a running perspective and then work our way backwards? This is the 1st best practice that Amazon actually calls out, we say, start with the customer needs and work our way backwards. And these customer outcomes are not just a product.

70
00:12:52.400 --> 00:13:04.150
Ryan Dymek: The outcomes include things like resiliency requirements and the ability to scale right the ability to monitor and observe what's going on. Those are all requirements that we have to start with and work our way back from this.

71
00:13:04.584 --> 00:13:07.419
Ryan Dymek: I could. I could recommend the best solution

72
00:13:07.500 --> 00:13:11.659
Ryan Dymek: in existence on some, you know, on some need.

73
00:13:11.740 --> 00:13:23.389
Ryan Dymek: but if you can't support it as an organization, right? So, example, what if we build out this whole thing? And it's built all in python code? And it's all this. You don't have a single python developer on staff

74
00:13:23.830 --> 00:13:25.299
Ryan Dymek: makes no sense. Right?

75
00:13:25.390 --> 00:13:32.670
Ryan Dymek: So that's that's a very simple best practice. But it's sometimes a lot harder and and a lot less obvious than people will give it credit for.

76
00:13:33.077 --> 00:13:41.589
Ryan Dymek: Operational needs are very, very important. So we start here. We say, how are we gonna run the system that we're going to build out and then work our way backwards from that

77
00:13:41.600 --> 00:13:50.879
Ryan Dymek: right? And and so we have to start here. And this is not the. This is not the fancy technical stuff, right? This doesn't always get us down this exciting technical path.

78
00:13:50.980 --> 00:13:59.610
Ryan Dymek: But it's a must right. We have to start with the business mindset and say, what is the problem we're solving? And how are we going to solve it? And is the solution actually viable.

79
00:13:59.900 --> 00:14:17.149
Ryan Dymek: There's a hundred ways to solve these problems. And we don't want to choose the solution that doesn't work by operations. Right? So it's kind of frustrating. When I work with a customer of something like that, where they say, let's ignore operations like I can't. We can't know how to build this without operations. We have to start with that actually.

80
00:14:17.360 --> 00:14:23.709
Ryan Dymek: and then work our way into the actual build out. Okay, you can't just build in a vacuum. So this is, this is a big one.

81
00:14:23.800 --> 00:14:24.879
Ryan Dymek: Now, the

82
00:14:26.300 --> 00:14:39.339
Ryan Dymek: these pillars are again big, high level concepts. Right? And so I kind of, you know, just talking about observability or operational, rather operational, includes the concept of observability as well. You see, down here we have, like

83
00:14:39.490 --> 00:14:58.330
Ryan Dymek: we have organizational. We got preparing. We've got operate and evolve inside of these. You're going to have some stuff around observability around monitoring without getting into all the all the nuances here we could spend all day just on one pillar if we really wanted to. We're going to make this kind of brief here, and we're going to move on to other pillars.

84
00:14:58.640 --> 00:15:00.600
Ryan Dymek: But the thing is

85
00:15:01.710 --> 00:15:20.669
Ryan Dymek: we have to start here and then work our way out from operations. It doesn't matter if we build something super secure. If we build something that is extremely cost effective if we can't run it right? So we start here. And then inside of this includes things like monitoring. And what a new term that we, a newer term that's emerged kind of over the last

86
00:15:21.290 --> 00:15:39.450
Ryan Dymek: 5 to 10 years is this phrase called observability. Okay, observability is different than monitoring. Monitoring is about metrics a lot of times. Okay, CPU spikes and how much disk space I have. And those things those are classic monitoring metrics.

87
00:15:40.309 --> 00:15:49.270
Ryan Dymek: I don't know if anybody here remembers the old Sherlock Holmes shows, or actually, there was even a movie more recently on that.

88
00:15:49.390 --> 00:15:55.169
Ryan Dymek: But there's a saying that Sherlock Holmes used to actually say, and it would be, you see. But you do not observe.

89
00:15:55.260 --> 00:16:15.830
Ryan Dymek: And unfortunately, this also happens a lot in it, right in the technical landscape. Okay, we have all these metrics. But what do they mean? Right, are they? What is the bigger picture? What is that picture that's being painted with those metrics. Is there some sort of analytics we could be doing against those metrics to give us some sort of bigger understanding around all of that.

90
00:16:15.830 --> 00:16:27.129
Ryan Dymek: And so we need to actually understand the data more than just capture the data. And so there's actually a lot of tools in Amazon that that actually help us with this.

91
00:16:27.500 --> 00:16:36.390
Ryan Dymek: And so if I kind of come back here under observability, we've got this this terminology. It's it's actually an acronym called melt

92
00:16:36.440 --> 00:16:42.639
Ryan Dymek: metrics, events, logs, and traces. This is what observability actually consists of.

93
00:16:42.650 --> 00:16:48.189
Ryan Dymek: So we've got metrics which are typically captured in a product in Amazon called cloudwatch.

94
00:16:48.520 --> 00:16:58.719
Ryan Dymek: We've got events which are event handling or event driven workloads. Things like that. Things that occur in our environment are events. A metric might just be.

95
00:16:59.168 --> 00:17:06.350
Ryan Dymek: Let's say, CPU load is anywhere between 0 and 100%. And it's constantly moving right?

96
00:17:06.903 --> 00:17:11.620
Ryan Dymek: That's not an event in time, right? An event is something occurred

97
00:17:11.690 --> 00:17:36.200
Ryan Dymek: right? So maybe I don't know. Maybe a file was written. Some data was updated. You know, something was deleted, or any number of things. Those can all be events that occur, and those events are opportunities to do something at the moment that event occurs. And so there's products in Amazon designed to handle and route those events and initiate actions based on those events.

98
00:17:36.200 --> 00:17:46.909
Ryan Dymek: So as an example, I can write something to S. 3. Now, if you're not familiar with S. 3. We can, you know, talk all about that in in other training sessions. But it's basically a place to store some data.

99
00:17:47.610 --> 00:17:51.689
Ryan Dymek: When data is written to S. 3, I could have an event

100
00:17:51.730 --> 00:17:57.949
Ryan Dymek: automatically kick off a data processing job to convert that data and load it into a database.

101
00:17:58.080 --> 00:18:12.279
Ryan Dymek: So now all I need to do is drop that data on S. 3, and it ends up in the database drops more data on s. 3. It ends up in the database. Okay? So events are things that are a moment in time. Something occurs and I can automate against that.

102
00:18:12.800 --> 00:18:32.309
Ryan Dymek: Logs are gonna be actual actions that are happening outcomes, you know, stuff that's being written to the screen. Any any number of things. And so those all need to be captured as well. And there's basically a couple of different logging systems in Amazon depending on how we're using them and and so on. So of course, we can evaluate those logs.

103
00:18:32.906 --> 00:18:35.359
Ryan Dymek: I have a very strong background in security.

104
00:18:36.020 --> 00:18:45.520
Ryan Dymek: And and I'll tell you, I got very heavily involved in data about 10 years ago, I started really focusing on big data data, analytics and machine learning

105
00:18:45.700 --> 00:18:48.749
Ryan Dymek: because of security. Interestingly enough.

106
00:18:48.790 --> 00:18:57.210
Ryan Dymek: And what got me there was logs, interestingly enough, is, I kind of came to this realization that almost every company out there did a great job at collecting logs.

107
00:18:58.280 --> 00:19:01.659
Ryan Dymek: But just because you collect them doesn't mean you're doing anything with them.

108
00:19:01.720 --> 00:19:04.420
Ryan Dymek: So the majority of companies collected logs.

109
00:19:04.480 --> 00:19:06.839
Ryan Dymek: but did a terrible job at doing anything with them.

110
00:19:07.120 --> 00:19:15.349
Ryan Dymek: And it's like this is live information. This is stuff you have knowledge about your environment that's going on right now. And you're not doing anything with it.

111
00:19:15.830 --> 00:19:37.859
Ryan Dymek: In fact, there's some security stuff out there that might actually say that that up to 80% of our security posture comes from these logs. And if we're not using these logs. We're missing the boat on 80% of our security. Okay? So we should be processing these in near real time. We should be analyzing these apply machine learning to the logs. Do analysis of these logs right now.

112
00:19:38.170 --> 00:19:41.800
Ryan Dymek: Fortunately, there's actually services in Amazon that do exactly that.

113
00:19:41.810 --> 00:19:52.049
Ryan Dymek: that that make this actually a fairly easy job to do so. These logs contain very valuable information, and we can have automated systems that do that. So here's the thing we start to see with the cloud.

114
00:19:53.060 --> 00:19:54.520
Ryan Dymek: The cloud is not virtual machine.

115
00:19:54.590 --> 00:19:58.740
Ryan Dymek: Okay, virtual machines existed long before Aws was around.

116
00:19:58.920 --> 00:20:01.030
Ryan Dymek: Okay, we could do virtual machines

117
00:20:01.270 --> 00:20:03.779
Ryan Dymek: many years prior many years. Prior. Okay.

118
00:20:04.487 --> 00:20:13.770
Ryan Dymek: what makes cloud so special? You know, whether we're talking Aws or Google or azure? Oci, I mean, there's a lot of cloud providers. Right?

119
00:20:14.065 --> 00:20:21.490
Ryan Dymek: But what makes cloud in general so interesting is it's not just virtual machines. It's not just somebody else's data center. I know some people say that

120
00:20:21.590 --> 00:20:27.549
Ryan Dymek: it's the fact that you get potentially decades of research and development

121
00:20:27.570 --> 00:20:48.160
Ryan Dymek: incorporated in some product that you're able to use and just use it like that right? And so some of these products, it's like, Hey, I need to analyze logs in near real time and apply machine learning to them. Guess what Amazon already does that you don't actually need to develop that solution. It's already there. In fact, in some cases it's just a couple of checks to the box, and you can make it happen. We'll talk about that.

122
00:20:48.230 --> 00:21:03.990
Ryan Dymek: There's actually a product in Amazon called guard duty that will analyze these logs from a security perspective and help. You understand anomalies inside of your logs, things that are going on and say, wait a second. It looks like somebody's doing a reconnaissance for some attack, some future attack.

123
00:21:04.090 --> 00:21:10.480
Ryan Dymek: or somebody's right now in the middle of of attacking you right now. And and here's some stuff that's going on, and we're seeing it in the logs.

124
00:21:10.610 --> 00:21:12.710
Ryan Dymek: So you don't have to do that work

125
00:21:12.790 --> 00:21:17.339
Ryan Dymek: right. And this is the beauty of the cloud is you're actually able to take advantage

126
00:21:17.360 --> 00:21:30.819
Ryan Dymek: of 20, even 30 years of knowledge gained at Amazon. And all this research and development with some of the brightest, best people in the world on this stuff, and you're able to just use it right. Nothing to install in a lot of cases is literally just just use it

127
00:21:31.293 --> 00:21:55.380
Ryan Dymek: whereas, historically, if I did the stuff on premises, I would have to go buy expensive appliances, install those, set them up, pay for professional installation. We might not even get rolling on that for for 6 months. And meanwhile it's a massive investment to even get to that point. Meanwhile, in the cloud, it's it's it's a checkbox, or it's a single Api call right? It's a single command line entry, something like that. Very simple stuff. A lot of times.

128
00:21:55.740 --> 00:22:06.149
Ryan Dymek: Traces are for microservices, Api, tracing and things. So if you have microservices where you have service, A talking to service. B, talking to service, C, talking to service, D,

129
00:22:06.410 --> 00:22:12.719
Ryan Dymek: tracing that request through the system being able to diagnose which of those systems is maybe the problem.

130
00:22:12.850 --> 00:22:33.929
Ryan Dymek: Maybe service a, you know, the front end. It looks like something is slow. But is it is a BC or D that's actually causing the slowness. Something like tracing is actually a part of that landscape to be able to identify where that slowness is coming from, where the latencies are coming from the load and all that. So we need to use traces. Well again, there's a service in Amazon that just does this for us that's called X-ray.

131
00:22:34.100 --> 00:22:39.950
Ryan Dymek: And so we can incorporate a lot of these services and get up to speed on things that normally would have taken maybe months.

132
00:22:40.010 --> 00:22:57.079
Ryan Dymek: many months, maybe even in some cases, years that are already built. And we could get this stuff online in a matter of minutes or hours or days, versus weeks, months, or years. Okay? And so that's a huge reason we use the cloud is to be able to leverage Amazon's

133
00:22:57.160 --> 00:22:59.210
Ryan Dymek: research and development here. Okay?

134
00:22:59.450 --> 00:23:26.389
Ryan Dymek: And so we're going to kind of hone in now for just a second I mentioned, I have some background in security. I'll talk about security pillar for just a second. Here, I'm not going to bore you on this. I mean, some of you are interested in security. Some of you aren't, but we all need to have some level of interest. And it's important. It's not just cliche. It's a very important thing. Security is everybody's responsibility. If you're a developer, you have the ability of making a very insecure insecure load on the in the code. If you're an architect. We can make insecure.

135
00:23:26.410 --> 00:23:49.909
Ryan Dymek: insecure designs on that front, right? Things like that. So so in that regard, we're all responsible for this. And I want you to understand. There's this concept of 0 trust. I'm not going to get into all the details of this, and I could teach 0 trust for a couple of hours if we needed to, to a security team. But here we're going to just give you the really high level highlights, almost of it. And the general idea here.

136
00:23:50.090 --> 00:24:02.659
Ryan Dymek: And it's not just that you don't trust anybody. In fact, this doesn't mean I don't trust people. Okay, we we should hope that for the most part we have employees in our company that we can trust right now.

137
00:24:02.710 --> 00:24:06.789
Ryan Dymek: You can't say you can do that blindly. Okay, but this isn't about

138
00:24:06.970 --> 00:24:16.979
Ryan Dymek: having no trust with people. But what we're saying is not from a human perspective, from an action perspective. Every single action that takes place

139
00:24:17.290 --> 00:24:19.659
Ryan Dymek: should be authenticated

140
00:24:20.020 --> 00:24:29.080
Ryan Dymek: and should be approved. Okay, so so here authorized is actually the official term for that. So so so here's the general concept.

141
00:24:29.450 --> 00:24:41.290
Ryan Dymek: Chances are if you work for a larger enterprise. But maybe not a lot of people have these these key cards or badges or something, right? And maybe you need that to even enter the building. And then maybe there's a lobby.

142
00:24:41.370 --> 00:24:57.400
Ryan Dymek: and then maybe you have to use that card to enter the elevator and to go to a specific floor, and then maybe you have to use that card to enter certain doors right? Well, every time that's happening you are reauthenticating. You're proving that you are who you say you are. Okay.

143
00:24:57.410 --> 00:25:01.469
Ryan Dymek: You're not just blindly walking around the building, you're able to say every time this is who I am.

144
00:25:01.580 --> 00:25:07.679
Ryan Dymek: And then, in the process of doing that, do I have permission to open this door? Do I have permission to go in this elevator?

145
00:25:07.740 --> 00:25:25.029
Ryan Dymek: Do I have permission to, you know. Go wherever right and 0 Trust would say, this has to happen on any and every action that takes place that you have to reauthenticate. There's not like a central login where I just log in, and I'm blindly allowed access to everything right. It's every time I do something.

146
00:25:25.270 --> 00:25:35.069
Ryan Dymek: There's authentication taking place, and then and then and then not only my authenticated, then I'm reevaluated of do I actually have permissions to do this exact thing that I'm trying to do.

147
00:25:35.190 --> 00:25:46.909
Ryan Dymek: That's what 0 trust is versus just letting everybody in the front door and say, Well, if you're in the front door, you're allowed. This is the problem actually is traditional. It does what I just described in the second half of that

148
00:25:47.010 --> 00:25:56.110
Ryan Dymek: traditional it. You tend to have classic firewalls. And once you're through the firewall, and you're on the other side. You're trusted. Meaning if you're on this like

149
00:25:56.750 --> 00:25:59.120
Ryan Dymek: trusted network inside.

150
00:25:59.240 --> 00:26:03.230
Ryan Dymek: you're just blindly trusted, do whatever you want to do inside of that network. And you're trusted.

151
00:26:03.360 --> 00:26:07.820
Ryan Dymek: 0 Trust doesn't do that. Well, Amazon is built with 0 trust in mind.

152
00:26:07.950 --> 00:26:10.769
Ryan Dymek: Unfortunately, I've seen a lot of customers.

153
00:26:11.680 --> 00:26:17.800
Ryan Dymek: Take a nice, really, really high quality, secure environment, using 0 trust

154
00:26:17.940 --> 00:26:23.000
Ryan Dymek: and degrade it at Amazon. In other words, they take this great starting point.

155
00:26:23.150 --> 00:26:49.499
Ryan Dymek: and they do away with 0 trust. And they start doing things in the old way. They start doing things with subnets and firewalls and managing things in that capacity which aws is actually not designed to be managed in that capacity. I mean, you can. But even then, even if we're dealing with traditional network designs. We can do things in a 0 trust way. And so the point is that I've actually seen, ironically enough, I've seen security teams

156
00:26:49.520 --> 00:26:54.710
Ryan Dymek: make Amazon less secure because they applied old ways of thinking

157
00:26:54.780 --> 00:27:02.199
Ryan Dymek: to this new environment. You can't take your knowledge. I've been doing this stuff for 25 plus years in the enterprise.

158
00:27:02.240 --> 00:27:12.589
Ryan Dymek: But stuff that I learned in that 1st decade, you know. A lot of it doesn't apply here, or is quite frankly the exact opposite the way we should be doing it in the cloud.

159
00:27:12.630 --> 00:27:17.559
Ryan Dymek: And this is why, actually, why training is so important? Because without that training

160
00:27:17.840 --> 00:27:24.950
Ryan Dymek: you can make things work the way you made them work on. Prem. You can make things work the way you've always made them work, and they will probably work.

161
00:27:25.290 --> 00:27:27.780
Ryan Dymek: They might be, they might be expensive.

162
00:27:27.920 --> 00:27:50.169
Ryan Dymek: and the administrative overhead might be absolutely astronomical, and in the process you may have actually degraded the security. So we need to know how to do this stuff well and correct and right, because if we don't, we're actually taking something that is really hardened and making it less secure. And again, the amount of times I've seen security teams in the interest of security, good intentions.

163
00:27:50.450 --> 00:28:07.099
Ryan Dymek: Actually, I've seen people actually degrade the security in the system. I actually see a raised hand. We're limited time, so we'll take a couple of questions. But go ahead, go ahead, raise hand, go for it. If you want to open your mind. I don't know if you can. If your mics are not locked.

164
00:28:07.420 --> 00:28:08.319
Ryan Dymek: Not sure

165
00:28:09.360 --> 00:28:16.460
Ryan Dymek: not sure. Maybe maybe it's only one way. Audio, I'm not sure it's a webinar. So normally the. So if you want to type a chat type, something in the chat that's probably the best way to do it.

166
00:28:16.650 --> 00:28:20.569
Ryan Dymek: I'm I'm kind of monitoring the chat, and if there's something you want to throw in there, go for it.

167
00:28:21.220 --> 00:28:22.739
Axcel ILT: Yeah, thanks. Thanks. Ryan.

168
00:28:23.120 --> 00:28:23.750
Ryan Dymek: Absolutely. Yeah.

169
00:28:23.750 --> 00:28:24.240
Axcel ILT: Big in chat.

170
00:28:24.240 --> 00:28:25.090
Ryan Dymek: Probably the best way to do it.

171
00:28:25.090 --> 00:28:25.800
Axcel ILT: Is it? Yeah.

172
00:28:25.800 --> 00:28:31.700
Ryan Dymek: Probably the best way with this many people. I mean, we've got a pretty good size, a group here, so I think opening the mics would probably not be a great idea, so.

173
00:28:31.700 --> 00:28:34.141
Axcel ILT: No, yeah. And we do.

174
00:28:34.630 --> 00:28:45.565
Ryan Dymek: Absolutely so go and drop it in the chat, and if it's something I can kind of slip into the mix of a conversation, I'd be glad to do so. All right. Awesome. So so yeah, 0 trust is something that

175
00:28:46.050 --> 00:28:47.076
Ryan Dymek: that we

176
00:28:47.650 --> 00:28:57.339
Ryan Dymek: we want to try and adhere to. But we have to fully understand it. And and that's and that's that's a kind of an important, you know, important piece to this. So just real quick.

177
00:28:57.440 --> 00:29:04.290
Ryan Dymek: I want to. I want to show you something about this when it comes to government standards actually on this front.

178
00:29:04.719 --> 00:29:08.319
Ryan Dymek: So there's actually a standard on 0 trust by the

179
00:29:08.330 --> 00:29:17.799
Ryan Dymek: NIST. If you're not familiar with the NIST, it's a government standards organization, and they have a standard defining 0 trust. And so there's something here

180
00:29:17.830 --> 00:29:19.449
Ryan Dymek: that's very interesting.

181
00:29:19.840 --> 00:29:47.520
Ryan Dymek: This is just an abstract summary. If you want to actually go look at the full documentation of this. Of course you could. Let's go and drop this in the chat real quick. All right. So yeah, absolutely, Inger. Yeah, I'm going to go ahead and give you some of these links. Absolutely. So. This is a good one right here. So I'll start with this one, and I'll kind of also go back. And if there's anything else. In fact, while I'm at it, let me go ahead and give you the well architected link here. I'm just gonna throw that one in the chat as well while I'm thinking about it.

182
00:29:47.670 --> 00:30:00.630
Ryan Dymek: That's in there, and of course you can go from there. You can go to any of the any of the pillars you want to go dive into. Okay? All right. So the 0 trust. This is just a summary. I'm not going to read this whole thing. Of course you can read this for yourself. The link is in the chat.

183
00:30:00.700 --> 00:30:27.000
Ryan Dymek: but I want to. I want to talk about some of this stuff. 0 trust is a response to enterprise network trends that include remote users. Right? So the thing is, people have been distributed. People have stopped coming in the office very commonly or not coming in the office as often. So network location or actually geographic location may not be as the same as it once was. But look at this right here. There's an interesting statement here. 0 trust focuses on protecting the resources. Okay?

184
00:30:27.410 --> 00:30:28.950
Ryan Dymek: Oh, they're not coming through the chat.

185
00:30:29.393 --> 00:30:32.396
Ryan Dymek: Okay, I'm not sure I can get those out.

186
00:30:33.810 --> 00:30:49.369
Ryan Dymek: but yeah, we'll see what we can do, all right. So so if you can't, you can just do a search for NIST 0 trust. And this should come up. Okay. Also, if you do a search for aws well architected, it'll be one of the 1st search results that you'll you'll come up with. Okay.

187
00:30:49.660 --> 00:31:02.009
Ryan Dymek: so 0 Trust is focusing on protecting the resources. So this will be actually like protecting the data itself as an example, saying, If you want access to this data, you have to meet all these conditions.

188
00:31:02.040 --> 00:31:16.809
Ryan Dymek: and if you don't meet these conditions, you don't have access to it. I'm not going to necessarily care so much about what network address you're coming from, what subnet you're coming from. That's not a trusted. I don't want a trusted network. Okay? In fact.

189
00:31:16.840 --> 00:31:33.309
Ryan Dymek: statistically, 60% over 60% of attacks come from the inside. Now, some people mistakenly think that means that my employees are the attack source. Sometimes they could be, but by coming from the inside we mean that they were. They were trusted somehow.

190
00:31:33.410 --> 00:31:34.640
Ryan Dymek: So if I

191
00:31:34.700 --> 00:31:37.939
Ryan Dymek: break an application. And I end up on the trusted network.

192
00:31:37.960 --> 00:31:44.839
Ryan Dymek: That's the problem we're trying to avoid. Right? We want to make sure that even if you break that application that you're not somehow landing on some trusted network.

193
00:31:44.940 --> 00:31:48.939
Ryan Dymek: Okay, there's no such thing as a trusted network in a 0 trust environment.

194
00:31:49.261 --> 00:31:55.469
Ryan Dymek: Oh, cool! It looks like, looks like my teammates have actually been posting the links there in the chat hopefully. That helps. Maybe that'll work for you.

195
00:31:56.185 --> 00:32:00.910
Ryan Dymek: So so look at this, though, okay, 0 trust focuses on protecting the resources.

196
00:32:01.110 --> 00:32:04.500
Ryan Dymek: Okay, not network segments.

197
00:32:04.740 --> 00:32:15.659
Ryan Dymek: The network segment is no longer the prime component of security in in 0 trust. So aws is a 0 trust environment. By the way, aws is not the only one. But

198
00:32:15.810 --> 00:32:36.090
Ryan Dymek: we're talking aws, this is how we want to design things. Okay, so I'm going to kind of leave this alone. This isn't a security class. I just want to touch on this that, hey? You know, the way we approach these problems is very different than the way we used to do it on premises. And if we take the old way of doing it. We will directly cause security risks in the cloud if we're not careful. Okay.

199
00:32:36.418 --> 00:32:44.959
Ryan Dymek: I know the amount of teams I've encountered as a consultant where I've seen this firsthand, where the team is in the interest of security, trying to do what they think is right.

200
00:32:44.980 --> 00:32:51.150
Ryan Dymek: But they haven't had the necessary training. And and so and so that, of course, everything kind of falls apart, right?

201
00:32:51.180 --> 00:32:59.090
Ryan Dymek: And their way of thinking needs to change. Okay, and so this is really, really an important thing. And this kind of carries through not just with security.

202
00:32:59.190 --> 00:33:03.149
Ryan Dymek: Our way of thinking has to change across the board on all of these pillars.

203
00:33:03.240 --> 00:33:07.329
Ryan Dymek: Okay, security just being one of those pillars. All right.

204
00:33:07.530 --> 00:33:15.994
Ryan Dymek: So I'll move on. But yeah, this is this is an important pillar to kind of address there, right? And then we've got

205
00:33:16.730 --> 00:33:20.719
Ryan Dymek: principle of least access. This kind of goes along with 0 trust.

206
00:33:21.104 --> 00:33:27.479
Ryan Dymek: Principal access, basically just means when I grant access. I only grant what I need and nothing more.

207
00:33:27.780 --> 00:33:44.200
Ryan Dymek: Okay. And we do that through policies and roles and things like that in aws. Now, I've pulled up a couple of policy examples. I'll show you just kind of what these might look like. But I want you to understand that by default nothing has access to anything in Aws because of 0 trust.

208
00:33:44.250 --> 00:33:51.140
Ryan Dymek: No service in Amazon has access to another service. No service has access to any resource in your account.

209
00:33:51.330 --> 00:33:56.079
Ryan Dymek: So just because you're having service, A talking to service B in aws.

210
00:33:56.120 --> 00:33:59.879
Ryan Dymek: it doesn't mean they can talk just because they're both aws means nothing.

211
00:34:00.210 --> 00:34:08.320
Ryan Dymek: If if service A is not trusted is not, you don't have a policy set up to grant service, a. The ability to talk to service. B, they cannot.

212
00:34:08.500 --> 00:34:18.610
Ryan Dymek: Okay, there is no default. Open access to anything in aws, it is completely locked down. And then you specifically say what you need to open up.

213
00:34:18.920 --> 00:34:32.509
Ryan Dymek: And so the way you open that up is through policies. So policies are more of a an allow scenario versus a deny scenario. You can do denies and strategic advanced things. But mostly it's an allow concept. Only allow what you need and nothing more.

214
00:34:33.139 --> 00:34:46.019
Ryan Dymek: Okay, and so I'll kind of share with you. Consider some of these examples, and then we'll move on to some other topics. But one thing I want to point out is I mentioned how in the key card example, you might swipe that key card at every door.

215
00:34:46.060 --> 00:34:51.170
Ryan Dymek: Okay, just as an example. Okay. And to get into that door. You got to reprove who you are. Okay?

216
00:34:51.389 --> 00:34:59.040
Ryan Dymek: Well, this is happening in Aws as well. Again, because of 0 trust. We have to authenticate every single action every single time.

217
00:34:59.110 --> 00:35:25.940
Ryan Dymek: So there are completely dynamic credentials. These are in the forms of keys Api management keys that take place, and these keys are generated and cycled through very aggressively by default. When I do what we call assume a role in aws, we'll get into that in our architecture class. But when I do this action, I have to kind of think of it as like a persona like you kind of become this role. And that's what has the permissions.

218
00:35:25.960 --> 00:35:29.939
Ryan Dymek: So I say you, I don't mean the human being. The service

219
00:35:29.950 --> 00:35:42.329
Ryan Dymek: takes on that role, and that's what gives that service the access or the permissions that it needs. Well, in the process of doing that credentials are actually generated, and those credentials by default last no more than an hour.

220
00:35:42.700 --> 00:35:45.669
Ryan Dymek: These credentials could be shortened down to 15 min, they could.

221
00:35:45.690 --> 00:35:52.250
Ryan Dymek: under situations could be all the way up to 36 h, and you can define this. But the point is, those credentials are generated.

222
00:35:52.590 --> 00:36:01.130
Ryan Dymek: and then every single Api request actually has a fresh signature on every single request. Those credentials are not used

223
00:36:01.220 --> 00:36:08.380
Ryan Dymek: by themselves. Those credentials are used as part of an algorithm to actually generate a unique signature.

224
00:36:08.710 --> 00:36:14.700
Ryan Dymek: Every single action we do, every single Api call we do

225
00:36:14.740 --> 00:36:16.719
Ryan Dymek: has a unique signature to it.

226
00:36:17.130 --> 00:36:29.570
Ryan Dymek: Okay, very different than just trusting a network. Okay, we're proving that we are, you know who we say we are when it comes to that, whether that's a service, whether that's an application, whether that's a person at all times

227
00:36:29.710 --> 00:36:32.699
Ryan Dymek: you have to reprove that every single action.

228
00:36:33.060 --> 00:36:39.350
Ryan Dymek: And then, of course, that's all logged and and monitored, and you know all of that right. We have a full observability around all of that.

229
00:36:39.670 --> 00:36:55.620
Ryan Dymek: And and so let me just kind of briefly show you some examples of IM policies here that I've pulled up. So Amazon's got a nice policy example list here for anybody that's interested in kind of understanding these a little bit more that I put the link in the chat. Maybe I can get republished there.

230
00:36:56.763 --> 00:36:57.416
Ryan Dymek: But

231
00:36:58.652 --> 00:37:01.549
Ryan Dymek: this oops. Sorry one second. Okay.

232
00:37:02.068 --> 00:37:16.360
Ryan Dymek: so these are some examples. Let me just kind of show you allow access during a specific range of dates. Okay? So there's this policy here that says, Hey, there's this particular service, and it's only allowed access during this timeframe.

233
00:37:16.570 --> 00:37:20.030
Ryan Dymek: So here's here's a scenario. I want us just to kind of be aware of.

234
00:37:20.592 --> 00:37:33.619
Ryan Dymek: I can actually make policies in Amazon that says you can do this one action during this 1 1 h window of time. If I want. Okay? And if it's outside of that hour, it's access denied.

235
00:37:33.890 --> 00:37:44.170
Ryan Dymek: Alright, I can have policies that not. And that policy may not just be blind access. It might be like, I can do this one request against this one piece of information for this 1 h.

236
00:37:44.390 --> 00:37:57.750
Ryan Dymek: Okay, aside from credentials, right credentials are going to be expiring after an hour at most. But again, also, those credentials are used to generate that signature, and then from a permissions perspective. Those permissions can be very dynamic

237
00:37:57.770 --> 00:38:00.599
Ryan Dymek: and and have very short windows of time. Perhaps.

238
00:38:00.948 --> 00:38:08.710
Ryan Dymek: So there's just there's a bunch of different policies in here now you'll be taught, you know, if you don't, if you don't know what Dynamodb is. This is

239
00:38:08.920 --> 00:38:17.460
Ryan Dymek: talked about in the architecting class. But Dynamodb is a no SQL. Database. If that's if you know nothing more than that. That's fine. Okay, it's it's a database.

240
00:38:17.570 --> 00:38:21.809
Ryan Dymek: No, SQL, we're not going to get into all that. But there's a policy here.

241
00:38:22.050 --> 00:38:30.300
Ryan Dymek: And let's just take a quick look at this policy. Briefly, we're saying, Hey, we're going to allow these actions and these actions are specifically the ability to list stuff

242
00:38:30.530 --> 00:38:44.380
Ryan Dymek: and then describe commands or read only metadata kind of commands. Okay? And so we can do all those, and then we might also say, You know what we can only do these actions against this specific table.

243
00:38:44.400 --> 00:38:47.370
Ryan Dymek: So I might say, I have this, no SQL. Table

244
00:38:47.580 --> 00:38:57.389
Ryan Dymek: and I can do batch, get operations. I can do these actions right. So I might have a service that needs to be able to do these things. But again, it's allow specific. Without this, allow these things can't happen.

245
00:38:57.540 --> 00:39:03.169
Ryan Dymek: Okay, so this is kind of the syntax. It's it's a as you notice, though, it's more like code, right? It's more like

246
00:39:03.270 --> 00:39:31.190
Ryan Dymek: it's like a level of programming to some degree. And so there is a there's a level of understanding that we actually can run these through things like devops, pipelines. Ci, CD, pipelines version control all of those things around these permissions. And this is this is what a permission looks like in aws. Okay, we get into this a little bit in the architecting class, and kind of you would know how to read these at the very least, how to really understand these and how to leverage various conditions and

247
00:39:31.190 --> 00:39:44.450
Ryan Dymek: and other things around that. Okay, there is a separate security engineering course that goes into much greater depth on this, though right for aws. But at least in the architecture class, you're going to go high level on this. Okay?

248
00:39:45.345 --> 00:39:55.479
Ryan Dymek: Okay. So so that's that's that's kind of the main thing there, all right. Oh, is terraform supported absolutely 100%. Yes, aws fully supports terraform.

249
00:39:55.610 --> 00:40:01.890
Ryan Dymek: Yeah. And for those of you that aren't familiar with terraform, that's discussion for another day. Okay? But yes, 100%.

250
00:40:02.300 --> 00:40:14.889
Ryan Dymek: So a couple of things I want to also talk about, though, is there's this kind of new breed of tools. I say new breed, I mean in Amazon. These have actually been around in some cases for a very long time. But it's a new breed in the sense that a lot of people

251
00:40:14.960 --> 00:40:20.429
Ryan Dymek: are just finding out about these things, or maybe they're just new to aws. And so they don't know about these things.

252
00:40:20.450 --> 00:40:44.409
Ryan Dymek: These are all tools that actually leverage machine learning. They use. AI, you know, AI has kind of been the topic of conversation for a lot of people, a lot of places for the last year or 2. It's really come on the scene. That's a different kind of AI, okay. The stuff that everybody's talking about is what we call generative. AI right? Generative. AI means it's generating content. Right? It's creating it's creating stuff. New works.

253
00:40:44.440 --> 00:40:56.490
Ryan Dymek: This AI has actually been around for quite some time is really intelligent. But it's more about things like, Hey, let's identify anomalies. Let's look at something that's not normal. So what if the system can learn what normal is in your environment?

254
00:40:56.930 --> 00:41:06.579
Ryan Dymek: It learns, okay, every Monday morning. There's this, this spike that happens in this capacity. And that's normal, right? But there's various things that are normal. But then what about things that aren't normal?

255
00:41:06.880 --> 00:41:14.329
Ryan Dymek: Okay? So there's anomaly detection across the board. There's a whole bunch of services that support anomaly detection throughout. Aws.

256
00:41:14.970 --> 00:41:17.136
Ryan Dymek: again, the beauty here is

257
00:41:18.010 --> 00:41:24.170
Ryan Dymek: we don't have to codify these things right? This is stuff where it's like, you want anomaly detection. Just turn it on.

258
00:41:24.830 --> 00:41:35.350
Ryan Dymek: Okay. Now, in some of those cases there are fees for these things you have to be willing to pay for, but the beauty is you don't have to do the R. And D for it. You don't have to go set this up. You don't have to install anything. There's no licensing.

259
00:41:35.470 --> 00:41:37.480
Ryan Dymek: It's usually paid for usage.

260
00:41:37.580 --> 00:41:44.120
Ryan Dymek: Okay, so a smaller environment pays less. A bigger environment pays more. You know. Depending how it's being used. Right?

261
00:41:44.150 --> 00:42:07.279
Ryan Dymek: Amazon guard duty actually analyzes your logs. It actually looks at Dns, lookup logs, look at network logs, it looks at Api logs, looks at them all together to paint a picture, and it will alert you of anomalies and things that are going on in your environment, or or things that look like a specific type of attack, it'll let you know. So the thing is no longer am I looking at purely things like

262
00:42:07.280 --> 00:42:29.880
Ryan Dymek: network devices to look for network packets and attacks at the network level? Right? We're actually looking at things from a much more intelligent perspective than that. Attackers today aren't manipulating IP packets like they once were. Now, it's much more strategic attacks around leveraging services and being smarter about it to make it look more like a human being or this or that right?

263
00:42:29.930 --> 00:42:35.109
Ryan Dymek: So, finding those things we have to. We have to kind of match what the attackers are doing with more intelligent software. Okay?

264
00:42:35.340 --> 00:42:58.719
Ryan Dymek: Amazon, Macy, this one's really cool. I've got a customer that has a really neat story. I'm going to tell you briefly on this. I'll try and summarize it. But this product right here will actually 1st off, it'll scan your data and look for sensitive information. Let's say you wanted to find social security numbers, credit card numbers, things like that throughout your data. And you want to find it in any places that maybe you didn't know it existed. Right?

265
00:42:58.730 --> 00:43:15.569
Ryan Dymek: Most basic simplistic example. What if I had a document that said my social security number is. And then there's a number. But it doesn't have any dashes. It wouldn't have matched any kind of pattern recognition. We need smarts to understand the context to know that that is a social security number.

266
00:43:15.620 --> 00:43:30.359
Ryan Dymek: And so you need machine learning tools. That'll do that. And so Macy will actually look for that. A second thing that Macy will actually do is is a look at human behavior. This is a really cool one. So a customer of mine, a couple years back

267
00:43:30.490 --> 00:43:34.750
Ryan Dymek: they had a salesperson that had access to a lot of customer data

268
00:43:34.950 --> 00:43:37.319
Ryan Dymek: completely legitimate access.

269
00:43:37.480 --> 00:43:45.489
Ryan Dymek: totally within the security scope of what this person should be doing so. They had. They. They had legitimate access. They didn't have to do anything special.

270
00:43:45.950 --> 00:43:47.710
Ryan Dymek: But suddenly one day

271
00:43:47.890 --> 00:43:49.480
Ryan Dymek: this one person

272
00:43:49.820 --> 00:43:52.559
Ryan Dymek: was downloading a whole bunch of customer data

273
00:43:52.690 --> 00:43:57.589
Ryan Dymek: like unusually in a in a, in a unique, unusual, anomalous way.

274
00:43:57.710 --> 00:44:00.149
Ryan Dymek: Okay, completely within the permissions.

275
00:44:01.080 --> 00:44:06.420
Ryan Dymek: Long story short, this person was actually downloading all the customer data from the company.

276
00:44:06.430 --> 00:44:11.210
Ryan Dymek: They had accepted a position with another company, and they were stealing customer data to take over there

277
00:44:12.270 --> 00:44:16.110
Ryan Dymek: this customer that was using Macy identified it in real time.

278
00:44:16.470 --> 00:44:22.750
Ryan Dymek: Like as this stuff was happening like, what's going on? Why is this person just suddenly sucking down a bunch of information

279
00:44:22.760 --> 00:44:28.880
Ryan Dymek: from our our data sources, and and although they have permissions to it, this is unusual.

280
00:44:29.520 --> 00:44:31.130
Ryan Dymek: Macy caught it. Alerted.

281
00:44:31.810 --> 00:44:57.039
Ryan Dymek: Detective is a great tool for like investigating root cause or even potential vulnerabilities in your environment, it'll detect it's kind of like a an investigator, right? It's kind of going out and investigating things in your environment again, using full artificial intelligence, machine learning sense here to find these things in your environment, because these are much harder, sometimes much harder to find in the cloud than they were than they were. A different era. Right?

282
00:44:57.288 --> 00:45:07.729
Ryan Dymek: It used to be. I could just make sure my routes were safe. My firewalls were safe, and that was kind of the bulk of our focus. Very different world. Now, a lot of this stuff doesn't even deal with networks. Okay.

283
00:45:08.699 --> 00:45:14.679
Ryan Dymek: even down to the code level, there's actually a product that will analyze your code for vulnerabilities in your code.

284
00:45:15.200 --> 00:45:36.630
Ryan Dymek: Okay, making sure that proper validation is happening, that you're not vulnerable to things like injections and SQL. Injections and different types of attacks like that. Right? So there's these tools that will govern your environment in a totally new and different way than we're used to. We're not going to just use firewalls and intrusion prevention systems like we once did at the network level.

285
00:45:36.640 --> 00:45:48.649
Ryan Dymek: we're way past that. We're way more advanced than just analyzing network packets. Okay? And the network access analyzer is more about reachability, like like what has access to what in our network

286
00:45:48.960 --> 00:45:52.460
Ryan Dymek: and what shouldn't have access to certain things? It does right?

287
00:45:53.140 --> 00:46:03.989
Ryan Dymek: So then we're going to kind of totally shift gears. Okay, going into cost. So cost. So we talked about operational. We talked about security. I want to briefly talk about cost. We've got about 14 min. It looks like

288
00:46:04.248 --> 00:46:11.140
Ryan Dymek: so cost is cost is an interesting one. What I'm going to do is do a little exercise with us here. This is going to be kind of a fun little exercise.

289
00:46:11.889 --> 00:46:22.020
Ryan Dymek: So I've got 2 operational scenarios that I am presenting here, and I want us to kind of work through what those costs might look like.

290
00:46:22.320 --> 00:46:34.520
Ryan Dymek: Okay? And again, in the architecting classes, you kind of learn how to do this yourself. Okay? And I'm going to kind of simplify it. So don't think it's always as simple as I'm presenting here. This is just a very unique scenario. I wanted to present.

291
00:46:34.640 --> 00:46:48.050
Ryan Dymek: Well, in this scenario we have one case that's like a fairly high rate of rights coming in. So you have this data. Maybe this is data being generated from logs or sensors. IoT devices, you know, whatever the situation. Maybe you have mobile apps.

292
00:46:48.140 --> 00:46:50.450
Ryan Dymek: But I've got these 300, writes per second.

293
00:46:50.850 --> 00:46:58.779
Ryan Dymek: Okay? And maybe this is on average. So it's a continual 300 writes per second every second, every minute, every hour every day. Okay.

294
00:46:59.030 --> 00:47:09.519
Ryan Dymek: nonstop. All right. And so these writes are coming in there. This is on average. So maybe some moments there's less, some moments, there's more. But on average we've discovered. It's about 300, writes per second.

295
00:47:09.660 --> 00:47:22.110
Ryan Dymek: Each right is only about a K, okay, fairly small blocks of information here. But it's a fairly high rate. Okay. Now, I say, fairly high. I mean, there's things I can do in aws that are little, literally, millions of writes per second.

296
00:47:22.400 --> 00:47:31.670
Ryan Dymek: Okay, so this isn't high when it comes to aws. There's capabilities of me doing amazing things here. But still 300 writes per second is nothing to laugh at.

297
00:47:32.220 --> 00:47:40.160
Ryan Dymek: So I have these one K rights coming in. We have a total of about 77 million rights per month. Okay.

298
00:47:40.980 --> 00:47:50.459
Ryan Dymek: total amount of data that we're dealing with here is about 777 gigs. Because if you look at this one K, it's just it's just take this number

299
00:47:50.500 --> 00:47:55.280
Ryan Dymek: and add one K to it, or multiply it by one K. And you end up with the same number just

300
00:47:55.330 --> 00:47:59.400
Ryan Dymek: a couple extra zeros. Right? So we have 777 gigs

301
00:47:59.430 --> 00:48:10.609
Ryan Dymek: per month, being ingested through this model. All right. And I want to point out this other scenario that we've got here is actually the same amount of data. My point is, the actual amount of data we have to store is the same.

302
00:48:10.990 --> 00:48:22.680
Ryan Dymek: The thing that changes between these 2 is the rate and the size of the writes. So I want to highlight that. So the only thing that's different between these is up here. You see, this is only 3 writes per second. But the rights are bigger.

303
00:48:23.120 --> 00:48:25.370
Ryan Dymek: Okay, so smaller rights.

304
00:48:25.490 --> 00:48:28.189
Ryan Dymek: smaller rights, many more of them

305
00:48:28.600 --> 00:48:33.679
Ryan Dymek: bigger, writes fewer of them. Okay, same total aggregate data.

306
00:48:34.340 --> 00:48:44.269
Ryan Dymek: So what should we choose here? Should we use S. 3 to ingest this data, or should we use Dynamodb? Now, there's other ways. I mean there's plenty of other. There's like

307
00:48:44.370 --> 00:48:49.960
Ryan Dymek: there's like 10 different places. I could probably think of right now off top of my head where I could send this data. Okay?

308
00:48:50.210 --> 00:48:56.500
Ryan Dymek: But point is, I want to. I want to receive this data. And I want to store it for long-term use. Okay, in some capacity.

309
00:48:56.920 --> 00:49:16.239
Ryan Dymek: And that could be either. One of these. These are not, by the way, s. 3 is not a database, but it has the capability of of being queried, and being used like a database, s. 3 is labeled as a excuse me, I'm sorry. Dynamodb is, however, labeled as a database, but it can also just be used to store and query data. Okay, I mean, these are both under a heading of what I like to call data store.

310
00:49:16.510 --> 00:49:21.460
Ryan Dymek: whether it's storage, whether it's a database. Databases are just a fancy way to store and retrieve data.

311
00:49:21.510 --> 00:49:26.339
Ryan Dymek: right? Databases are still just storage as well. Okay. So they're both storage solutions.

312
00:49:26.580 --> 00:49:52.859
Ryan Dymek: So the question is which one makes the most sense? Well, we're going to compare these 2 scenarios and kind of show you the nuanced differences between these. And so we're going to just pull up the pricing calculator in aws, just to kind of show you the effect of this. Okay, so there's this calculator in Aws, I'm going to give you a link to this as well. But again, if you just did a simple Google search of Aws pricing calculator, you would come up with this, probably pretty quickly in your search.

313
00:49:52.990 --> 00:49:54.769
Ryan Dymek: So I'm going to create an estimate here.

314
00:49:55.120 --> 00:50:03.470
Ryan Dymek: Okay, so what we're gonna do is we're gonna first, st we're gonna do the 1st scenario, right? And the 1st scenario was 300, writes per second

315
00:50:03.500 --> 00:50:08.140
Ryan Dymek: with one K rights. All right. So we're going to pull up as 3.

316
00:50:08.230 --> 00:50:13.119
Ryan Dymek: I'm just going to do the most basic situation here. Now.

317
00:50:13.320 --> 00:50:22.329
Ryan Dymek: if I choose some of these other options, it would actually get more expensive than what I'm about to show you. Okay, so 300 rights a second, I want to point out, S. 3 is capable of much more than this.

318
00:50:22.390 --> 00:50:23.970
Ryan Dymek: Technically speaking.

319
00:50:24.345 --> 00:50:29.719
Ryan Dymek: s. 3 has this capability of what we call partitions, and we give you multiple partitions.

320
00:50:29.830 --> 00:50:31.750
Ryan Dymek: But a single partition

321
00:50:32.110 --> 00:50:40.579
Ryan Dymek: can handle 3,500 writes per second. Okay, so 300 writes per second is really nothing for S. 3 s. 3 can handle this just fine.

322
00:50:41.850 --> 00:50:48.100
Ryan Dymek: So we're going to say, you know what we are doing? 300 writes per second. That is a total

323
00:50:48.240 --> 00:50:52.299
Ryan Dymek: in the whole month. It's a total of 77

324
00:50:53.090 --> 00:50:58.490
Ryan Dymek: 1 million, right? 77777600000. Okay.

325
00:50:58.770 --> 00:51:03.150
Ryan Dymek: so just the operations to write this data to S, 3

326
00:51:03.750 --> 00:51:07.770
Ryan Dymek: is $3,888 a month.

327
00:51:08.310 --> 00:51:12.719
Ryan Dymek: And this is just the sheer cost of writing it to S, 3.

328
00:51:12.760 --> 00:51:18.980
Ryan Dymek: Okay, so this is a right cost. Basically, it's it's a it's an operations charge.

329
00:51:19.270 --> 00:51:20.000
Ryan Dymek: Okay.

330
00:51:20.460 --> 00:51:22.719
Ryan Dymek: I haven't even paid for the storage yet.

331
00:51:22.750 --> 00:51:29.969
Ryan Dymek: But here's what's kind of crazy. If I put the storage amount in here, which is 777 gigs, doesn't look like the price changed a whole lot.

332
00:51:30.070 --> 00:51:32.200
Ryan Dymek: Well, let's look at the calculations for this.

333
00:51:33.460 --> 00:51:38.060
Ryan Dymek: Look at this. The actual storage costs for 777 gigs here

334
00:51:38.350 --> 00:51:40.689
Ryan Dymek: is just under $18.

335
00:51:41.510 --> 00:51:43.640
Ryan Dymek: So I'm gonna pay $18 a month

336
00:51:44.380 --> 00:51:48.260
Ryan Dymek: to work with to work $18 a month to store this data.

337
00:51:48.530 --> 00:51:52.699
Ryan Dymek: But for $18 a month worth of data, I'm gonna charge. I'm gonna pay

338
00:51:53.090 --> 00:51:55.440
Ryan Dymek: under 4, just under $4,000

339
00:51:55.480 --> 00:51:58.049
Ryan Dymek: to operate $18 of data.

340
00:51:58.240 --> 00:52:00.689
Ryan Dymek: That sounds kind of off, doesn't it?

341
00:52:00.980 --> 00:52:04.440
Ryan Dymek: Doesn't seem like it's a very good solution. So I've had customers that say, Ryan.

342
00:52:04.520 --> 00:52:05.759
Ryan Dymek: s. 3 is expensive.

343
00:52:07.760 --> 00:52:09.910
Ryan Dymek: or I've had other customers that say, s. 3 is cheap.

344
00:52:10.120 --> 00:52:13.439
Ryan Dymek: they say, Hey, Ryan? S. 3 is cheap. And so they just use S. 3 for everything

345
00:52:13.560 --> 00:52:16.279
Ryan Dymek: you can see here. Architecturally, this is a bad choice.

346
00:52:16.310 --> 00:52:20.389
Ryan Dymek: right? I hope this is pretty obvious that if I'm paying this kind of money.

347
00:52:20.420 --> 00:52:31.149
Ryan Dymek: it's only $18 worth of storage. But I'm paying almost $4,000 to operate it. There's something that doesn't work right there. Okay, so let's let's let's actually switch gears and do this with dynamodb instead.

348
00:52:31.470 --> 00:52:32.170
Ryan Dymek: Okay.

349
00:52:32.640 --> 00:52:34.959
Ryan Dymek: and let's use dynamodb to ingest this data.

350
00:52:35.390 --> 00:52:43.289
Ryan Dymek: And so there's different ways. I could set up Dynamodb, because we're just kind of doing a constant stream here. I'm just going to use what we call provision capacity.

351
00:52:43.620 --> 00:52:45.919
Ryan Dymek: Now, there's actually another way called on demand.

352
00:52:46.170 --> 00:52:50.779
Ryan Dymek: I'm going to actually, briefly show you this here in a minute, because on demand is going to be more expensive, ironically enough.

353
00:52:50.960 --> 00:52:55.830
Ryan Dymek: And this is also an important thing. I've had. People tell me that on demand is always cheaper. No, it's not.

354
00:52:56.050 --> 00:52:59.040
Ryan Dymek: You have to know the situation. Okay?

355
00:52:59.120 --> 00:53:07.216
Ryan Dymek: So it's all about architecting. Okay? So what I'm gonna do is I'm gonna come down here and I'm going to say that we have

356
00:53:08.444 --> 00:53:14.359
Ryan Dymek: rights. Okay, so these rights coming in, are 300 rights per second, right?

357
00:53:15.154 --> 00:53:26.010
Ryan Dymek: And it's not gonna worry, even worry about peaks. So we're just going to do a consistent. Just make the numbers easy. I'm not going to worry about any kind of peak or burst, or any of that kind of stuff.

358
00:53:26.140 --> 00:53:30.300
Ryan Dymek: Okay? And we're not doing any kind of reserved capacity which we could talk about another time.

359
00:53:30.530 --> 00:53:37.391
Ryan Dymek: Okay, and so and then the data storage size. We're dealing with a total of

360
00:53:37.830 --> 00:53:40.609
Ryan Dymek: 777 gigs.

361
00:53:40.620 --> 00:53:45.120
Ryan Dymek: Okay? Worth of storage. So you see here, just the storage.

362
00:53:45.530 --> 00:53:52.389
Ryan Dymek: The storage is actually a lot more expensive than S. 3 was. Remember how s. 3. The storage was $18 or a little less.

363
00:53:52.590 --> 00:54:04.299
Ryan Dymek: Here. The storage is going to cost me under $200. So it's actually quite a bit more on the storage cost. In fact, Dynamodb Storage is about 10 times. It's actually a little bit more than 10 times the cost of S. 3.

364
00:54:04.940 --> 00:54:05.720
Ryan Dymek: Okay?

365
00:54:05.960 --> 00:54:13.199
Ryan Dymek: And so wait a second. This. This is an interesting thing, right? But my operations of all of this

366
00:54:13.700 --> 00:54:24.699
Ryan Dymek: are substantially cheaper. Actually, in fact, this shows you all the math that took place. I'm not going to walk through it all, but we look down here, my total monthly cost is $339.

367
00:54:25.130 --> 00:54:26.889
Ryan Dymek: So even though the storage

368
00:54:27.180 --> 00:54:30.019
Ryan Dymek: is 10 times more than that of S. 3.

369
00:54:30.110 --> 00:54:31.819
Ryan Dymek: The operations are cheaper.

370
00:54:32.720 --> 00:54:37.080
Ryan Dymek: I'm doing the same number of operations, the same amount of data, the same amount of everything.

371
00:54:37.260 --> 00:54:41.560
Ryan Dymek: But instead of it being almost $4,000. It's $339.

372
00:54:42.540 --> 00:55:02.819
Ryan Dymek: So this is architecture. Okay, this is why architecture is so crucial for us to understand how to figure these things out because I can make it expensive. I can make it less. I can make it substantially less expensive now. By the way, that's scenario one. Now we've got about 5 min here. I think I can get in through scenario 2 for us. Here, let's just take a quick look at scenario 2,

373
00:55:02.820 --> 00:55:13.180
Ryan Dymek: we'll go back to S. 3. Okay. But in this case I want to remind you what scenario 2 consisted of without switching back and forth on my slides. Scenario 2 was only 3, writes per second.

374
00:55:13.420 --> 00:55:14.612
Ryan Dymek: and it was

375
00:55:15.290 --> 00:55:23.770
Ryan Dymek: 100 k. Rights. Okay, so bigger rights, fewer of them. Still, still a constant clip, though it's still 3, writes a second forever.

376
00:55:25.280 --> 00:55:35.429
Ryan Dymek: But what we're gonna do is come in. Come in here, and we're gonna take a look at that now. The actual storage here. Okay, so we're gonna do a total of

377
00:55:35.910 --> 00:55:42.300
Ryan Dymek: Now, it's it's fewer writes, okay. So instead of 300, writes a second. It's 3, writes a second, which comes out to be

378
00:55:42.330 --> 00:55:45.550
Ryan Dymek: 7,000,776

379
00:55:45.680 --> 00:55:47.659
Ryan Dymek: 1,000 rights per month.

380
00:55:47.780 --> 00:55:48.680
Ryan Dymek: Okay?

381
00:55:49.180 --> 00:55:49.865
Ryan Dymek: And

382
00:55:50.970 --> 00:55:54.040
Ryan Dymek: And and this is where I'm not. Gonna get into all these other things.

383
00:55:54.230 --> 00:55:57.780
Ryan Dymek: The put operations for this are $38.

384
00:55:59.250 --> 00:56:00.160
Ryan Dymek: Okay.

385
00:56:01.460 --> 00:56:12.790
Ryan Dymek: And and then let's talk about the actual storage, though we're still talking the same amount of storage as we did before. Right? So it's 777 gigs. So that's the other $18. Okay? So if I break this down.

386
00:56:13.090 --> 00:56:18.619
Ryan Dymek: I've got $18 for my storage, and I've got $38 for my operations.

387
00:56:20.240 --> 00:56:23.550
Ryan Dymek: same amount of data. But the operations changed.

388
00:56:23.920 --> 00:56:27.010
Ryan Dymek: That mechanism. That thing that we want to look at

389
00:56:27.180 --> 00:56:35.059
Ryan Dymek: is very different, right? So the workload is substantially different. As an architect. I need to look at this and go. What kind of workload are we dealing with?

390
00:56:35.340 --> 00:56:42.370
Ryan Dymek: Are we dealing with a fairly high rate of rights, or are we dealing with fairly low rate of rights? And I want to point out 3, writes a second

391
00:56:42.860 --> 00:56:44.700
Ryan Dymek: is cheap in s. 3,

392
00:56:45.170 --> 00:56:46.610
Ryan Dymek: 3, writes a second.

393
00:56:46.870 --> 00:56:48.339
Ryan Dymek: it's fairly cheap in s. 3

394
00:56:48.833 --> 00:56:53.070
Ryan Dymek: but 300, writes a second, is a very different ballgame, right?

395
00:56:53.380 --> 00:56:56.440
Ryan Dymek: And so we'll wrap this up. We have about 3 min.

396
00:56:56.620 --> 00:57:05.860
Ryan Dymek: I want to actually do one more, and I'm going to show you the same scenario once again for scenario 2 with Dynamodb, and then we'll be done. Okay. So, Dynamodb.

397
00:57:05.910 --> 00:57:09.880
Ryan Dymek: let's just see if we can do this here quickly. Provision capacity.

398
00:57:10.010 --> 00:57:18.639
Ryan Dymek: Okay, again, we're not going to worry about all these little details. You can learn these things in classes later. Another time. Storage size, 777 gigs.

399
00:57:18.690 --> 00:57:20.210
Ryan Dymek: Okay. Worth of storage

400
00:57:20.500 --> 00:57:39.649
Ryan Dymek: as far as rights. Now, by the way, I haven't even addressed reads, we're just pricing out rights right now. That's all we've been doing. Okay. So we're going to come back here again. Our write rate. Okay, now it's 3, writes per second 3 writes per second, we're not going to worry about peaks

401
00:57:40.086 --> 00:57:44.000
Ryan Dymek: and we're not gonna worry about contracts and things like that. Okay.

402
00:57:44.150 --> 00:57:50.369
Ryan Dymek: so just kind of simplify it. So this scenario we're looking at still, about $200 a month.

403
00:57:50.690 --> 00:57:57.560
Ryan Dymek: Okay, so we were able to do this in in S. 3 for about $50 a month. We're able to do it in Dynamodb for 200.

404
00:57:57.990 --> 00:58:02.659
Ryan Dymek: So in scenario one, let me recap on this real quick scenario. One

405
00:58:02.720 --> 00:58:05.510
Ryan Dymek: s. 3 cost me almost $4,000.

406
00:58:07.310 --> 00:58:10.110
Ryan Dymek: Scenario 2 s. 3 cost me 50.

407
00:58:10.670 --> 00:58:12.560
Ryan Dymek: I'm kind of rounding here. Okay.

408
00:58:12.820 --> 00:58:16.139
Ryan Dymek: in scenario one. Dynamodb cost me 300. Something

409
00:58:16.980 --> 00:58:20.289
Ryan Dymek: in scenario 2. Dynamodb still cost me like 200 something.

410
00:58:21.140 --> 00:58:33.450
Ryan Dymek: and there may be some little things here. I may have missed a little bit here and there, but at the end of the day you can start to see where under one condition s. 3 was way more expensive, and the other condition s. 3 was the cheaper choice.

411
00:58:34.450 --> 00:58:39.399
Ryan Dymek: Can I just make a rule that says, always use S. 3, or always use Dynamodb. Of course not.

412
00:58:39.600 --> 00:59:04.870
Ryan Dymek: By the way, the same exercise. I'm gonna push it out even further. I'm gonna use other products, too. I'm gonna compare this with other solutions like kinesis or or or there's a whole slew of products that we could go compare these things through and say which was actually the best. I only narrowed it down to 2 for the simplicity of this webinar. Okay, but in reality there may be 10 possible storage options that we could use here, and we need to be able to understand which one's the best one to choose under that situation.

413
00:59:05.310 --> 00:59:06.730
Ryan Dymek: And that's the message.

414
00:59:06.790 --> 00:59:12.260
Ryan Dymek: Okay, that is the the key message that we need to understand is at the end of the day.

415
00:59:12.430 --> 00:59:40.600
Ryan Dymek: We have, as architects have to contemplate all of these pillars. Okay, so let me just roll back real quick. These pillars, the 6 pillars of the well architected framework. We need to look at all of these things and make decisions, and those decisions are not just in a vacuum. I can't just do it based on cost. So then my next thing is, let's let's step back and go. Okay, I chose S. 3 for this scenario. That's great. Now, how do we apply the Security pillar to S. 3. How do we apply the reliability pillar? And so on all these things?

416
00:59:40.720 --> 00:59:43.450
Ryan Dymek: And and that's how we're going to handle that. Okay.

417
00:59:43.880 --> 01:00:01.980
Ryan Dymek: so so that's I'm gonna say, that's good. Okay, we're done. We're out of time, and that's pretty much everything I plan to plan to address. So I think I kind of timed that pretty well, so I'm glad to have you here. I'm glad you were able to join us. Now, if you want to kind of learn more about all these things. Obviously, this is what those architecture classes are for.

418
01:00:02.780 --> 01:00:06.190
Ryan Dymek: I'm going to hand it back to my my my partner here, all right. Thank you so much.

419
01:00:07.050 --> 01:00:20.298
Axcel ILT: Ryan. Thank you so much. Thanks. Thanks everyone for hanging in there with us. I think we've had pretty much everyone stay the entire time. That is amazing. I'm just gonna quickly share my screen. let. Thank you.

420
01:00:20.630 --> 01:00:21.389
Ryan Dymek: There you go!

421
01:00:21.630 --> 01:00:23.189
Axcel ILT: Okay, let's

422
01:00:24.230 --> 01:00:36.029
Axcel ILT: see if I can do that. And hopefully, you're you're seeing the exit certified site with the upcoming course dates for architecting on. Aws, is that right, Ryan? Just confirm. You can see that. Okay.

423
01:00:36.030 --> 01:00:37.290
Ryan Dymek: Yep. Yeah. I sure can.

424
01:00:37.450 --> 01:01:01.439
Axcel ILT: Okay. Awesome. So if you enjoyed this hour with Ryan, the only thing better than an hour is, you know, 3 days and we are heavily discounting this course that's running on November 19th to the 21.st So it is just this date. If you happen to be free that week. It's 3 days, and the pricing is 60% off. So this 2,000 ends up being about a thousand dollars off.

425
01:01:01.856 --> 01:01:30.949
Axcel ILT: So if you just we'll we'll be giving you all this information to in the after Webinar email with this recording. By the way, so you just click enroll hopefully. You can see your shopping cart and you just put in the promo code. Save aws like save aws, and then apply the code and you'll get that 60% off and we'll we'll give you all of this information as well. So we hope to see you at that class, or or any others, and we also have

426
01:01:31.265 --> 01:01:41.254
Axcel ILT: webinars the next 2 days, and then 2 next week. So we'll send you all of that as well. And we really appreciate you being here. And, Ryan, we thank you as well for

427
01:01:41.820 --> 01:01:56.929
Axcel ILT: for introducing us, or, you know, being here again always a pleasure to work with you and everyone. We hope to see you in a webinar very soon, and I will release you out into the world. And if you have any questions definitely. Let us know. Thanks, everybody.

428
01:01:57.350 --> 01:02:02.420
Axcel ILT: I'll go ahead and stop my share and thank you. Have a great day. Bye, bye, thanks. Everyone.

Free Webinar: Architecting Resilient and Scalable Solutions on AWS [Webinar]

About the presenter, Ryan Dymek:

Alert!

Modal Title

Error!

Default Title

Prompt

Confirm

Login