In this lesson, we're going to discuss
cloud security and its various components.
Cloud security is comprised of several different components
within a virtual private cloud.
By understanding the different cloud security features
that are available and how to use them effectively,
you can help to protect your cloud-based resources
from unauthorized access and attack.
A virtual private cloud is commonly referred to as a VPC,
and it's used to provision a logically isolated section
of a cloud provider's infrastructure
where you can launch various resources inside
of a virtual network that you as the consumer have defined.
By using a VPC, we can use software to create
a virtual network environment that is much more flexible
and scalable than a traditional
hardware-based networking would allow.
Virtual private clouds are an integral part of the larger
concept known as infrastructure as code, or IAC.
Infrastructure as code includes
the provisioning of architectures, where the deployment
of resources is going to be performed
by scripted automations and orchestration.
While infrastructure as code can be applied
to various aspects of your cloud-based infrastructure,
including servers and databases, your VPC
is going to be used to specifically focus
on the networking aspects of your cloud-based infrastructure
when using infrastructure as code.
Now, the virtual private cloud provides us
with a lot of different features and core components
that you should be aware of, including subnets,
route tables, internet gateways,
network address translation gateways,
network access control lists, security groups,
VPC peering, VPC endpoints, and VPN connections.
First, we have subnets.
A subnet is arranged within your virtual private cloud
that you can allocate to the instances
that you are going to be launching.
You can have public subnets that are accessible
from the internet, or private subnets
that are not accessible from the internet.
Second, we have route tables.
Now, a route table contains a set of rules, called routes,
that determine where network traffic is going to be directed
by your switches and routers
within your virtual private cloud.
Each subnet in your VPC has to be associated
with a given route table, otherwise it's going to be isolated
and not able to communicate
with other resources in different subnets.
Third, we have internet gateways.
Now, an internet gateway is a horizontally scalable,
redundant, and highly available
virtual private cloud component that allows
communication between your instances,
in your virtual private cloud, and the internet.
Essentially, an internet gateway provides a connection
between the resources in your virtual private cloud
and the publicly available internet
that lies outside of your virtual private cloud.
Fourth, we have NAT gateways.
Now, a NAT gateway, or network address translation gateway,
is used to enable the instances in a private subnet
to connect to the internet,
or other cloud service provider resources or services.
But they also are used to prevent the internet
from initiating a connection with those instances
inside of your virtual private cloud.
Simply put, a NAT gateway acts as a broker
between your private subnets and the public internet.
Whenever an instance in your private subnet
needs to connect to the internet, it's going to send
its traffic to your NAT gateway, and then the NAT gateway
will translate the instance's private IP address
to a public IP address in order to forward
its traffic the internet.
Fifth, we have network access
control lists and security groups.
Now, network access control lists,
also known as network ACLs, are similar to our traditional
network firewalls and they operate at the subnet level
within your virtual private cloud.
Each network ACL is comprised of a number of different rules
that your cloud service provider will process,
in an ascending order, to determine whether or not to allow
or deny network traffic that attempts to enter or leave
your subnets inside of your virtual private clouds.
Now, each of these rules can be customized to suit
your specific network traffic control requirements as well.
Now, our network ACLs are going to be used to create
two sets of rules, one for inbound
and another for outbound traffic requests.
Inbound rules will control the traffic that's allowed
to enter into your subnets, while the outbound rules
govern the traffic that's allowed to leave your subnets.
It's important to remember that network ACLs
operate like a stateless firewall.
This means that each rule for inbound or outbound traffic
is going to be evaluated independently,
and it does not consider anything that came before it,
or anything that comes after it.
For example, if an inbound rule will allow traffic
from a specific IP address to go into your subnet,
the corresponding return traffic also has to be explicitly
allowed by an outbound rule, otherwise it will get blocked.
Now, it's important to note that both security groups
and network access control lists, or ACLs,
are two different types of firewalls essentially
that control inbound and outbound traffic
for your instances and your subnets.
Security groups are really the preferred way to control
inbound and outbound traffic for your instances though,
because they are more granular than your network ACLs,
and they can be used to control traffic
on a per port or per protocol basis.
Security groups, unlike network ACLs,
are going to be designed to function at the instance level
within your virtual private cloud.
Basically, a security group will serve
as a virtual host base firewall for a specific instance,
and then it can be used to control both the inbound
and outbound traffic for that instance.
Now, unlike a network ACL, security groups are considered
to act like a stateful firewall.
This means that if an outbound request
is made from your instance, the inbound response traffic
will automatically be allowed in.
Similarly, if a request is made and approved
by an inbound rule, then it may open up an outbound port
to respond to that request
without being explicitly asked to do so.
Each of our security groups is comprised of a set of rules
that define the allowed inbound and outbound traffic.
When you create a new security group,
it has no inbound rules by default.
And therefore, no inbound traffic
is going to be allowed into the instance.
Similarly, when you create a new security group
for an instance, it's going to allow all the outbound traffic
to go out due to the default allow outbound rule
that's configured by default by your cloud service provider
when a new security group is created.
Network ACLs, on the other hand, can be used to supplement
our security groups, but they should not be used
as a replacement for security groups.
For this reason, the use of both network ACLs
and security groups will offer us
a lot of different security advantages.
By using these tools, we're going to be able to provide
granular control over our network traffic,
and this allows us to tailor our security
to our own unique requirements.
By properly configuring these components,
we're also able to create a more robust
and multi-layer defense for our virtual private clouds.
Network ACLs and security groups
do have some challenges though.
For example, if you incorrectly configure the rules
within these tools, you're going to inadvertently
block legitimate traffic, or you could potentially allow
harmful traffic to pass through to your resources
instead of blocking it.
For this reason, it is really important
that your network ACLs and security groups
are correctly configured for security.
And that you audit your rules regularly
to ensure that you're still providing the level
of organizational security that you want.
Sixth, we have VPC peering.
Now, virtual private cloud peering is a network connection
between two virtual private clouds
that enables you to route traffic between them privately.
VPC peering is a great way to connect two VPCs
that are located in the same region as well,
because this makes sure that the traffic
doesn't go through the public internet.
And instead, it will improve the security and performance
of your resources by keeping those two VPCs peered
in a local area network configuration.
Seventh, we have VPC endpoints.
Now, VPC endpoints allow private connectivity to services
hosted inside of a cloud service provider,
like AWS, from within your VPC
without using an internet gateway, a VPN,
or AWS's Direct Connect service.
VPC endpoints can be a great way to connect
other cloud-based services that are not publicly accessible.
And again, this can improve performance and security,
because a large amount of this traffic
will not need to go through an internet gateway,
and instead, it can be handled locally
inside the cloud service provider's network.
Eighth, we have VPN connections.
Now, VPN connections can be created between your VPCs
and your remote network, or between two VPCs.
This can be used to connect your on-premise network
into your cloud service provider's network,
or to connect two VPCs that are located in different regions
of your cloud service provider's network.
Now, in a traditional network, these functions might occur
with various physical devices, like routers, firewalls,
unified threat management systems, and switches.
However, by using these virtual private clouds,
all these functions can be virtualized instead
so that we have more flexibility and control
over the functions themself.
And they've been abstracted from the hardware level
to the software level inside of our cloud-based designs.
A VPC does provide us with numerous advantages
over traditional networks,
by allowing us to mix products from different vendors,
to increase the speed of our network development,
and add layers of automation and policy management.
Virtual private clouds can also enable us to fully automate
our deployments within the cloud, which makes VPCs
a critical tool for high velocity
or high availability architectures and disaster recovery.
Now, despite the benefits of using a virtual private cloud,
there are also some challenges you need to be aware of.
For example, if connectivity to the VPC is lost,
your entire network could end up going down.
Also, the centralized nature of the VPC
makes it a potential target for attackers,
so it's crucial that you ensure the VPC is properly secured
before you use it inside of your production environments.
So remember, the virtual private cloud, or VPC,
is a logically isolated section
of your cloud service provider's infrastructure
that you can use to launch their resources
for your organization's use.
VPCs are more flexible and scalable than traditional
hardware-based networks as well.
And VPCs are considered to be a part of a larger concept
known as IAC, or infrastructure as code,
where the provisioning of architecture,
and the deployment of resources is going to be performed
by scripted automation and orchestration.
The key components of VPCs are things like subnets,
route tables, internet gateways,
network access translation gateways, network ACLs,
security groups, VPC peering,
VPC endpoints, and VPN connections.
Virtual private clouds can provide a number of advantages
over our traditional networks,
including increased flexibility, scalability, and security.
However, there are some challenges associated with VPCs,
such as the risk of being a single point of failure,
and the need for properly securing them
before using them inside your production environments.