Building SaaS on AWS - Delivering SaaS with AWS PrivateLink for SaaS

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
[Music] [Applause] hello everyone and welcome to the third episode of building sas on aws my name is gill magrosh i am a developer advocate at aws and if you're thinking i want to build a sas solution or if you think i want to improve my sas solution or i want to learn more about sas well then you've tuned into the right show because that's exactly what we're doing here we're going to help you look at how to build sass on aws and on the previous episode of this show i was joined by oppa uchval and anabab from the aws sas factory team to talk about architecting a serverless sas solution and that is really what we do we deep dive into sas specific topics so that you can learn more about building sas on aws and we want this to be as interactive as possible so if you have comments if you have questions just post them in the chat and me and my guests will do our best to answer those questions and this week i am joined by sudhir and amanda welcome to the show the both of you hello hey hello hey so let's start things off with the standard introduction sudhir tell us a bit about yourself hey hey everyone my name is sudhir uh i'm i'm i i'm part of a team we call aws satisfactory here so i'm a patent solution architect and what i do on a day-to-day basis is work with sas isvs to accelerate their sas journey on aws and i'm glad to be here and i think we have a great interesting topic for today and on that hi good night thanks and nice to meet everybody here my name is ananda raja gopal and i'm the specialist for private link and a few other networking services with an aws worldwide specialist organization all right so if the previous two episodes have been pretty straightforward based on the topic building multi-tenant sas on amazon eks building serverless sas this topic is perhaps a bit more unknown and might need some more explanation i think for the viewers we're going to talk about delivering sas using aws private link this week so let's start off with what is the customer problem we want to solve by using aws private link so let me go with that so when you think about what customers are trying to solve you know many customers have got zero trust initiatives uh they have a need to meet regulatory compliance they want to consume sas services and they're really looking for a way where the exchange of data between the enterprise and the sas provider is done in a private and secure way especially given many of the compliance regulations as well as cyber security threats that are facing enterprises today so that's kind of the core problem that these enterprises are trying to solve so from a sas provider perspective the big question is how do you offer this in a way which is secure which is compliant and doesn't expose your infrastructure to any of the uh threats that are happening on the internet while the same time providing the best experience for for customers and so what we're really looking for here is to have that best-in-class infrastructure that could be provided to these customers to solve the problems mentioned before and and to to show how this can be done i know that you've built a sas private link reference architecture can can you tell us a bit about how and why you built that yeah so maybe one way to think about that is you know how sas services are typically consumed in an enterprise today and that would kind of lead into the sas reference architecture so perhaps i'll talk about you know the typical ways how perhaps you as a sas builder might be thinking about offering these services and then so they can talk about the uh the reference architecture so when you think about how to offer these services to you to your enterprise customer you're probably thinking about okay and i'm i've got a public ip address i've got the internet right and that's the way in terms of how you would access it totally fair and perhaps if you're having something which requires monitoring or some kind of a service which has got an element of on premises maybe you're even thinking in terms of okay i can just use vpn there because perhaps not everything is located in aws for a hybrid infrastructure maybe combine that with direct connect maybe everything is completely cloud native so which means your customer is also located in aws and therefore you maybe just use vpc peering or transit gateway and just connect those two vpcs together none of these are technically wrong right all of them are absolutely impossible however the big question is is there a better way is there a different way to get secure connectivity and do it in a private way to offer this from from the point of view of a sas service which leads into what the sas reference architecture is that sudhir maybe you can cover sure thanks uh yeah like ananda said the sas reference architecture the reason we built it was uh you know we wanted to show our take on how uh you you know the the sas provider can consume a solution like this which we're going to get into right to enable private connectivity for your tenants for your customers and and like the use case says we wanted to come up with a solution that's a scalable right uh vpc pairing the example that i undertook is scalable only to an extent right if you're talking about hundreds and thousands of tenants you don't want to be in the business of figuring out uh iph clashes and cider cider blocks etc so uh this reference architecture hopefully will show you how to enable private link for your existing tenants but uh you can absolutely use it to extend it for net new tenants as well right and uh what we are also going to show is the behind the scenes orchestration and sort of workflow that is also supported by by the features of a aws private link so we'll get into those uh details shortly yeah don't worry we're gonna get to code we're going to get to architecture diagrams we're going to get to all of that throughout the show but i think we need to cover the basics a bit because private link is perhaps not that known to to a lot of the viewers and i can see already that we're getting some questions in the chat sean has posted something that looks like a really good question but i think we'll save that question just for a few minutes and do some of the basics around private link to begin with and then we'll get to that questions but keep dropping your questions and comments in the chat and we'll get through them throughout the show so talking about the basics then let's let's uh look at aws private link for well the people who are new to the service sure so one of the one way to think about private link if you're not familiar with that is it's really combining the best of two cloud constructs virtual private cloud which is effectively the private network that can be isolated from the internet from all of the vpcs and also the aspect of sas wherein you're kind of bringing in the sas into uh your vpc you're being the the enterprise customers vpc so you're really kind of combining both of those so think about this from the perspective of an enterprise who is deploying a sas application and is effectively bringing in the sas application into the vpc effectively what private link does is to provide a private path over the aws network wherein the enterprise customer consumes that service in another vpc using a private ip address so that's the first key thing so remember sudhir mentioned you don't need to worry about any kind of overlapping ip addresses or trying to do any kind of ipa risk coordination because that's messy business and you know after all your customer and yourself are totally entitled to have completely overlapping ip addresses number two the big one is that the traffic completely remains on amazon's private network so it doesn't go to the internet you don't even need an internet gateway even though traffic is actually crossing between two organizations in the picture that you see here that sudhir is showing right now you see the sas consumer which we'll keep referring to as the enterprise or the sas consumer on the left and on the right you've got the sas provider that is what is the infrastructure that you're hosting the two are connected even though they're across accounts across vpcs over the aws backbone a few things to note is that there is a concept called interface endpoint that the sas consumer sets up now that gets set up within a private subnet you do not emphasize need any access to the internet gateway you don't even need to use any kind of network address translation which is the reason why you will notice that the ip addresses are actually overlapping and that's done by design when you see the sas consumer on the left and the sas provider on the right they've actually got overlapping ip addresses third really important one is from an enterprise perspective they are often concerned in terms of am i having a third party that is kind of accessing into my network even though i'm using a sas service so if you notice closely in terms of the flow of those bubbles that are you know flick going back and forth between the sas consumer and the sas provider initiation happens from the consumer and the sas forward is responding to that right so imagine maybe you have for sensor for example perhaps you're using you know a service like data dog for example as an enterprise customer this may be a sensor that is located in the sas consumer vpc which collects metrics which collect locks and then kind of pushes into the sas service on the right and last but not the least which is a very powerful capability this is a mutual handshake that we'll talk about later on wherein the sas consumer and the sas provider effectively and have a communication before this connection or the channel gets established to exchange data that's a really important aspect that we'll come back to again later on because from a sas provider's perspective you also have to take into consideration any kind of attacks on the infrastructure when you're building out a sas infrastructure and so the cyber security aspects are pretty important to make sure the availability and uptime of your service is is maximized with private link because it's being offered over a private network your your service endpoint is not really exposed to any kind of attacks in the wild right so give us a couple of examples of how this is used today then can can you give some references for instance or specific solutions that are using this type of architecture yeah absolutely so one example i could give is since we just talked about datadog uh datadog you know is a pretty well known service that every builder is familiar with they offer the endpoint service over uh private link and so if you are a consumer of data doc you would effectively set up the interface endpoints your applications would be accessing the interface endpoint by the way that's the last thing which i should have mentioned that you know okay once all of this is set up maybe as a builder you're thinking okay how do my applications now access the other service you're just accessing the interface endpoint just like any other dns name right so there's really no change the applications apart from accessing that second example could give is mongodb which offers database as a as a service and the mongodb is also integrated with private link we have over 400 um you know different types of sas providers and close to 1200 organizations that i've integrated with private link you can actually use this even for any kind of third-party you know connectivity um you know apart from of course accessing aws services but for today's talk since everybody is really keen about sas we'll focus specifically on the sas usually i think that's good all right so maybe now now is a good time to bring on sean's well the first part of sean's questions and it's a long one so hopefully you won't disappear off screen ananda you did so let's do this now ananda's back all right so i'll read out the question i'm building a sas product for the marketplace right now i want my clients to use aws private link the challenge challenge is that i'm using a private ip gateway endpoint i do have an endpoint connected to api gateway can i get that endpoint viewable by client for aws private link connection after they subscribe great question if it is on marketplace the answer is yes so any kind of services that your customer has uh subscribed to in the marketplace would be visible in the console so remember the three types of services that are shown one is when you go to the private link console that you'll actually see in the demo later on one is connecting to aws services maybe like kinesis or s3 or sqs etc the second is third party services and the third is my aws marketplace services so that's one of the options you'll see in the radio buttons and so if your customer has actually subscribed to whatever service you're providing um sean uh they can definitely see that in the console and then yeah it's second part and with the least amount of changes required by the customer yes good then by the way the bonus advantages i should say of integrating with marketplace if you have not integrated with marketplace it's a there's a little bit more work that happens and we'll come to that in just a couple of minutes when sylvia and i will walk through kind of the three-way handshake involved there and then the last part of the question is that his sas product is completely serverless so comparing this to the architecture diagram you showed before he doesn't use a vpc can he use private link without a network load balancer and vpc okay so today private link necessarily requires an nlb you cannot use private link without an nlb however you can have your infrastructure that is serverless you have to front end that with an nlp today and obviously that means that it has to be in a vpc all right here we go keep your questions coming we are here all our all right so we've looked a bit at what private link is then so is it time to perhaps start looking at the reference architecture absolutely i think i i just have the good segue view for that which is up on the screen now so uh what i'm what i'm showing here is um sort of like an overlay on what ananda showed in the previous slide right so on on the left you still have the sas consumer and on the right you have the sas provider and the bits from the previous slide are still the same so you have a vpc endpoint that your consumer is trying to access your sas service over and on the provider side if you see here is where i i threw in a question mark and then that's where i i'm gonna sort of dive deep into right uh so aws whatever doing like another set and needs that backing nlp right now the way it is built right uh so the question in a typical multi-tenant sas environment becomes how how do i as a provider identify um who who my consumer is right so that's the sort of crux of what this reference solution is built around but but let's take a step back right let me explain this architecture diagram a little bit more so what i'm showing here is a cookie cutter sas provider if you will who happens to use ecs elastic container service as their primary compute choice and what i'm showing here is each tenant gets a service uh that is siloed for themselves right so this is a silo architecture style of sas and what i'm showing here is a service per tenant essentially so uh so if you move a little bit to the left now with aws private link the the little bit of configuration that provider has to do is the routing piece essentially right so how do you how do the provider how does the provider identify uh who who the incoming traffic belongs to and send it along the way to the appropriate destination fuel so that's the simple view that i'm trying to show here uh and we'll get to a little bit more nuanced view later so so hopefully that helps position what the reference solution is we are keeping it intentionally simple and and the solution itself what it does is it bootstraps and installs what you're seeing here on the screen so what you need to consume the solution would be two aw bus accounts to sort of mimic uh the consumer portion of the solution with one aws account and the provider solution with another aws account and then once you go through the bootstrapping process pretty much what you see on the screen here will get configured and installed on your database accounts so that's in a nutshell or the reference solution the scope of the reference solution is all right and yeah go ahead go ahead no i'm just going to go lead into the next screen but i think i think let me pause there right so just if you just joined us this is building sas on aws our bi-weekly show about building sas on aws and today i'm joined by sudhir and ananda to talk about using aws private link for your sas solution and we're going to dive into the the reference architecture quite a bit throughout the show so i think we have another question let's bring that up while we have that slide can you elaborate does both accounts needs to be configured the short answer is yes yes to consume the solution uh what you would have and again these are these are elaborated in detail in the prerequisites section eventually on the github repository but the short answer is yes you need to have two aws accounts already configured in your awcli this entire solution is packaged as a cdk uh application so you would use the cli profiles behind the scenes so i would have one profile pointed to the consumer aws account the other profile pointed to the you know the scan hope that answers the question i hope so as well and keep your questions coming here we will follow a question assume we have video streaming provider how would this work with private link that's very specific question i'm using right it is it is um let me move on to let's see if i have a view which sort of answers that question or or maybe on another we can elaborate a little bit on what layers of voice stack does aws private link address in today's world right because this reference solution that we're going to talk in detail today is catered more towards layer seven and layer four so if i i think to take a stab at your question if your video streaming service is operating in the layer four territory then yes you could use uh something like a aws private link to consume that stream right and again there is a equivalent layer three uh private link solution as well um so i don't know if you wanna if you wanna take a snap of the question should i think that we need to explain those different layers what they mean yeah so so first off uh private link uh currently supports only tcp based traffic right so if your service uses udp then private link now is not applicable there what sudhi was referring to is that private link is kind of the underlying technology which actually helps kind of bring together the consumer and the provider there are actually multiple types of endpoints you will notice in the sas consumer there is the terminology called vpc endpoint now also referred to as an interface endpoint which is one kind of an end point there's a second kind of of a private link endpoint which is called as a gateway load balancer endpoint right and that is a way to actually have you know one of your in-line appliances or something which is more at layer three that is kind of built into uh you know the the the infrastructure too so that is an option too but your specific question assuming that a video streaming provider is offering the service over over tcp then yes that could be done now again you can only access a service over private link as long as that provider is offering that endpoint service over private link because both parties have got to obviously do that right perhaps one way to think about this is that normally you would build a service and provide that service and expose that service using a public endpoint here rather than using a public endpoint you're using a private endpoint that is designated as an endpoint service by the service provider that you see on the right i hope that answers the question i hope so all right so so did any other slide you want to show in regards to the architecture absolutely let me let me talk a little bit more uh and i think this second slide and now we're getting into the layers actually so these next two set of slides will actually make sense um so just to throw a nuance over what i've shown in the previous uh view right if you are a sas provider who's operating in uh the layer 4 like another refer to in the tcp realm right so what you would typically use in front of your services and again i'm still sticking to the same ecs example but you could think of any compute choice here right i think we already got a question around serverless it could be eks it could be any type of compute as long as your service is aware of layer 4 is operating within the tcp realm you would have something like a nlp in in front of it right assuming it's a load balance service so so a little bit of nuance here is um if you see uh if you follow my cursor i'm kind of hovering on this whole ingen x layer i'll come to it in a second but what we're doing in this reference solution is sort of applying routing logic in between the a private links nlb and the service nlb that you might already have in your stack right so a solution for layer 4 would typically involve a a setup like this and to get into what nginx does here we are using engine x as a reverse proxy in the solution uh we'll get into the details as to why uh but but you could substitute this with any reverse proxy for that matter right so we just need some brains behind the scenes which can do intelligent routing questions for us leveraging what aws privately provides so so that's that's a typical solution for layer four uh only component that has changed really is that routine layer um for and the key thing i think another already stressed on this is for your tenants for your consumers the experience doesn't really change this is the solution is really focused on what you have to do as a sas provider right what is the routing logic the tool that you need to build on your end of the equation for your consumers end of the day it's a dns endpoint that they're gonna hit right so you however they consume in today's world they will just start to consume it using another dns name which happens to be private accessible within the vpc so the consumer experience doesn't change now just to um sort of say go into layer 7 uh if you are a sas provider who happens to have a sas surface in layer seven like the presentation layer maybe it's a typical web application right or a api that you are exposing to your tenants then you would typically have something like a alb application load balancer in front of your compute stack right and again uh the conformity in the solution is whether you have an alv or whether you have an lb will still rely on this nginx layer that's acting as a reverse proxy in between private link and where your services are hosted so my point here being we definitely wanted to give a solution i think one of the users already asked we wanted to give a solution for sas providers which is which is not destructive right minimum description all they have to do is introduce this additional routing layer and business as usual right so for their tenants who still want to use and consume the service over um public internet the ingress routes they already have in today's world still apply right so there to think of i'm not showing here on the screen but think of the existing english routes will still route traffic to this service alv and it will go on its way to the uh backend services we are just introducing another route essentially using this architecture so hopefully that makes sense um but yeah these are the two nuances that i wanted to bring out in the solution hey steve can also add to this so if viewers if you're thinking wow this is a lot of layers of nlb and nginx and alb here what is being shown here is kind of more of the pooled mode wherein you're kind of offering a multi-threaded service using common infrastructure the other popular mode that we also see is wherein there's a siloed mode that customers deploy uh sorry providers deploy and in that case you really need only a single nlb that is front-ended that is connected to the private link service and then at the back end you know the nlp will directly route to the specific tenant because effectively there is a dedicated infrastructure for for each tenant that is used right so so that's also a possibility that that you could use from an architecture perspective absolutely that's a great point right and sean has a question he's thinking about changing his architecture now based on what you just showed and uh perhaps using nginx in his architecture would that be a good choice actually if you are already using api gateway api gateway is integrated with private link i would recommend you continuing to use that again you can certainly use the nginx approach too it is important to note that private link is integrated with close to 120 aws services including api gateway if it is any other third party service you have to use a network load balancer so you cannot directly connect the nginx with private link you will need if you notice uh if you can bring back the picture again uh sudhir so you notice that the private link is associated with ingress nlb and then there is an nginx behind that right so you'll have effectively two layers of load balancing there if you were to using if you were to use the enginex approach which has got a lot of value in situations like the one that surreal is showing but if you already have api gateway which provides the level of abstractions which is probably why you chose that in the first place make use of api gateways native integration with private link right and using using nginx would mean that you need to have instances running as well that is true so moving away from a surplus architecture that way as well all right so then i think we're 30 minutes into the show we haven't seen any code yet um i'm getting itchy i want to see code so bring the code yeah so all right let me let's have a look at the reference architecture and see we'll see what it looks like absolutely i think i think i'm pulling up the code screen now oops unless i asked again powers for yeah my screen keeps switching so okay uh yep so here's the code um so let's let's get into the code and and hopefully i'll throw some structure around it so uh like i said you know this entire reference solution is a single cdk app right um the beauty of cdk is you know you get to deploy it with the existing cdk cli and the tooling so let me talk a little bit about uh how we structured this code right and then hopefully this should align with um i'm just trying to find the customer here it should align with the picture that we just showed um on the slide so let's just mention straight away that this is being open sourced it's not yet available on github but very very shortly isn't that right absolutely it's it's in the works uh we are uh going through the process to open sources so you will find this on aws samples eventually and we'll share out that link when it's ready that's right um so so yes this is where i wanted to start if you're familiar with cdk and the way cdk structures uh typical cdk projects you will see that bulk of the infrastructure as code as far as the cdk code goes sits in the lib folder and the way we organize the lib folder is uh the way i showed you in the picture right so there's a consumer app and there's a provider app and consumer app is exclusively what gets deployed in the consumer account and provided in the provider account respectively right so if i go to provider app real quick you will see how i structured the various layers of my infrastructure right so anywhere from the app itself and then by the way the app in this reference solution is not at all fancy it's a simple hello world think of it as just a shell of a api which happens to render in your browser right so nothing fancy there so that's my app and if i just expand it you will see that it just has two uh portions to it it is a cookie cutter client and then there's a back-end api right compute hopefully you still connect the dots i'm going to use ecs for as my compute stack and then i tend to uh package my service i'll be with the computer itself it's it goes in one stack to me that's the logical way there's no hard and fast rule however you organize your apps uh feel free to uh continue to do that right the uh the the point i i guess i want to drive in this entire um structure walk through is if i if i go down to this this folder called private link this is where the meat of the crux of what private link is doing for you is packaged right so rest of the modules if you will you could choose to consume them or you choose to discard them like for example i i happen to use identity i haven't used cognito right so that's a module and so on infrastructure to me is vpc ingress to me is route 53 because i happen to be a publicly served sas provider with a dns and a hosted zone and everything so i have 53 i have a sas rest api which is my control plane api so so you get the idea right so that's my existing ingress and uh what i'm trying to do here is to tack on private link and enable private link private connectivity as a feature right so that's why we organized it this way and finally uh for storage i'm just using dynamodb um and because this is uh hello world app i really have no need for functional storage data so all i have is just a tenant store right so these are the layers that would get deployed to your provider account uh once you bootstrap and deploy this solution and on the consumer side it's really really simple right all i have is a vpc as my infrastructure a simple ec2 instance just so that i can connect to the private link service and show that yep this is how i consume it and then finally as part of private link all i have is a vpc endpoint right so that's how i organize the code here um all of these little modules both on the consumer and providers side are stitched into uh two apps if you will i'm literally calling them sas service and sas consumer and and they do bubble up to your bin folder and again this is going into how cdk apps are typically packaged right but the idea here is uh because this is completely cdk end-to-end and again sorry if it's funny i'm trying to find my cursor i just can't see it but it works so um excuse me if i'm just fumbling around uh okay i think i think i'm back in action okay um so so yeah um so what what we also did was package this entire experience into simple bootstrap scripts right uh running this bootstrap script is literally gonna instantiate everything for you so what i'm gonna do here real quick is let's see if i can show you the actual command that you could use to bootstrap it so i i think i have it here it's at the bottom of the screen what i'm going to supply to this bootstrap script is just couple of things right first and foremost is two aws cli profiles like i said you have to have awcla configured because you are deploying this reference solution into two aws accounts for the consumer and the provider and then what i also have is think of think of this reference solution as an existing sas provider who happens to serve already in the public domain so typically because i'm using route 53 typically i would need the hosted zone id uh where where i control the dns settings and then the uh the the host itself name itself right so just bare minimum parameters to uh instantiate everything and once you go through this let me see if i can do a demo run right here once you go through the bootstrap script what you hopefully see towards the end is a simple set of commands that you would run a couple of them in the provider account a couple of them in the consumer account just to test out um this reference solution right so we are also giving you the commands to go ahead and test it out so this is all cdk this is no none of this is the reference solution this is the regular cdk exhaust what it's doing is just going through the chain of all you know little modules that we just talked about it's trying to deploy them i went ahead and deployed it ahead of time just to save time so what you're seeing is pretty much a cdk saying that hey there's really no changes here um so hopefully it will just breeze through so let's give it a minute and then while it's doing its thing um [Music] what i do want to show um real quick and i think if you are sort of trying to get beyond the structure of the code and get into some meat of what we built here right um i will really start with private link right the topic of the day so um so let me open up oh by the way i think the boot subscript is done so you you'll actually see here um sorry if it's two verbose but you will see here that really there's only uh four steps in the entirety right and then some of these steps you can absolutely skip like for example step number one is all about tenant onboarding right you might already have a elaborate process to onboard tenants onto your sas application this is just a think of this as a hello world sort of onboarding right this is very unique to my demo the reference solution um just to show you how things so what i'm doing here is my uh my tenant onboarding is kicked up using an api call this is my onboarding api call that is typically part of your sas control plane right and to this api call all i'm going to ask as input is just three things hey who are you right meaning what's your email id right so think of this as a tenant administrator or your customer administrator signing up for your service for the very first time so all they're doing is supplying an email address and uh declaring couple of things like hey i want a sub domain called tenant type of one right you could abstract this experience away but at the end of the day this api call should on board return it for you uh and at this step it has nothing to do with private link this is a typical onboarding right now once your onboarding is done this is where um we'll we'll get into what another you did too is the three-way handshake so i'm gonna save this for later right we'll come back to this so let me pause right there so at this point you you your reference solution is bootstrapped it's deployed to two aws accounts by doing step one you have already onboarded one tenant onto the stack okay so so far so good we'll pause there let me just switch gears and go into code a little bit and show you what we are doing within private link itself so uh so real quick so as you can see cdk simplifies a lot of things so it's just a few instances of lines of code to enable private link on your sas app all i'm doing here is i'm declaring that hey i need a vpc endpoint service right and and i'm literally saying that this vpc endpoint service like the diagram showed is gonna use this ingress nlp as the packing nlp right um now what i'm gonna do uh in this particular stack is i'm not really declaring what the eventual target is that's handled by a separate module so what i'm doing here is just declaring a vpc endpoint service the backing nlb and then just exporting out cfn out bare minimal information that i need to consume this private link in different parts of the stack and we'll get to where i'm actually consuming it um so let me pause there i think i've talked enough about about the structure of the solution and the bootstrap script and the good stuff so let's get back into uh concepts and theory for two minutes and let's talk about 3d handshake i think that's a really important topic here yeah so that's a pretty important one so uh viewers you may recall that we spoke about how there is a coordination which happens between the provider and the consumer now for reference purposes let's imagine that you're not using private link and you have exposed as a sas provider you've exposed your endpoint over a public ip address because it's public ip address it's a public dns name anybody can access that that's both an advantage and also a downside because bad actors can also access your endpoint in the case of private link because the endpoint is being privately exposed over the amazon private network to potential customers of yours the handshake works slightly differently before the consumer the sas consumer can initiate a connection you need to allow list that account okay so sas provider allows the account and that's the first step wherein let's say you got a particular account id in this particular case you know what you see there one two three four five six seven eight nine zero one two is the account id of the sas consumer that wants to access the sas service that you built so you have to allow listed account that is step number one step number two is after uh you have now listed their account they will see your service your service endpoint uh in the console and of course you can also access that through api so that's step number two so for example supposing your service has got a domain name of let's say service.example.com the reverse proxy of that or the reverse dns name of that com.service.dns com.service.example in this particular case is what would be visible in the third party services the consumer needs to initiate the connection to you okay you cannot initiate the connection into your sas consumer account the sas consumer needs to do that remember we spoke about security and how enterprises really like that aspect where they retain control in terms of when they initiate the connection so that's the step number two and step number three which is part of the three-way handshake is you as a provider would then approve that now you can automatically accept that or you can see i'm going to kind of um you know go through the process to to prove that so they will shortly speak in terms of uh you know how that portion can be automated too now until you have approved that you'll basically see your customer will basically see the connection in the pending acceptance stage which is exactly what you what you see sudhi is showing in the console here by the way gunnar i noticed that there was a question in terms of how did they char how the charges work and what outbound traffic is charged from one account to another account um so that is actually a pretty important point from a sas provider perspective you are not paying any charges for private link apart from hosting the nlb okay so you pay the nlp charges nlb obviously has got an hourly charge as well as the lcu charges based on the connections etc so if you're already using an nlb you're not paying any extra charges including any responses that you're providing to the sas consumer the sas consumer on the other hand will be paying two kinds of charges for private link number one they pay hourly charges for the interface endpoint if i'm hopefully they're using a multi-availability zone architecture in which case if they've got an interface endpoint in let's say two or three availability zones they'd be paying an hourly charge for each of them they will also be paying for any data that is sent over that interface endpoint both send as well as receive but user provider did not incur any additional charge apart from the nlp that is there awesome awesome thanks another so the yup that's that's a key concept here the three-year handshake and and real quick while another was talking i just pulled up um what the reference solution actually deployed ahead of time so i i did this prep for the for the demo so what you see here is exactly what another set right so you have this section within aws console by the way um all right um uh on aws console by the way where you allow principles right so this particular account is my consumer account that i supplied when i bootstrapped the solution and only this consumer can actually even look up my service at this point because that's the only account i have allowed so that's the security so just because you published you you meaning your sas provider has published your service on aws private link doesn't mean that anyone can discover it you get to control who gets to see it right so that's one piece of the three-way handshake and the second one is what another talked about is even the unload principles if they try to connect to your service the connection gets into pending acceptance state till you go through the workplace approve it which we'll see it in a second so i'm gonna switch from console now back to code and i'm actually gonna go into the uh bootstrap script now now that we have talked about three-way handshake these steps will make sense right so we just talked about tenant onboarding step number one that's out of the way the second piece is the the three-way the first step of the three-way handshake that another talked about right so in step two what i'm going to do is and again this is i'm exposing this as a api for my consumers so my consumers can simply go to an api url like this the only key difference being my onboarding api typically is unauthenticated right anybody can sign up for my sas service right if they're willing to pay or if it's free but the second api call is assuming that you are already an existing tenant and now you want to enable private link for your tenancy so i want i have to know who you are so this api call is authenticated two essentially uh once you're done with step two once you uh list a particular consumer or bunch of consumers the step three begins right in step three what your consumers can do and this is where you execute this in the consumer account right and we are we're actually giving you the aws command to do so here and real quick what this command does is it's gonna create a vpc endpoint for the sas service which is here is the dns name for the or the service name for the sas service and obviously we are creating a vpc endpoint so you got to associate it with a vpc and couple of other bits like security groups and finally the cli profile for the consumer account once you file this uh command what happens is uh a vpc endpoint is going to get created in the consumer account and i can show that real quick um like like this right um just refreshing real quick this is the vpc endpoint that got created as a result of that command and it's now it's automatically kept in pending acceptance state it will be in this state till the provider accepts it right so you could create a vpc endpoint as a consumer but the provider has to accept before you start to consume it so back to the code so in step three what you will do next is um uh once you create a vpc endpoint behind the scenes and i'm gonna and i'm gonna have to explain this visually and i think i will switch to slides for a second so excuse me here um so what's going to happen what's going to happen is and and this this is the feature of aws private link you don't have to do anything this comes out of the box right so once your consumer creates a vpc endpoint because aws private link is neatly integrated with sms you could actually build pretty cool automation with this feature right so the you provide an sms topic to your vpc endpoint service as a provider and every time a consumer connects to your service you will get a notification and send us a message and what i'm doing here in the reference architecture is passing on the sms message to my lambda function and my lambda function all it does is it kicks off a step function this is my orchestration this is my workflow right uh it just kicks it off and and and that's it and of course uh what i'm also going to do behind the scenes within this lambda function is keeping a log of who that consumer is what is their aws account id and all of these details are actually provided by aws private link within that sms message right so i'm capturing those in my tenant store and i'll show that in a second but real quick this step function workflow i know it looks busy but what it's doing uh in a nutshell is it's taking this sns message looking up uh who the tenant is based on the account id remember in step one your tenant has already provided you the aws account id so you kind of know who that account id belongs to because you've you got to store it in your time store right so you're going to look that up so that's step one so you're going to look up that aws account id to figure out who the tenant is here and then based on the tenant configuration and i'm gonna switch to my tenant store real quick just to show my point here so i'm gonna pull up one of my tenant records so tenant 32 is my tenant record obviously i tried it 32 times that's why i'm at 10 32. part of my tenant configuration part of my attendant configuration is my tenant port right so remember um maybe i didn't elaborate this but this reference solution is going to show you how to operate on layer 4 right the tcp there so what i'm doing in tcp realm it's all about ports right so you got to assign a particular port to your tenant but you're not surfacing those mapping details to your consumer itself or the tenant itself and that's the beauty of aws private link right so you kind of hide away this complexity behind the scenes so behind the scenes i'm associating port 4280 to this particular tenant and i don't even have to tell the tenant that they have to consume the service on this port they can continue to consume for example take mongodb right mongodb standard port is 27017. if without private link if you are a sas provider operating in public domain and operating on shared infrastructure you probably were doing some sort of creative port mapping right and then you are telling your tenant and consumers that hey you gotta assign you got to access the service on port hundred and someone else is gonna access on port 200 and so on as well you don't have to do any of that because of private link uh you hide it away you abstract it away so this particular piece it brought up so many memories when you talk about that having worked in infrastructure back in the days so yeah happy to see that yeah yeah and that piece what i just showed on the console is what gets used in this workflow right so what i'm doing here is taking that port association information and uh other bits of information like what is the service nlp dns name and so much other metadata that's already available in my tenant store and by the way i'm also using uh systems manager parameter store in the solution right because that's a great uh like we always say right tool for the right job right so tenant store in dynamodb is a great way to access and store 10 configuration but so is ssm parameter store because it's neatly integrated within infrastructure as code like cloud formation and cdk right so i happen to use both of them and here is an example uh where i'm actually storing uh execution token from code pipeline and i'll get to it in a second right but but bottom line in in this step function workflow what happens is my nginx configuration gets stitched and i'll actually show you uh that in action in a second and what that nginx configuration does is uh the the core uh ip of the solution if you will so we'll probably i think gunner will probably spend a couple of minutes there it's okay i don't know i don't want to rush to the year but but you have about a couple of minutes in total left so shoot your demo parts wisely from now on absolutely absolutely uh so let me see if i can get to um uh all right let me see if this still works okay so what i was going to show is my um nginx uh instance and how the nginx configuration sort of makes the routing decision which is the crux of the solution here right um so let me just hop on to one of my uh nginx instance here so i'm going to connect to it using session manager so i don't have a section etc and what i'm gonna do real quick if time permits is connect to the configuration and then by the way all these commands you will see them already available within the code itself so you don't have to go fish around for any of this um so let me quickly while you're getting that and on that question for you so the the reference architecture we saw before it used well as a silo model and would you say that it's common to to only use silo model for your sas solution for this when using with private link or or are companies using the pool model as well they use both it's totally up to you and you know whether you use the pool mode or the siloed board that's really a choice that uss builder make um as many of you know some organizations especially those with high compliance requirements prefer the siloed mode but others don't necessarily care and so that's your choice but private link would work with both all right so okay 30 seconds 30 seconds yup real quick i'm going to breeze through this so so one of the neat little things that aws private link does for you is a layer 4 headers the tcp headers aws private link injects the source vpc id right so what it means is in nginx if i were to introspect each and every tcp packet i will get which uh originating vpc id the packet is coming from or the tcp stream is coming from right so what i'm doing here and by the way i'm actually showing the engine's conf here i know it looks clutchy but i'm going to show you the the core parts here right so what i'm doing here is i'm mapping the custom tlb tcp header that private link gives me and do you remember remember this vpc id that we created in the consumer account i'm literally injecting a rule here saying that hey if the stream is coming from this vpc id i know it belongs to this tenant uuid and guess what this tenant uuid is my upstream server that happens to listen on port4280 which we just saw in the tenant configuration so this is how the various metadata pieces about my tenant the uuid the port numbers the source vpc id the aws account id that i already allowed all of that bits come together in this orchestration layer and i i would say if there's one piece that you were to walk away in this reference solution it would be this orchestration there right the way we are stitching together the enginex con with all this metadata pieces and then finally of course because this nginx is running in an auto scaling group you get this neat little trick where you update the launch configuration and just tell auto scaling group to refresh itself right and while you just onboarded a brand new tenant onto aws private link without disrupting your existing tenants that's the key all right hopefully that makes sense i think those were your final words to do it i have to say thank you to the both of you i know another we want to mention the service ready program as well for aws private link partners i posted a link in the chat and with that i have to thank you both for joining me thanks a lot this was great i hope the viewers enjoyed this as well and i'll see you all again in two weeks bye bye thanks bye guys bye [Music] [Applause] [Music]
Info
Channel: Gunnar Grosch
Views: 153
Rating: undefined out of 5
Keywords:
Id: aq7KlrHllT4
Channel Id: undefined
Length: 59min 58sec (3598 seconds)
Published: Wed Sep 08 2021
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.