Welcome back. In this lecture we're gonna take our latest architectural changes that we performed in the previous lecture and upload them back into our cloud hosted infrastructure. If you recall in the previous lecture, we converted our server-side rendering into client-side rendering for our presentation layer.

 This was done by swapping out the ASP .NET Razor templating solution for a React.js implemented front end. Now one of the features that we're leveraging in this redesign is the capability that our browser has to make direct Ajax calls to our backend microservices. So when our presentation layer loads within our browser, the Shop2018 React component now makes Ajax calls to the APIs implemented as microservice components packaged within our Doka containers. Having made all the changes locally, we recompiled, rebuilt and started up the full environment locally. 

This allowed us to test and everything worked as expected. So now we're at the stage we would like to uplift our latest changes and run them on top of our ECS cluster that we built several lectures ago. So let's remind ourselves what this ECS cluster looks like. You can see that when we launched our ECS Fargate cluster, we launched it within private subnets within our VPC. Now this presents a challenge to us. Because we have client-side Ajax calls wanting to head our microservices components, then the designers is unable to facilitate these requests given that our microservice components are deployed as tasks running in the private subnets of our VPC. The point being each of the three microservice components on the right hand side of this diagram have all been provisioned with a private IP address allocated from the subnet range and to which they've been deployed. So to address this networking challenge, what are our possibilities? Firstly we could stand up a custom reverse proxy solution in which we bind a elastic IP address to it, exposing it to the public internet and then configuring it with reverse proxy rules down to each of our three microservice components.

 Secondly we could update our existing application load balancer, introducing three new target groups, one per microservice and adding in specific custom rules to route the traffic. Or thirdly we could use AWS's API Gateway managed service and as the name suggests, this is a thoughtful purpose solution and our preferred option. So going forward what does our updated solution look like? Well with the introduction of API Gateway, our client-side Ajax calls will first be routed to the public endpoint exposed by API Gateway which in turn will leverage a VPC private link endpoint deployed within our VPC. From here calls with then be forwarded to a network load balancer which is a layer four load balancing service.

 And then finally the NLB will forward the calls to our tasks where the traffic will be processed and the response will traverse the same network path in reverse all the way back to the browser. So before we jump into AWS and make our configuration changes, let's summarize the new components. One, we're introducing API Gateway. Two, we're configuring a VPC private link. And three, the standing up network load balancers. Now currently the only way API Gateway can proxy calls to private resources is through the use of a VPC private link. And the VPC private link has a requirement to forward traffic via our NLB, hence the introduction of the NLB. Okay, that completes this lecture. Go ahead and close it and we'll see you shortly in the next one where we perform the configuration changes mentioned here.