YT YouTube2Text

YouTube2Text → Transcripts → CloudFormation, Load Balancers & Auto Scaling Explained | AWS Cloud Practitioner | Day 18

CloudFormation, Load Balancers & Auto Scaling Explained | AWS Cloud Practitioner | Day 18 — Transcript

by Pawan Joshi · 5,280 words · 937 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Hey everyone, welcome to day 18. We are
0:02getting really close to the finish line
0:03now, and today is one of those days
0:05where a lot of different puzzle pieces
0:07from earlier in this course are finally
0:08going to click together into one big
0:10picture.
0:11Today's theme, and honestly one of my
0:12favorite lines in this whole course is
0:15build it once, scale it automatically,
0:17sign it once, govern it all. Let's
0:20quickly unpack what that actually means
0:22because it perfectly summarizes
0:23everything we are covering today. Build
0:25it once refers to infrastructure as code
0:27using CloudFormation.
0:29So, you never have to manually click
0:31through the console to rebuild the same
0:32environment twice. It scale it
0:34automatically refers to elasticity using
0:36Elastic Load Balancing and AWS Auto
0:39Scaling.
0:40So, your application can automatically
0:41grow and shrink based on real traffic
0:44demand.
0:45We have sign in once. That refers to
0:47identity using AWS IAM Identity Center
0:50and identity federation. So, employees
0:52don't need separate logins for every
0:54single AWS account or business tool.
0:56Govern it all refers to multi-account
0:58governance using AWS Organization and
1:00service control policies. So, large
1:02companies with dozens or hundreds of AWS
1:04accounts can still enforce consistent
1:06rules everywhere.
1:07This is genuinely how real large-scale
1:09companies run their AWS environments.
1:12Nobody at big companies manually
1:13clicking launch instance in the console
1:15every day, and nobody is creating a
1:17hundred separate logins for a hundred
1:19separate employees. Everything you learn
1:21today is about automation and scale,
1:23which is exactly why this topic spans
1:25both
1:26domain two and domain three, that is
1:28security and compliance and cloud
1:30technology and services.
1:32By the end of this today's video, you
1:34will be able to explain what
1:35infrastructure as code is and how AWS
1:37CloudFormation implements it.
1:40You will be able to compare Application
1:41Load Balancer and Network Load Balancer
1:43as well as Gateway Load Balancer. What
1:45are these three balancers? We will
1:47understand how AWS Auto Scaling provides
1:49elasticity using dynamic, scheduled, and
1:52predictive scaling.
1:54We will also see AWS IAM Identity Center
1:56and identity federation for workspace
1:59single sign-on.
2:00We will also understand AWS
2:02Organizations service control policies
2:04and AWS Control Tower for governing many
2:06AWS accounts at once. And then we will
2:08do a hands-on lab where you will deploy
2:09a real CloudFormation stack, put a load
2:12balancer in front of it, watch traffic
2:14bounce between two servers, and then
2:15cleanly tear the whole thing down. So,
2:17let's get into it.
2:18So, now let's quickly map out today's
2:20journey before diving in so you know
2:21exactly what's coming and how it all
2:23connects.
2:24First one is AWS CloudFormation.
2:26The fundamentals of infrastructure as
2:28code.
2:29The next is elastic load balancing. That
2:32is comparing ALB, that is uh application
2:34load balancer versus network load
2:36balancer versus gateway load balancer.
2:38The third we will see AWS auto scaling.
2:40We will cover dynamic scheduled and
2:42predictive scaling. Then we will cover
2:44AWS IAM Identity Center and identity
2:46federation. That is workforce single
2:48sign-on at scale.
2:50We have fifth one, AWS Organizations
2:52service control policies and AWS Control
2:54Tower.
2:55Governing many accounts at once.
2:57The sixth is our hands-on lab where we
2:59will deploy a CloudFormation stack
3:01sitting behind a load balancer.
3:03Notice the natural flow here. First, we
3:05will learn to build infrastructure with
3:07code with the help of CloudFormation.
3:09Then we will learn to scale that
3:10infrastructure automatically
3:13with the help of load balancing and auto
3:14scaling.
3:15Then we will learn how people securely
3:17access the infrastructure using Identity
3:20Center. And finally, how large
3:22organizations govern all of this across
3:24many accounts. It's basically the
3:26complete life cycle of running AWS at an
3:28enterprise scale. So, you will
3:30understand that all today. Let's start
3:32building.
3:33Let's start with a concept that's
3:35incredibly important in the real cloud
3:37world. That is infrastructure as code.
3:40Often abbreviated as IAC. So, what's
3:43infrastructure as code?
3:45Here's the simplest way to understand
3:46it. Instead of manually clicking through
3:48AWS console every single time you want
3:50to create a server, a network, or a
3:52storage bucket, you write all that
3:54infrastructure down as a text file,
3:56almost like a recipe. Then a service
3:58reads that recipe and builds everything
4:00for you automatically, exactly the same
4:02way every single time. Think about the
4:04difference between baking a cake from
4:06your own memory versus following a
4:07written recipe. If you bake from your
4:10own memory, every cake might come out
4:12slightly different. Maybe you forgot an
4:14ingredient one time and add too much
4:15sugar another time. But if you follow a
4:17written recipe exactly, you will get the
4:19exact same cake every single time, no
4:22matter who is baking it.
4:23That's the entire philosophy behind
4:25infrastructure as code,
4:27consistency and repeatability.
4:29So, how AWS CloudFormation works.
4:31CloudFormation is AWS' own
4:33infrastructure as code service. It reads
4:35a template file written in either JSON
4:37or YAML format, and then automatically
4:39provisions, updates, and deletes an
4:41entire collection of resources together
4:43in a correct order.
4:44So, for example, a single CloudFormation
4:46template might describe create a VPC,
4:49then create two EC2 instances inside
4:51that VPC, then create an S3 bucket, then
4:54attach the right security groups.
4:56CloudFormation reads all of that,
4:58figures out the correct order to build
4:59things in, since some resources depend
5:01on others existing first, and creates
5:03the whole environment for you in one
5:05shot. So, what are the benefits of it?
5:08Repeatable deployments means you can
5:10deploy the exact same environment in
5:12deployment, staging, and production with
5:14zero manual guesswork.
5:15Version control infrastructure. Since
5:17it's just a text file, you can save
5:19different versions of it, just like you
5:21would do with the source code, and track
5:23exactly what changed over time. Safe
5:26automatic rollback. Like if something
5:27goes wrong partway through a stack
5:29update, CloudFormation automatically
5:30rolls everything back to the last known
5:33working condition, rather than leaving
5:34your environment in a broken,
5:36half-updated condition.
5:38Here is something worth remembering
5:39clearly.
5:40Deleting a CloudFormation stack removes
5:42everything that stack originally
5:43created. This is actually a really
5:45useful feature for cleanly tearing down
5:47a test environment. Instead of manually
5:49hunting down and deleting 10 different
5:51resources one by one, you delete the
5:52stack once and CloudFormation cleans up
5:55everything behind the scenes. This exact
5:57scenario, that is clean environment
5:59teardown, shows up often in exam
6:01questions. So, here's something to
6:03remember. CloudFormation is declarative
6:05infrastructure as code, meaning you
6:07describe what the final result look like
6:08and CloudFormation figures out how to
6:10get there. It is not like a scripting or
6:13automation runner like Systems Manager
6:15run command, which we covered back on
6:16day 17, I guess. So, run command
6:18executes specific commands or a script
6:20step-by-step, and CloudFormation
6:22describes an end state and builds toward
6:24it. Don't mix these two up if a question
6:27mentions both. All right? Now that we
6:29know how to build infrastructure, let's
6:31talk about how to distribute traffic
6:33across it. This is where Elastic Load
6:35Balancing or ELB comes in. So, what does
6:37a load balancer actually do?
6:39Imagine a busy restaurant with only one
6:41waiter. If 100 customers walk in at
6:43once, that one waiter gets completely
6:45overwhelmed and service grinds to a
6:47halt. Now, imagine you have a host at
6:49the front door who intelligently seats
6:51guests across five different waiters,
6:52spreading the workload evenly.
6:54That host is exactly what a load
6:56balancer does for your application. It
6:58automatically distributes incoming
7:00traffic across multiple targets, like
7:02EC2 instances, containers, or IP
7:04addresses, and it can spread this
7:06traffic across multiple availability
7:07zones for extra resilience as well. AWS
7:10actually offers three different types of
7:12load balancers, each suited to a very
7:13different job. Let's go through them one
7:15by one.
7:16We have the first one that is ALB.
7:18That is Application Load Balancer.
7:20ALB operates at layer 7, that is the
7:23application layer, meaning it
7:24understands HTTP and HTTPS traffic at a
7:26detailed level.
7:28This means ALB can make smart routing
7:30decisions based on the actual content of
7:32a web request. For example, routing
7:34based on the URL path, like sending uh
7:37images request to one group of servers
7:39and API request to different group. Or
7:42based on the host name being requested.
7:44So, one of the best use cases like
7:46modern applications and microservices
7:48architecture where intelligent content
7:49aware routing really matters.
7:51We have next one that is network load
7:53balancer, NLB. NLB operates one level
7:56deeper, that is at layer four, the
7:58transport layer. Working directly with
8:00the raw TCP and UDP traffic rather than
8:02understanding web content specifically.
8:04Because it works at this lower simpler
8:06level, NLB is built for ultra high
8:08performance, extremely high throughput
8:10and extremely low latency. It also
8:12supports something ALB does not, a
8:13static IP address. So, one of the use
8:16case of this NLB is situations requiring
8:18extreme speed and performance, or
8:20specifically requiring a fixed
8:21unchanging IP address for the load
8:23balancer itself.
8:24We have the third load balancer that is
8:26gateway load balancer, GWLB. This is the
8:29newest and the most specialized of the
8:31three, operating at layer three, the
8:33network layer.
8:34Its specific job is quite different from
8:36the other two. It's designed to
8:37transparently insert third-party virtual
8:40security appliances into your network
8:41traffic path. Think firewalls, intrusion
8:44detection systems, or deep packet
8:45inspection tools built by security
8:47vendors. GWLB lets you route traffic
8:50through these tools seamlessly without
8:51disrupting your existing network
8:53architecture.
8:54So, for the exam, remember this.
8:57Whenever you see a scenario asking for a
8:58static IP address for a load balancer,
9:01the answer is network load balancer, not
9:03the application load balancer. All
9:05right? So, let me summarize this for
9:07you. ALB, that is application load
9:09balancer, it is a smart, content aware,
9:12and web traffic, that is layer seven.
9:15Okay? NLB is raw speed, static IP, TCP,
9:19UDP, layer four.
9:21Another we have GWLB, that is gateway
9:23load balancer, third-party security
9:25appliances, transparent insertion. Now,
9:28let's pair our load balancer with the
9:30service that actually decides how many
9:32servers should exist in the first place.
9:34That is AWS auto scaling.
9:36So, what is elasticity? Here's a
9:37beginner-friendly way to think about
9:39elasticity.
9:40Imagine a rubber band and it stretches
9:42when you pull it and sinks back down
9:44when you let go.
9:45AWS auto scaling gives you
9:47infrastructure the same stretchy
9:48quality, automatically adding EC2
9:51instances when the demand goes up,
9:53and automatically removing them when the
9:54demand goes back down. So, I'm not only
9:56talking about EC2 instances, but other
9:58resources as well.
10:00This means you are never stuck paying
10:01for 10 servers during a quiet Thursday
10:03night when only two servers were
10:04actually needed.
10:05Auto scaling supports three different
10:07scaling strategies, and it's important
10:09you understand the difference between
10:10all three.
10:11We have dynamic scaling. Dynamic scaling
10:13reacts to real-time metrics as they
10:15happen. For example, add more instances
10:17whenever the average CPU utilization
10:19goes above 70%. This is completely
10:21automatic reactive response. As soon as
10:23the CloudWatch, as you remember in the
10:25previous video, it detects that
10:27threshold is being crossed and auto
10:29scaling springs into action. The next we
10:31have scheduled scaling. It works
10:33differently.
10:34It scales your infrastructure at known
10:36predetermined times based on patterns
10:38you already know about your business.
10:40For example, add extra capacity every
10:42weekday morning at 8:00 a.m. right
10:44before our daily traffic spike begins.
10:47This is useful when you already know
10:48your traffic patterns in advance and
10:50don't want to wait for a reactive
10:51metric-based trigger to catch up. And
10:54the final scaling we have that is
10:55predictive scaling. It is the most
10:57advanced of the three.
10:58It uses machine learning to analyze your
11:00historical traffic patterns and then
11:01proactively scales your infrastructure
11:03ahead of time, anticipating demand
11:05before it even arrives, rather than
11:07reacting to it after the fact. Auto
11:09scaling groups always pair with a load
11:10balancer. This is an important
11:12architectural point to understand. In
11:14real-world systems, an auto scaling
11:16group and a load balancer almost always
11:18work together as a team.
11:20The auto scaling group's job is to
11:22change the number of available servers,
11:25and the load balancer's job is to spread
11:26incoming traffic evenly across whatever
11:29servers currently exist.
11:31So, one controls the capacity, the other
11:34controls the traffic distribution.
11:36Together, they create a system that
11:37automatically grows, shrinks, and evenly
11:39distributes load all without any human
11:41intervention. So, now note this
11:43important thing that every scaling group
11:46auto scaling group is configured with
11:48three key numbers: minimum, desired, and
11:50maximum.
11:52Minimum is the smallest number of
11:53instances that should ever exist even
11:55during quiet periods.
11:57Desired is the number of instances auto
11:59scaling group is currently trying to
12:00maintain. And the maximum is the largest
12:02number of instances allowed it even
12:04during the busiest traffic spikes.
12:07The exam loves testing scenarios at
12:08these exact boundaries. For example,
12:10asking what happens if demand spikes so
12:13high that auto scaling wants to add more
12:14instances, but you have already hit the
12:16maximum limit. So, the answer for this
12:18is it simply won't scale beyond that
12:20maximum, no matter how high demand goes,
12:22unless you manually raise that limit.
12:25All right, now let's shift our gears
12:26from infrastructure to identity.
12:28Specifically, how real companies manage
12:30employee access across many AWS account
12:33and business tools without creating a
12:34messy nightmare of separate logins
12:36everywhere.
12:37The first one is AWS IAM Identity
12:39Center,
12:40which used to be called AWS Single
12:42Sign-On. So, you might see either name
12:44mentioned. It lets employees sign in
12:46just once and from that single login
12:48access multiple AWS accounts and
12:50multiple business application without
12:52needing to remember or manage separate
12:53credentials for each one.
12:55Think about a large company with say 50
12:57different AWS account, one for each
13:00department or project. Without Identity
13:02Center, you would need to create a
13:03separate IAM user for every single
13:05employee in every single account they
13:07need access to. An absolute
13:09administrative nightmare and a serious
13:11security risk, since managing 50 sets of
13:14credentials per employee is basically
13:16guaranteed to lead to a forgotten
13:17password, weak password, or account left
13:19active after someone leaves the company.
13:22So, that's not good. IAM Identity Center
13:25is ideal specifically when you're
13:26managing many AWS accounts through AWS
13:28Organizations, which we will cover in
13:30the next slide. It completely avoids the
13:32need to create separate IAM users in
13:34every single individual account.
13:36Now, let's talk about identity
13:37federation. Closely related, but
13:40slightly different. This concept lets
13:42external identities, meaning identities
13:44that live outside of AWS entirely, like
13:46your company's corporate active
13:47directory or third-party identity
13:49providers like Google or Okta or even a
13:51mobile app social login, temporarily
13:52assume an IAM role without ever needing
13:55to create a native permanent IAM user
13:57for that person inside AWS. Think of it
14:00like a visitor badge system at a large
14:01office building.
14:02Instead of giving every visitor a
14:04permanent employee key card, the front
14:06desk issues a temporary visitor badge
14:08that grants exactly the access needed
14:10and for exactly as long as needed based
14:12on verifying who that visitor already is
14:14through an outside system. That's
14:16federation. Proving your identity
14:18somewhere else and then being granted
14:20temporary or appropriate access to AWS
14:23based on that proof.
14:24SAML 2.0 is the industry standard
14:27protocol most commonly used for
14:28enterprise workforce identity providers
14:30connecting into the AWS.
14:32So, if a question mentions company's
14:34existing corporate directory connecting
14:36into AWS, SAML federation is likely to
14:39be the concept that is being tested.
14:42So, here's a subtle but important
14:43distinction between Identity Center and
14:45Cognito.
14:46AWS IAM Identity Center is for centrally
14:49managing workforce access,
14:51meaning your own employees across
14:52multiple AWS accounts. And Amazon
14:55Cognito is a completely different
14:56service used for managing end user
14:58sign-in to your own customer-facing
15:01application, like allowing customer to
15:03create accounts and log in to your
15:05mobile app. If a question mentions
15:07employees in multiple AWS account, think
15:09Identity Center. And if a question
15:11mentions customer logging into your app,
15:14think Cognito.
15:16So, don't let these two get mixed up
15:17just because they both involve identity
15:19and sign-in. So, yeah, don't forget this
15:21Amazon Cognito as well.
15:23Finally, let's talk about how large
15:24companies govern dozens or even hundreds
15:27of separate AWS account all at once
15:28consistently.
15:30So, first we have AWS organizations. AWS
15:32organizations lets you centrally manage
15:34multiple AWS accounts under a single
15:36top-level management account. Instead of
15:38every department or team having a
15:40completely independent disconnected AWS
15:42account, organizations lets a company
15:44bring all of those accounts together
15:47under one unified structure.
15:49Within organization, you can group
15:50related accounts together into
15:52organizational units, often abbreviated
15:53as OUs. For example, you might have one
15:56OU for all your development accounts and
15:58a separate OU for all your production
16:00accounts, each with different rules
16:02applied to them.
16:04One of the most practical benefits of
16:05AWS organizations is consolidated
16:07billing. This means all the charges from
16:09every single member account roll up into
16:12one single bill paid by the management
16:14account.
16:15And here's a nice bonus because AWS
16:17often offers volume discount as your
16:19total usage increases. Consolidating the
16:21billing across an entire organizations
16:23means the whole organization benefits
16:24from bigger discounts, even if each
16:26individual accounts usage is on its own
16:29wouldn't have qualified for that same
16:30discount tier.
16:31Now, here's important governance tool.
16:34Service control policies or SCPs.
16:37These are JSON policies that get
16:39attached either to an entire
16:40organization unit or to individual
16:42accounts directly.
16:44Their job is to define the absolute
16:46maximum permission that any IAM
16:47identity, meaning any user or role,
16:50within that account is allowed it to
16:51have, no matter what their individual
16:53IAM permissions might otherwise say.
16:55Let's take a real example. No account
16:57inside the development OU, development
16:59organization unit, is allowed it to
17:01launch EC2 instances in the US East 1
17:03region.
17:04Even if a specific IAM user inside that
17:06account has full administrator
17:07permissions granted directly to them,
17:09the SCP acts as an overriding ceiling.
17:12If the SCP says no EC2 in the US East 1,
17:15then no one in that account can do it,
17:17regardless of their individual IAM
17:18permissions.
17:20Now important exam discussion. SCPs can
17:23only restrict permissions. They can
17:25never grant permissions. SCPs work
17:28purely as a maximum boundary or a
17:29ceiling. They never act as a source of
17:32positive permissions on their own. The
17:34actual permissions still need to come
17:36from IAM policies attached to the users
17:38and role that we discussed previously as
17:40well. SCPs simply place a hard limit on
17:43what those IAM policies are ever allowed
17:45it to grant, no matter how permissive
17:46they might be individually. Finally, AWS
17:49Control Tower. Think of this as an
17:51automated shortcut for setting up
17:53everything we just described. Instead of
17:55manually building out your entire
17:57organization structure, OUs, SCPs, and
17:59audit logging piece by piece, Control
18:01Tower automatically sets up properly
18:03configured multi-account environment,
18:05often called a landing zone, complete
18:06with pre-configured guardrails, an
18:08account factory, and built-in audit
18:11logging. So, what are these
18:12pre-configured guardrails? They are
18:14essentially pre-built SCPs, that is,
18:16service control policies following AWS
18:18best practices. An account factory is
18:20which standardizes and automates how new
18:22AWS accounts get created and configured.
18:25Built-in audit logging, so security and
18:26compliance monitoring is set up
18:28correctly right from day one. Think of
18:30Control Tower as the automatic setup
18:32wizard sitting on the top of AWS
18:34Organizations, saving large companies
18:36enormous amount of manual configuration
18:37work.
18:39So, now it's time for our hands-on lab.
18:41Today, we are building a highly
18:42available web application on AWS using
18:45CloudFormation and Application Load
18:47Balancer.
18:48Before we click anything in the console,
18:50let's understand what we are actually
18:51creating.
18:52Take a look at this finished picture. By
18:55the end of this lab, we will have two
18:57web servers running in two separate
18:58availability zones sitting behind one
19:00Application Load Balancer that will
19:02spread the traffic between them. And if
19:04one zone fails entirely, the other keeps
19:06serving requests without anyone
19:08noticing. That continuous uptime is the
19:10whole idea behind high availability.
19:13Now, let's see.
19:15Think of AWS as Amazon's massive
19:17collection of data centers. Everything
19:19we build today lives somewhere inside
19:21this boundary.
19:23AWS is divided into regions around the
19:25world. We are deploying everything into
19:27Mumbai. A region is simply a specific
19:30geographical location that contains
19:32multiple independent data centers.
19:34So,
19:36and here we have availability zones.
19:38Each availability zone is a separate
19:40physical data centers with its own
19:42power, networking, and cooling. We use
19:44multiple AZs so that if one experiences
19:46a failure, like a power outage, the
19:48others keep running our application.
19:52And yeah, so these are our
19:55availability zones, and then we have
19:57VPC.
19:58This is our own private network inside
20:01AWS.
20:02Nothing we build today exists outside
20:03it. Imagine renting a private office
20:06building. AWS owns the city, but this
20:08specific building belongs only to us.
20:11If the VPC is our office building,
20:14each subnet is a different floor.
20:16We create one subnet per availability
20:18zone specifically to achieve high
20:20availability.
20:22We are dividing our network across
20:23distinct physical location.
20:26And you know, our EC2 instances need
20:28internet connectivity so users can visit
20:30our website.
20:31The internet gateway is the front door
20:32of our VPC. Without it, nobody on the
20:35internet could reach our servers.
20:38So, yeah, this is our internet gateway.
20:42And then we have route table. A route
20:44table acts like a traffic cop, telling
20:46AWS where network traffic should go.
20:49The address, like 0.0.0.0/0,
20:53means any destination on the internet.
20:56This rule sends outbound traffic from
20:58our subnets straight out the front door,
21:01the internet gateway.
21:03Then we have security group. A security
21:05group is our virtual firewall. It
21:07decides which traffic is allowed it to
21:09reach our instances.
21:10If port 80, that is HTTP, isn't open,
21:13nobody can load our webpage.
21:15And we have these EC2 instances.
21:17When CloudFormation launches this
21:19instance, it automatically runs this
21:21user script on its first boot. That's
21:24how our webpage gets installed and
21:25configured with zero manual work.
21:28We now have two identical web servers in
21:31two different data centers. If one
21:33fails, the other is ready to serve
21:35users.
21:36Here we also have target group. A target
21:38group is simply a list of servers.
21:40Instead of our load balancer keeping
21:42track of dozens of individual instances,
21:44it just forwards requests to this group.
21:47And the group handles the rest.
21:49And talking about application load
21:50balancer, that is ALB, it is like a
21:52receptionist. Every visitor talks to the
21:55receptionist first, and the receptionist
21:57decides which servers handles the
21:58request.
22:00Visitor one goes to the instance one,
22:02visitor two goes to the instance two.
22:05This is spread traffic evenly, so no
22:06single server gets overloaded. So now,
22:09let's trace a user request start to
22:11finish.
22:12Let's say a user types our URL.
22:14It hits the internet gateway.
22:16And it routes to the application load
22:18balancer.
22:19Then the ALB checks its listener on port
22:2180.
22:22And it forwards the traffic to the
22:24target group.
22:25Then the target group picks one healthy
22:27instance, and the request lands on
22:29instance one or two.
22:31The webpage then travels back along the
22:33same path.
22:35Every time you refresh, the ALB might
22:36pick a different instance. That is load
22:38balancing in action.
22:40Now, let's see this exact architecture
22:42defined as code.
22:44I have this YAML file.
22:46As you can see, we have lab VPC. This is
22:48our VPC boundary, and we have internet
22:50gateway and IGW attachment, that is the
22:52front door up to the internet.
22:54And we have public subnet one, public
22:56subnet two, our two public subnets.
22:59Notice we use um exclamation mark get
23:02ejects to dynamically spread them across
23:05zones automatically.
23:07We also have public route table public
23:08route the traffic cop pointing to the
23:10gateway.
23:12Then we have web server security group
23:13and web server one web server two that
23:15are the our instances and we have web
23:17server target group as well that is a
23:19list of servers pre-registering both our
23:21instances. You might notice something is
23:23missing that is application load
23:25balancer.
23:26It isn't in this template. We are going
23:28to create that manually in the next
23:29step. I will explain why.
23:32Let's deploy the foundation first.
23:35So now as I'm in the console I will go
23:37to the cloud formation.
23:39And I will click on create a stack.
23:43Select with new resources a standard.
23:46And yes and here let's select upload a
23:49template file and choose a YML file. So
23:52I this I have this file that is also
23:53uploaded in the LMS. You can find in the
23:56YouTube description as well.
23:58So I will simply select this file and
24:01upload this and leave all the other
24:03parameters as default and then click on
24:05submit.
24:07Now you can see on this events tab you
24:09can watch each resource appear one at a
24:11time. Once the top level status reads
24:13create complete click on the outputs
24:15tab.
24:16And keep those subnet ID and the target
24:18group ARN handy. We need them right now.
24:21So why didn't the template build the ALB
24:23for us?
24:24Two reasons.
24:26First an ALB needs its own security
24:28group which I deliberately left out so
24:30we could configure it manually and
24:32understand the traffic flow.
24:34Second in real world DevOps teams the
24:36load balancer is often managed
24:37separately because it routes traffic to
24:39multiple different services.
24:45So go to the EC2.
24:46And yes okay select load balancers.
24:51And then let's click on create load
24:52balancer.
24:53And select the application load balancer
24:55here. You can see we have three options,
24:57but we will use application load
24:59balancer here.
25:01Then name it anything. Let me name it
25:03like this and select the scheme internet
25:06facing.
25:07And this under network mapping, select
25:10the VPC our stack created.
25:12And check for both public subnets we saw
25:15in the cloud formation output.
25:17Check them.
25:19So pay close attention here.
25:20If you use default security group
25:22without an inbound rule for HTTP, our
25:25load balancer will time out.
25:27Ensure you select
25:28a security group that allows inbound
25:30HTTP from anywhere.
25:33So simply for now, we will do select a
25:35default one and we will
25:37add one inbound rule for HTTP
25:40in the default security group only.
25:42We have listeners and routing.
25:44Port HTTP on port 80.
25:46For the default action, select forward
25:48to target groups and choose our existing
25:50D18 lab TG.
25:52Remember this rule.
25:53A listener watches a port. A health
25:56check quietly pings your instances in
25:57the background. And routing connects the
26:00two.
26:01Click create load balancer and let's
26:03wait for a minute for the status to
26:04switch to active.
26:06All right. So now let's prove this
26:08actually works.
26:09So what I will do, I will grab the
26:11public IP of both the instances and we
26:13will see what does these both pages look
26:16like.
26:17All right?
26:18So as you can see, this is the public IP
26:21of my EC2 instance.
26:23As you can see, I go to the browser and
26:25open it. You can see what the text is
26:28here. And let's do the same for EC2
26:30instance two.
26:32Mm, okay.
26:34So this proves both our servers are
26:35working independently.
26:37Now go to ALB and let's copy the DNS
26:40name of your ALB and let's open it in
26:42new tab.
26:43Uh as you can see,
26:45it is saying time out, like it is not
26:47loading.
26:48Yes. So what we will do is go back to
26:50our security groups in the EC2.
26:54And as you can see I'm in here and I
26:56will
26:57select the default one.
26:59Add rule and click on
27:02um HTTP
27:06as the type and yes TCP port 80 has been
27:08selected.
27:09And in the source we will select from
27:11anywhere.
27:13So you can click on save rules and yes
27:16we are ready to go. So now you can copy
27:18the DNS uh name and then let's go to the
27:21browser and paste it again.
27:23As you can see now the page is now
27:26showing some text.
27:27Sometimes from instance one, sometimes
27:29from instance two as you refresh the
27:31page.
27:32This is the load balancer distributing
27:34the traffic in real time and
27:35continuously checking health in the
27:37background and only sending the traffic
27:39to instances confirmed are healthy. If
27:42one instance failed right now all the
27:43traffic would automatically shift to the
27:45survivor.
27:46That's high availability and not just in
27:49the theory.
27:50And we are done with the lab here.
27:52Now let's clean up what we have created
27:54since because AWS charges for running
27:56resources so we need to clean up our
27:58lab.
27:59First we will delete the ALB. Since the
28:01ALB wasn't part of our CloudFormation
28:03stack we must delete it manually first.
28:05Go to the EC2.
28:07Go to the load balancers and select this
28:10and actions delete load balancer
28:14and confirm okay.
28:17So yeah. So my ALB is deleted now. So
28:19now what about other resources?
28:21Now we will delete them as well.
28:23Uh I will go to the CloudFormation and
28:26select this 18 lab stack
28:30and click on delete. Confirm.
28:34And click on the events tab and watch
28:36the teardown. Notice how CloudFormation
28:38deletes everything in reverse dependency
28:40order. It kills the target group and
28:42instances first and then the route table
28:44and gateway and saves the VPC for last
28:46since everything else dependent on it.
28:49One template build this entire
28:50environment in minutes, and one click
28:52cleanly tears it all down. That is the
28:55power of infrastructure as code.
28:58Incredible work today. We covered a huge
29:01amount of ground, so let's tie it all
29:03together with a clean recap.
29:05First, we have CloudFormation. That is
29:06infrastructure as cloud. One template,
29:09one repeatable stack deployed
29:11consistently every time.
29:13We also studied about ALB, that is
29:15application load balancer. HTTP HTTPS
29:18routing, that is layer seven. NLB equal
29:21to high performance, static IP support
29:23in the layer four. And we have GWLB,
29:26that is third-party security appliances,
29:29layer three.
29:30We also studied about the elasticity
29:32engine, dynamic scheduled data and
29:34predictive scaling, and it always pairs
29:36with a load balancer in real
29:37architectures. We then discussed about
29:39IAM Identity Center, workforce single
29:42sign-on across many AWS accounts.
29:45Federation equal to external identities
29:48assuming IAM roles without needing a
29:50native IAM user.
29:51AWS Organizations plus SCPs, permissions
29:54guardrails at the organizations level.
29:56And Control Tower, that is automates the
29:59entire multi-account is set up process.
30:02Notice how naturally these pieces
30:03connect. CloudFormation builds your
30:05infrastructure. Load balancer and auto
30:08scaling make it elastic. We have IAM
30:10Identity Center that controls who can
30:13access it.
30:14We have AWS Organizations that governs
30:17the rule across every account where it
30:19all lives.
30:20This is genuinely how modern large-scale
30:23AWS environments are architected in real
30:25world.
30:26Our next session is on AI and ML and
30:30analytics on AWS, and I want to
30:32specifically flag that this session is
30:34built around a full exam task statement.
30:36So, please don't skip it. This is an
30:38area that is becoming increasingly
30:40important on the exam as AWS continues
30:42expanding their AI and machine learning
30:44offerings.
30:45That's a wrap on day 18. You now
30:47understand how real companies build
30:49infrastructure through code, is scaled
30:51automatically based on demand, manage
30:53secure access for their workforce, and
30:56govern everything consistently across
30:58many account. This is genuinely
31:00enterprise level AWS knowledge, and you
31:02have built a strong foundation for it
31:03today.
31:04Fantastic effort. Please go and review
31:07those concepts once more, and I will see
31:09you for day 19. Keep up this amazing
31:11momentum.

About this transcript

This page contains the full transcript of CloudFormation, Load Balancers & Auto Scaling Explained | AWS Cloud Practitioner | Day 18 by Pawan Joshi, generated from the public captions YouTube serves with the video. The transcript has 5,280 words across 937 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.