If we have applications that are running in the cloud
and we're storing data in the cloud,
then we need some type of network
to be able to send and receive data
from that cloud-based system.
Our application may be a public one,
which means anyone on the internet from anywhere
in the world would be able to access that application.
Or maybe it's a private cloud.
And you'll have to have a VPN connection in order
to gain access to that private subnet.
And most application instances have many different services
running simultaneously.
And there needs to be some way for all
of these different services to communicate with each other.
This may be within the same data center using east-west traffic.
Or there may be communication outside
of the data center to information
that's stored in a completely different location.
And that would be referred to as north-south communication.
And, of course, it's very common to have
the ability in the cloud to be able to create and tear down
instances of servers of databases and of other systems.
We can do exactly the same thing with our networking.
We can have virtual switches, virtual routers,
and build an entire virtual infrastructure
with different IP addressing, different routing
configurations all within a cloud-based system.
From the perspective of the network administrator,
these virtual systems look and feel exactly the same way
as the physical systems.
So configuring a virtual switch is exactly
the same process in front-end as configuring a physical switch.
But unlike our physical devices, our cloud-based networking
systems can be created virtually at any time.
We can use our on-demand functionality
to go to a single console, configure
as many different switches as we would like.
And instantly, we now have a new network infrastructure created.
We can combine this with rapid elasticity
so our applications can automatically
create new instances.
And with those new instances would be virtual switches
and virtual routers along with all
of the other cloud-based systems.
It's not uncommon to create cloud-based systems that
may be located at a global provider like Amazon
or Microsoft.
But there's no public access to any of those resources.
This would be virtual private clouds
that have all internal or private IP addressing.
And the only way that you'd be able to connect
to those systems is using some type
of virtual private network.
This allows you to have all the advantages
of a cloud-based system but also have all of the privacy
since no one on the internet has direct access to your data.
Of course, you might be building out an application
that you would want everyone in the world to be able to access.
And in that case, you would use a private cloud.
This would use external IP addresses
so that no matter where you are in the world,
everyone would be able to connect to your service.
And it's not unusual to find situations
where you might have a public-facing part
of your application that users connect to.
But the internals of your application
may only be communicating with each other
over private networks.
This allows you to determine exactly what part
of your cloud-based services can be accessed
by folks on the internet and what
parts of that cloud-based service
are only private for people who are part of your organization.
We would use these public and private subnets
to be able to create segmentation
of your application and of the data.
This application instance might be
running separate virtual private clouds.
It might have different containers
and separate microservices for the applications
that you're running.
This means that there is certainly
going to be opportunities to provide segmentation
of the data.
And now we can start to manage how
we want that data to flow between all
of those different segments.
For example, we might have an application front-end
that users are able to access.
But there may be communication to a backend database that
is all on a private network.
And the users can't directly access the database server.
Only your application server has access to your database server.
This adds additional security between
the different components of your application instance
and allows you to maintain a level of privacy that
is naturally built into your infrastructure.
We might also want to supplement this segmentation
with additional security controls.
For example, we might have a Web Application Firewall, or a WAF,
which is examining all of the communication inbound
and outbound for that application
and making sure that there's no malicious data going
into or out of your application instance.
If you want to segment the network even further,
you might want to use a next-generation firewall.
This allows you to set different subnets
to be able to route between those subnets.
And you can do this all in a virtual environment.
Many next-generation firewalls also
include intrusion prevention so they
can identify any known malicious code that might
be traversing your network.
Many of our applications use the microservice architecture
where there is an API gateway that is simply
accessing microservices of the application
and using application programming interface or API
calls to be able to request and receive data
from that microservice.
Although this provides efficiency and redundancy
for the application, it also introduces
a number of security concerns.
For example, we may have situations
where instead of the client making requests
to an API gateway, someone attacking this application
could circumvent the client and send their own request directly
to the API gateway.
So we may want to examine those calls to see
if they're coming directly from the client
or if someone may be circumventing the client
and sending their own customized calls to our API gateway.
To be able to manage this, you'll
want to perform some API monitoring where
you can view specific API queries that are
coming from the API gateway.
And you can monitor exactly what type of data
is incoming to your database and what information is
being sent back to the client.