Networking In Aws

VPC with Public Subnet (Hands On) Preview 10:28

This is our first exercise and its very simple. Make sure you follow each step carefully and remember what we did so that while doing next exercises, it will be easy for you to set the things up quickly.

In this exercise, learn how to setup VPC with Public Subnet and connect to EC2 instance launched in this Subnet.

Here, we are not using default VPC. In the real world scenario, when you would require a Web application to be accessible over internet, typically you will create this kind of the setup. Optionally, you may choose to assign Elastic IP to EC2 instance instead of Public IP as Elastic IPs remains associated with the instance even after instance restart or you can detach and re-attach to another EC2 instance.

VPC with Public and Private Subnets (Hands On) Preview 17:13

In this exercise, learn how to setup VPC with Public and Private subnets. We then create EC2 instances in each subnet and connect to Private EC2 instance via EC2 instance in Public Subnet.

In real life, you would have Web server or public facing instances in Public subnets and Application servers/Database servers in private subnet. You can build your network as explained in this video and achieve the desired network security and isolation.

NAT Gateway (Hands On) Preview 05:59

In this exercise, learn how to NAT Gateway to allow EC2 instances in Private subnet to access internet.

In real life, you will have Application servers/Database servers in private subnet but still need to have internet connectivity to download packages from the internet. For this NAT can be used where it allows instances in private subnet to access internet but we can not reach to these instances from over the internet

NAT EC2 Instance (Hands On) Preview 09:07

In this exercise, learn how to use EC2 instance as NAT instead of NAT Gateway.

Understand that NAT Gateway is managed AWS service which automatically scales and is highly available in the AZ. When we use EC2 instance as NAT, its called NAT Instance. In that case, the availability and bandwidth scaling is limited and hence NAT Instance might not be a good choice for deploying in production environment. Typically people deploy NAT instance in Dev/QA environments and use NAT Gateway in Production environment.

VPC Peering across AWS Regions (Hands On) Preview 25:32

In this exercise, learn how to setup VPC peering between 2 VPCs across AWS Regions. VPC Peering is very important feature of AWS networking by which you can create private connectivity between 2 VPC. The EC2 instances in these VPCs can communicate with each other over Private IP addresses.

With VPC Peering, you don't require to have VPN connection and no need to expose your applications over internet if only other customers in AWS need to access it securely.

VPC Peering Use cases and Limitations Preview 11:34

This lecture captures the VPC peering features, limitations and use cases. Though VPC Peering is an important offering from AWS, it has been designed in a way that it does not allow transitive access. Due to this, VPC peering is a safe networking construct which you can use to allow private communication between workloads hosted in same or different AWS accounts in same  or different AWS regions.

VPC Endpoint to connect to S3 over Private network (Hands On) Preview 06:05

In this exercise, we will see how to use VPC Endpoint gateway which enables a private connection between VPC and another AWS service (currently only S3 and DynamoDB). If enabled, you do not require IGW or NAT when EC2 needs to access S3 or DynamoDB in same AWS region. The traffic between VPC & AWS service does not leave the Amazon network.

VPC endpoint gateway scales automatically and provides consistent bandwidth for S3 or DynamoDB access. Using VPC endpoint gateway instead of internet to access S3. It saves you considerable data transfer cost (and NAT charges). Also VPC endpoint gateway scales automatically as more bandwidth is required.

VPC PrivateLink to expose Application services privately (Hands On) Preview 24:48

In this exercise, you will learn how your applications hosted privately in AWS  can be exposed securely to other AWS services.

By definition, AWS PrivateLink simplifies the security of data shared with cloud-based applications by eliminating the exposure of data to the public Internet. AWS PrivateLink provides private connectivity between VPCs, AWS services, and on-premises applications, securely on the Amazon network. AWS PrivateLink makes it easy to connect services across different accounts and VPCs to significantly simplify the network architecture.

In this exercise, we will host a Webserver service in one of the VPC in private subnet and will expose this service to service consumer in other VPC.

AWS Site-To-Site VPN Connection (Hands On) Preview 27:03

