0:08 Welcome back everyone. You are here with us live at AWS Cloud Infrastructure Day. My name is Fiona McCann. I am a solutions architect in the public sector and I'm here with my co-host Art who just had a pretty interesting interview. Yeah, I thought that was a lot of fun to talk to Villim to talk about his journey and also to give some ideas about all of the development that we've had as well. Absolutely. So I think our it's time to transition over to our next segment. I think we should, shouldn't we? And so a lot of folks, you know, all of this AWS cloud is built off of well, I think that Tom here who's sitting next to me will tell us in a second. It's built off of networking as well. But before we uh get too deep into this, I'll have uh Tom introduce himself and tell us what he does here at AWS. Cool. Thanks for having me. Hi everybody. I'm Tomsky. I'm a principal solutions architect focusing
0:55 on all things networking. Uh, so I deal with customers helping them send packets between their network environments on AWS or on premise. Yeah, absolutely. So you say all things networking, Tom, we've got about 20 minutes with you. You think you can cover all things networking? Probably not. Get started today. Yeah, I can scrape the surface. I know you just had an interview with Will and he talked a lot about the innovation we do on the hardware side in the compute space. There's also a lot of that happening on the network space. So we're not just building our own chips. We're not just building our our own hypervisors. We are also uh innovating within the fiber that we're pulling down as well as uh we build our own network equipment. So our own switches. Yeah. And this gives us a lot of interesting capabilities because we can now control
1:41 the network end to end. Uh add encryption when we want to add encryption. In many cases when you're forwarding traffic between resources on AWS, there would be multiple layers of encryption. Uh there's some cool things we can do with uh optical failover. So we have uh cases in the past where there would be a digger cutting through a piece of fiber in one of our availability zones and something that would normally be a huge issue. Uh there was a fiber cut. I think we lost 16 packets which is pretty much uh that's phenomenal. There was a there was a fiber someone destroying one of those things when I worked at one of my first jobs and we had to go home for a couple weeks actually while they repaired it. But I also want to just comment we have a prop over here as well. We talked about fiber. Yes. You know, we call this our fiber tree, I
2:27 think. Right. Tom, do you want to tell us a little bit about the what we actually have included here in uh so so for folks can give an idea of what networking Sounds good. Yeah. So, this is what's in the ground forwarding your traffic. Uh in the fiber tree, there's some interesting uh examples here what we have to do. So, the I think this one here has Oh, we can pull it out. Oh, yeah. Yeah, you can pull it out. Yeah. Uh, I think that one there had a termite uh, coating to prevent from termites getting into and destroying the the connections. I think that has to be in Australia. Okay. And then from an innovation perspective, there's a really cool Yeah. What are we looking at there? Yeah. So, this is a holo core fiber. So, in this regular fiber that we kind of use today everywhere, the light bounces around a lot. So, it's not not actually traveling at the speed of light. It's
3:12 maybe twothirds of the speed of light. And this holo core fiber uh because it's kind of hollow and uh a little bit more rigid, you can actually get closer to the speed of light. So we're we're improving even how quickly you can get light from one location to another. And that what that transforms for people that speed of light transforms for people speed uh in terms of sending those packets that you talked about earlier. Every little counts. Yeah. Yeah. Well, every little thing counts especially when you're on the other side waiting for something to happen uh as well here. Absolutely. If this is something that you've ever worked with, let us know. Those of you who are watching and commenting, have you ever worked with um this type of equipment? And you know, switching to a more um software side of things, I think you have a bit of a demo for us. What are we going to be chatting about in terms of the demo today? Cool. Yeah, we're going
3:59 to talk about application networking. So, I had to decide which direction I'm going to take the demo. And obviously, I can't really demo the hardware, unfortunately. I can just show you the five. Would have been a little bit more difficult for us to set up. Yeah. It would have been fun to see though, for sure. Yeah. Yeah, I've never seen like speed of light. Maybe next time we'll display speed of light. Yeah, we'll do that then. So, we're going to focus on application networking which is innovation within the networking space to help you connect different applications in a simpler way. Uh so, I got some whiteboarding. I have a demo in the console as well and we can we can check that out together. Let's do it. All right, let's start. Cool. Uh so hopefully you can see my whiteboard here. Uh this is uh a very simple example of a VPC or virtual private cloud environment uh with a virtual machine and EC2 instance on the left. that has some IP address range which is
4:45 a unique identifier 10201 and then with VPC on the right hand side that's another private environment that you would create as a customer and you would put your resources in there and again an example application running on EC2 in real life scenarios the applications could run on any type of compute right could be a container could be container in Kubernetes or in our elastic container service it could be even a lambda function so you could have a bunch of different uh compute options to host the applications we're keeping fix simple for today we're going to focus Nice and simple for us. Yeah. On the connectivity purely is for me simple here. Okay. So, uh with traditional networking construct and if there's network engineers out there you're probably familiar with those construct is if you have two networks you can create some kind of logical
5:30 connection between those networks. Okay. And within AWS that could be something like VPC peering or maybe more advanced construct like transit gateway cloud one which can let you build these global network networks across uh all of our regions and then connect them back to on premise as well right uh but when you're connecting to VPC this way you're ultimately saying that I'm now allowing VPC 1 to fully try and connect to everything in VPC 2 and I'm allowing VPC2 to fully try and connect back to anything I have in VPC1 and that it's not maybe what I want right so in many cases I just want to limit that access to specific things. So I So it's set up in a non ideal way. Non ideal way because then I have to go and do like a second pass over this environment and say I want to restrict access using things like security groups, maybe bring in my own firewalls because here in this
6:16 example, you want VPC1 to be able to access just that application that's running on EC2, but maybe you have some other application running on a different EC2 or on Lambda and you don't want them to have access to that. That is totally right. And it sometimes gets even more complicated if you're doing any acquisitions. So, say you acquired a company that has presence on AWS. This unique identifier, the IP address, if it's overlapping, you're in trouble. It's going to be really complicated. Oh, I didn't even think about that. Okay. Now, it gets complicated. Yeah. This is why I'm not a network. I couldn't do it. Yeah. All right. Okay. So, with application networking, Yeah. How are we solving this? We're solving this with application networking, which is kind of a an evolution of networking where uh we're having the network being more aware about the applications that that is transporting. and we're going to make it look as if the application on the
7:02 right hand side appears to be hosted within the VPC on the left or very close to the VPC on the left. Um the service we're going to talk about is Amazon VPC Lattis. Okay. I think we launched that a couple of years ago. Uh and I'm going to talk about some of the features that came out uh since then as well. Okay. Uh but to be able to establish a connectivity, first we need we will need to create a construct called service network. Right. So that little circle is our service network. Service network. You can think about it as a uh as like a container for all of my applications. Okay. Um and then I will have a target group representing my application here. So if you ever used uh elastic load balancing, there's this concept of target groups, right? It's effectively a
7:48 way to track as my EC2 instances are changing, I'm adding more uh or if these are containers, I'm adding more containers. The target group will keep track of what's going on. They all sit within the same. You don't have to worry about, uh, oh, I got to added another instance. Yeah. Uh, so those are the two components that we already have in place. And I'm just going to jump in. Oh, so now we get to see it. We get to see in the console. Yep. I love it. Uh, let me zoom in a little bit. And then it's all going to be under the VPC section. Uh, and then so easy to find. Easy to find, right? No, seriously. I was wondering where you go with this. I'm just saying. And then we have a couple of VPCs here. Uh, the 10201 and 10200. So matching to what I have here. 101 is the client. 10200 is the provider. Perfect. Uh under the private link and VPC lattice. So there's there's
8:33 a few sections here under VPC. So that's where you want to go. Uh we have is the service network already in place. I'm not even going to show you how to create because pretty much a single API to just say I want a service network. Get it ready. That's pretty much it. Set it up in advance. Right. Yeah. H and then this is my target group. So in the target group uh and I'm keeping the naming naming con convention very consistent. So I'm calling it service one target group and I have one target that's my EC2 instance. All right. Just like in your drawing. Y coincidence. I'm following along so far. Yeah. Cool. Make it easy for us. Yeah, that's the best part. So now what we want to do is somehow connect this target group to the service network. And we do that through creating a service. So that's what we're
9:19 going to do together. So services, where is my service? Oh yeah. Dot services. There it is. create service. Create the ladder. What are you going to call it? Service one. I like it. Uh so some of the things that you can do with a service. Uh so we can imagine the service being kind of like a load balancer that will receive your traffic and do something with it forwarded to the target. Okay. Um you can use your own domain. So I'm going to show you autogenerated domain. So when we're doing the demo, you're going to see the host name that we're connecting to the DNS name being very long, kind of awkward. uh in production you'd probably change it to your own custom domain. So something that is easy for you to remember, right? Uh and then we now also have the option to add permissions. So ah this is nice. Yeah. So this is the
10:04 first time we're actually allowing customers to be able to use identity access management to control access to uh their own applications. And maybe we should ask as well the audience how familiar they are with um AWS AM. I think a lot of people have set up uh AM permissions and I think this is also an example of how you know when we launch services the integration that we do across the board we didn't just launch VPC lattice we have it integrated with the AM service so for those who have set up these policies make it easy even right you can benefit from it and so how does that make their lives easier the fact that it can integrate with AM so now you can add policies on top of the connectivity to control access so you can say I only want uh someone with a particular role or with a particular set of credentials to be able to connect to
10:50 my application. Otherwise, lattice is going to drop that traffic. And so we could use an existing role that's already in set up in you can use an existing role that you have deployed on an EC2 instance. So in my example here, if I had a role on that EC2 instance, that EC2 instance can find out the credentials of that role and use them in the request. So that's one extra caveat that you do have to make sure that whenever you do a request to lattice, you actually include the IM credentials in there. Absolutely. And we have some comments from our viewers who are saying that they actually consider IM to be one of the foundation services of AWS. Um someone Samma home said that IM is a critical service for secured architecture and you know we're seeing that in action right now. So thanks for pointing that out for sure. Exactly. And I think that when we talk with customers I know that most customers have taken advantage of AM as well used it. Okay. I
11:35 think we need to create our service network here. Yeah. We're going to run out of time if uh so I'm not going to share the resources. I'm not going to set up monitoring, but if you want, you can enable logging to see who's talking to who and kind of have some auditing. I just will say I encourage you to enable the logging as a general rule of practice. Enable it not just for security, but also for tracking and knowing what's happening in your system. Sorry, you're going to Let's move. We type in our port. That's a totally good call call out. Enable logging everywhere you can. That's I'm as a engineer, I just enable it. I'm telling you. Yeah. No, it is going to save you time later. I I promise you, you will need it. Wait. Yeah. Sounds like it's based on experience as well. So, yeah. No, no, no. Everything I've done is perfect. Yeah. Never had a problem. Never caused
12:22 a problem myself, but Okay. So, we're looking at listener identifier. So, now the listener is what the service is going to listen on. So, receive connections. So, we're going to say I want to listen on HTTPS, so port 443. And then when I receive connections on that port, I want to forward to the target group I created earlier. So, that's the stitching of the service and the target group. uh and we can immediately associate that with a service network as well. The one I created earlier and just here summary and create a lot service. While this is happening, success uh here's what we've done. So we created this service and then associated with with a service network uh s that's listening on port 443. Okay. Uh and then that can forward traffic to the target group. So now with this
13:07 association, we gave the ability for the service network to be able to reach into VPC2 and connect to the application that it needs to talk to. So you don't have to set up any additional like peering, transit gateways, any additional connectivity there. You're ultimately giving access straight from the service network. You mentioned a few things there, but let's maybe dive a little bit more into what is some of what are some of these steps that it's eliminating? What are things that people no longer have to worry about setting up themselves? So if if you're if you're moving an application to VPC, you don't have to use any other networking construct. So you don't have to use transit gateway, you don't have to have peering, you can even remove load balancers. So it allows you to remove a lot of components in the path and kind of integrate it into one thing uh rather than you having to go in and you know add these components yourself. Absolutely. We have a couple comments in here. CBFTW says that logging is the
13:53 only way that they've solved some configuration problem. Sounds like that's a similar experience out there. Um and Victor Victor Victor says that port 443 is very popular. So maybe this is something that Victor Victor Victor might be implementing in their applications. All right, cool. Okay, so final step. So right now we have a service. We know where how to send it to the target group. We need to somehow connect this client VPC to the service network. Uh so that is the final step. We're going to go to our service network. Uh click on it and then you can see that we already have one service associated. Yeah. And then we need to associate a VPC. Uh there's a couple of different ways you can do things here. I'm not if we have time I might mention what they are but for now we're just going to keep it simple and just do a VPC association. Let's do it. Uh create a VPC
14:38 association. You just pick the VPC you want to connect to. My client VPC I need to specify the security group. I preconfigured some of the security groups. It's almost like you're prepared. Yep. I've done it before. Uh okay. So this association is happening now. So now the VPC is connected to the service network. And Tom, I just want to give you I want to stop you really quickly to tell you that you're getting compliments on your drawing skills. Uh Mermillo says that you have elite paint skills. Thank you. I think I think the drawing is fine. I'm I'm still concerned about my writing. That's the problem. You know, you can't be perfect because everything is exactly. Hey, we can read it and Fiona and I that's all that counts. Maybe just because I said what it was. Well, who cares? We're also getting we're getting a question in here. Um Jill Rochelle says, "How
15:24 difficult is it to move from that traditional architecture peering load balancers etc to this service network?" It's a good question. It's not difficult at all. You can have these things running in parallel and you can decide on an application by application basis to move them one by one to another model. So it's pretty straightforward. There you go. Perfect. Jill Rochelle, maybe it's time for you to start trying it. Cool. Well, after we finish this demo, listen to us first. Okay, that's true. So, we got to connect to the uh to our client. Uh so, I'm going to do that now. I have it here. Client, I'm going to connect. I'm going to connect for the browser so we don't have to do an SSH session outside of the browser. Perfect. Make it easy for us. Okay. So,
16:10 as this is happening, uh how do we know what's the host name that we need to connect to on the service? So, we need to go and check. Whoops. We need to go and check in the service configuration what is the host name exactly. So if I'm going to click on it, there's a domain name here. This is the long one I mentioned earlier. Super easy. I can memorize that right now. Yeah. So normally in production you would convert that into your own custom domain. So if I do a DNS lookup on it, yeah, it gets back with this IP address. So this IP address is a range that we reserve for the service network. So the VPC knows to send all that traffic to the service network. Okay. And then uh finally I'm going to try and connect to it uh HTTPS. So I'm going to use curl which is like an open- source tool to
16:55 connect to HTTPS services. And I'm going to paste my service name. And voila. Okay. Awesome. So I've configured my application to reflect back some of the information that it's seeing from the request. So this is its own local IP address 10 to 100. So we know we're here. We're into 10 to 100. It's seeing the connection from this IP address 169254. So it's seeing the connection from the service network on this path and then uh x4. So that is actually capturing the client IP address. And interestingly here we see a IPv6 IP address and the reason for that is I haven't told you but this VPC also has an IPv6 range. And what happened is the EC2 decided to use the V6 to connect to the service and then V4 was used to connect to the target. Hm. So that tells
17:42 me that it has integration with both IP type and it can it's very common to to use it for like migrations between different IP address spaces as well. We have a question. It says can the target group be an existing ALB and can the service be spread across multiple accounts? Uh so target yes can be uh an existing ALB. The service usually would live in a single account. Okay. Uh but you can target whatever you want. So you can point it to a thing that might be in a different account as long as you can reach it. All right. Um and um we have another question. Can we use curl to connect uh to the protocol instead of https? Uh I just used curl. Yep. So I did use curl. So we demoed curl. Come on. We demoed. Where were you when it's got it all ready for you? Uh so one quick comment I want to make is we're showing one service. Uh you can
18:29 have dozens of services in here uh in production, right? And then you can also have other things like databases. All of your applications could actually be hosted in the service network. So from a perspective of a administrator, you can immediately immediately see like an audit of every single application that you've exposed. Yeah. With traditional networking, it's kind of a freef fall. You open it up completely. As a network owner, it's actually really hard to see what's going on. With uh application networking constructs, you're exposing applications one by one. So it's very easy to audit. It's all consolidated. The person who's auditing doesn't have to look in multiple different places, do that extra configuration. Boom. It's sitting in the service network. Yep. So from a network administrator perspective, this is making life easier. Yeah. Life a lot easier as well. So Tom, we don't have a lot more time here today. I just want to thank you for coming out and doing this. Anything else
19:16 that folks should know about this? I think everybody should get started and try out V. Oh, sure. Yeah. If you have a chance, uh, play around with it, set it up. It's super simple to configure. As you've seen, you can start with EC2 instances and then you can go as advanced as you want like pointing to Kubernetes deployment or Lambda functions. There you go. All right. There you go. Thanks. Thank you so much for joining us. Thanks for joining us. Thanks for having me.
