0% found this document useful (0 votes)
1 views

Customizing VPCs, Routing, and Security Controls - Part 1

Uploaded by

Elmehdi Sahla
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
1 views

Customizing VPCs, Routing, and Security Controls - Part 1

Uploaded by

Elmehdi Sahla
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 4

Okay, cloud gurus.

Welcome to this lesson


where we're going to talk about customizing VPCs,
we'll talk about routing,
and we're also going to cover security controls.
Now we're covering a broad range of topics
throughout this lesson,
including VPCs and the different subnets
and NACLs and security groups.
So let's go ahead and get started.
Now, first things first, let's have a quick review
on what a VPC actually is.
I imagine most of you know what this is,
but, again, I'd just like
to reinforce these fundamental learning blocks
before we continue on.
An Amazon VPC is a logically isolated virtual network
that is dedicated to your AWS account only by default.
Now, let's go ahead and take a closer look
at some of the resources within a VPC
including the different types of VPCs.
Now, VPCs come in two different forms.
There's a default and then there's a custom.
Now with a default VPC, this is automatically created
for you during your account creation.
With these VPCs, it includes internet access by default.
So there's an internet gateway that is deployed by default.
Now, with default VPCs,
any compute that you spin up within them is going
to be assigned both public and private IPv4 addresses
by default.
So essentially, all of your compute is going
to have internet access directly,
as opposed to using a net gateway.
Now, this is a major reason
why you should never use a default VPC for workloads.
They're great to experiment in
and get some hands-on experience with,
but they're never recommended to use for production, ever.
Now, speaking of production workloads,
this is where custom VPCs come in.
With a custom VPC,
you configure every little thing as required.
Now, with the custom VPC, when you spin it up,
internal communication will always be allowed.
So compute can internal privately
using the private IP space,
but there's no default internet access.
You have to explicitly grant and attach an IGW to your VPC
and set up the routing for that to work.
Now, no matter what,
whenever you spin up compute,
it is automatically always going
to get assigned private IPv4 addresses.
This is unavoidable
and that's essentially how networking works, right?
You can't avoid that.
Now, as the opposite of default,
you should always deploy custom VPCs for your workloads.
All right, that's a little bit
about the custom VPCs compared to the default VPCs.
Let's go ahead and move on
and talk about subnetting and routing.
Now, most of this content is gonna be specific
to custom VPCs,
but you do have similar controls in default VPCs.
But for this exam, custom VPCs will always be included
within the scenarios and not the defaults.
Now, the first thing I wanna talk about are subnets.
An important thing to remember is that subnets belong
to one availability zone only.
You can have both public and private subnets
based on the internet access granted to each of them.
Now, a common scenario is going
to be a three-tiered architecture on the exam,
and this is where you will have a web tier,
which is likely publicly accessible
and this is gonna usually include things
like a load balancer.
You'll have an application tier,
which is behind that load balancer,
and is going to be included in private subnets.
And then you'll also have something like a data
or a database tier,
which is also private and is exclusively accessed
from the application tier.
So it's security in layers.
Now, moving on, let's talk about route tables.
Remember, subnets can only have one route table at a time.
You want to use custom route tables
for controlling your routing needs.
Now, a cool thing is,
you can have multiple subnets share one route table
if required.
Generally, a best practice is
to have each subnet have its own custom route table
as this offers the most amount of control.
Now, a new term within VPCs is middlebox routing,
and this is the ability to control your routing paths
of all of your traffic that's coming in or out
of your custom VPCs.
Now, a common scenario for this would be something
like inspecting traffic using security appliances.
So you route traffic through a custom subnet,
which has your security appliances,
and then it can continue routing that traffic
to the other subnets.
Now, the next on the list is managed prefix lists,
and this is simply a set of one or more CIDR blocks.
It's that simple.
What it does is it allows for easier configuration
when you're maintaining your security groups
and route tables.
Now they come in two forms.
There's a customer-managed,
which is where you define the common set of IP ranges;
or there's AWS-managed,
which is usually a set of AWS service IP ranges
that they set.
Now, a common example of this for an AWS-managed one,
would be an S3 gateway.
When you're setting up an S3 gateway for a VPC endpoint,
it allows you to specify the AWS managed prefix list
and route your traffic to those IP ranges.
This really allows you to scale far easier
as opposed to having to put a set of rules
for each individual IP address as they get updated.
So for customer-managed,
maybe you have a default set of IPs
for a security appliance you want to route traffic to.
Well, instead of manually inserting those,
you can create your own customer-managed prefix list
and attach that prefix list into your routing rules.
Hopefully that helps you visualize
how scalable these really are.
The next topic is subnet security.
VPC subnets are going
to reference NACLs or network access control lists
for referencing the allowed and denied traffic
for both inbound and outbound traffic.
Now, we'll discuss NACLs in depth coming up,
but this is very important for you to know,
so I bring it up here.
You need to know that subnets do not use security groups
to control traffic.
That's not how they work.
Now, some more things to know,
subnets are going to have five reserved IP addresses
that you cannot use.
There's a network address, VPC router address,
DNS reserved address,
and then a future use reserved address,
and a broadcast address.
Now, these are more geared toward the networking exam
so it's not necessarily super important.
You know these in depth
but you do need to know that they are reserved.
So let's go ahead and look at a subnet example
for the reserved IPs.
We have our example CIDR here of 10.0.0.0/20
and the first reserved address would be the network address,
which you can see here.
We then have to reserve our VPC router,
which is the first available IP space in that subnet.
And then thirdly, the DNS reservation.
So the next reserved IP space
for allowing internal DNS resolution.
We would have our future use
which is not specified yet, just reserved just in case.
And then of course, the broadcast address,
which is hardly used as well.
So these are five examples of reserved IPs
within this common subnet CIDR.
Alright, cloud gurus.
Now we're getting on the lengthier side for this lesson
and we still have a lot to cover.
So let's go ahead.
We're gonna pause here.
We'll take a break
and then when you're ready,
we'll pick up in part two of this very same lesson.

You might also like