In this exercise, we will see how to setup Site-To-Site IPSec VPN connection between AWS VPC and simulated data center.  As we don't have our own datacenter (physical) router on the other end, we will use EC2 instance as VPN endpoint which has OpenSWAN VPN software installed.

After completing this exercise, you will know how VPN works in real world. As a next step, you may also want to  setup VPN connectivity between AWS and Google Cloud or AWS and Azure cloud.

Advanced Networking: AWS and Google Cloup Site to Site VPN using BGP Routing Preview 45:57

In this lecture, we are going to see how to setup site to site VPN using BGP routing. BGP stands for Border Gateway Protocol and used widely for dynamic routing between different AS (Autonomous Systems). BGP stabilizes the network by identifying optimal network paths using Path vector protocol, policy based and rules based routing. If the routing is done within AS then its called internal BGP or iBGP however when its between different AS then its called external BGP or eBGP.

In this lecture, we will setup eBGP between AWS and Google network. This kind of hybrid networks are always seen in big enterprises where there are multiple ISP networks.

Introduction to Client VPN (Client to Site) VPN Preview 12:13

We earlier learnt about AWS Site-to-Site to VPN. In this lecture we will understand the basics of Client to Site VPN and then AWS Client VPN service, its components and architecture.

How to setup AWS Client VPN (Hands On) Preview 29:25

Let's setup the AWS Client VPN from our local workstation to AWS VPC. AWS Client VPN setup is slightly more complicated the site to site VPN and have few more components like Authorization Rules, Authentication etc. But we will see all these components one by one and then will create those as we progress through the lab.

In this lab, you should be able to setup Client to Site VPN successfully.

AWS Client VPN Scenario 1: Access Internet via VPC IGW (Hands On) Preview 05:47

When we setup Client to Site VPN, by default all the traffic from local workstation is routed to VPN including your outbound internet traffic. Now if the VPC to which we are connecting does not have explicit outbound internet connectivity via the IGW then we also can not access internet from our local workstation while we are connected to VPN.

In this lecture we will see how to enable internet connectivity by two available options.

1. Via VPC VGW

2. Using local workstation internet (Split Tunnel)

AWS Client VPN Scenario 2: Access Internet using Split Tunnel (Hands On) Preview 03:48

In earlier lecture, we saw how to access internet via VPC IGW however this is probably not the correct approach in all scenarios. In many cases you might have to access other networks from your local workstations e.g may be home network or you want to use internet connection directly from your workstation. In such situations you can configure split tunnel on your openvpn client. In that case you route only the desired traffic through VPN tunnel and rest of the traffic is routed through your local network.

In this lecture, we will see how to configure Split Tunnel while using AWS Client VPN.

AWS Client VPN Scenario 3: Access Peered VPC (Hands On) Preview 10:08

In earlier lectures we saw few scenarios where we can access internet via IGW or use local internet using Split Tunnel method. However as you now know the Client VPN traffic lands into your VPC's target subnet and from there you can literally access any other network connected to your VPC. You can access IGW, Peered VPC, other IPSec VPN connected to your VPC, transit gateway , VPC endpoints etc.

In this lecture, we will see how to access peered vpc while you are connencted to base VPC via AWS Client VPN.

Transit VPC Preview 07:27

Transit VPC is a solution by which we can greatly simplifies the network topology when it comes to connection multiple VPCs or VPCs and On-premises networks. Transit VPC is not a gateway or any service from AWS but its a solution deployed on EC2 instances in centralized VPC using CISCO CSR 1000V routers. Many companies used Transit VPC solution to solve their networking challenges and it has been a great solution so far. However you should rather look at moving to newly launched service Transit Gateway which essentially solves the same problem natively in AWS.

Transit Gateway - Part 1 (Hands on) Preview 26:22

AWS Transit Gateway is a service that enables customers to connect their Amazon Virtual Private Clouds (VPCs) and their on-premises networks to a single gateway. As you grow the number of workloads running on AWS, you need to be able to scale your networks across multiple accounts and Amazon VPCs to keep up with the growth. Today, you can connect pairs of Amazon VPCs using peering. However, managing point-to-point connectivity across many Amazon VPCs, without the ability to centrally manage the connectivity policies, can be operationally costly and cumbersome. For on-premises connectivity, you need to attach your AWS VPN to each individual Amazon VPC. This solution can be time consuming to build and hard to manage when the number of VPCs grows into the hundreds.

Transit Gateway - Part 2 (Hands on) Preview 11:48

Transit Gateway - Part 3 (Hands on) Preview 15:21

Hosting website on S3 with custom domain name from Godaddy (Hands On) Preview 15:10

In this lecture, we will see how to host static website on S3. However AWS provides custom aws dns names for website hence we need to map our own domain name to AWS provided dns name. This is done using AWS Route53 service. Here for this exercise, I have got my domain from Godaddy and I updated godaddy DNS to resolve to AWS Route53 DNS. Then added record set in AWS Route53 to point the my custom domain to S3.

Note that AWS S3 does not provide a single IP address for websites hosted on S3, hence we have to use Route53 Alias record set to point our domain name to S3 DNS.

Secure website with HTTPS using S3 and CloudFront (Hands on) Preview 16:26

In this lecture, we will see how to enable HTTPS for websites hosted on S3. In the last lecture we hosted static website on S3 however we can't make it HTTPS as S3 does not support uploading SSL certificates. For this we need to have CloudFront (CDN) which acts as a front end for our website. We can deploy SSL certificate on CloudFront and it also caches the static contents like Pictures/Media giving user better experience by serving the contents from the nearest edge location.

For this exercise, we need to have your own domain name. You can buy that either from AWS or from any other domain registrar like Godaddy or namecheap etc. To know how to redirect your DNS queries from domain registrar to AWS Route53, please refer earlier lecture "Hosting website on S3 using custom domain name.."

Route53 DNS Region Level Failover (Hands On) Preview 17:33

In this exercise, we will see how to use Route53 to achieve AWS Region level failover. As you already know we can use ELB with backend EC2 instances to achieve high availability within same AWS region. However many a times its required to distribute your workloads across AWS regions e.g for failover, country specific regulations, providing lower latency to endusers etc. In this case, we need to manage the traffic at DNS level and its done using different AWS Route53 routing policies.

In this exercise, we will be using Failover routing policy where we configure the Primary and Secondary sites in different AWS regions and then simulate the primary site failure which results in DNS switching to secondary site.

ALB with 2 backend EC2 instances (Round Robin Routing) Preview 19:13

In this lecture, we will start with basic ALB with two backend EC2 instances. Important thing here is the VPC network setup. Note that ALB is internet facing and hence should be launched in Public Subnets across AZs however the backend EC2 instances need not be public facing and ideally they should be launched inside Private subnets across AZs.

In this lecture, we will setup the VPC and launch ALB and backend EC2 instances. Also, we will see that by default  ALB does the round robin routing to backend ec2 instances.

ALB Session Stickiness Preview 03:10

In this lecture we will see how to enable session stickiness so that the request from any particular client will be served by same backend EC2 instance. This is often required when you are doing any transaction or session data has to be persisted for some time till user takes some action. Here AWS Application load balancer using AWSALB cookie.

ALB with Custom Domain Name using Route53 Preview 04:41

In this lecture we will see how to use our own domain name to serve application hosted using Load Balancer. For this we need to have our own domain name purchased and use AWS Route53 DNS service. In Route53, we will create A record (Alias) and point our custom domain or subdomain to ALB DNS.

ALB with HTTPS Preview 06:46

In this lecture, we will extend the earlier setup and server our application over HTTPS instead of HTTP. As you already know, in order to enable HTTPS (SSL) communication, we need to deploy SSL certificate for the domain. Hence, we will acquire the SSL certificate for our custom domain from ACM (Amazon Certificate Manager) and deploy it on ALB.

ALB URL or Path based Routing Preview 18:14

In this lecture, we will see how can we use Application Load Balancer to route traffic to different backend EC2 instances based on URL/Path of the HTTP request. As you know ALB works at Layer7 and hence HTTP requests can be intercepted by ALB. Further based on certain string in the path e.g /image /vidoes etc, we can configure the Rules in ALB listener to route traffic to different Target groups which eventually distributes traffic to different group of backend EC2 instances.