This post explains some of the key concepts behind IBM Cloud Virtual Private Cloud (VPC) and looks at how Inspire-Tech used it to create a secure and accessible digital workspace.
This blog post is co-authored by Ting Teck Wei, Head of Technical Operations at Inspire-Tech, and Gajun Ganendran, CTO Cloud Platform at IBM Asia Pacific.
Virtual private cloud concepts and technologies, as explained by Gajun Ganendran.
Virtual Private Cloud (VPC), simply explained, is a mechanism to logically isolate cloud resources by defining network segments and routing rules. Some of the key benefits of VPC include increased deployment of network segments and rules, reduced costs without the need for physical network devices, and the agility to modify network rules as needed. As an example, we will create and design a network and workload architecture within IBM Cloud VPC.
First, you need to understand what a region is within IBM Cloud. A region is a geographically and physically separate group of one or more availability zones with independent electrical and network infrastructures isolated from other regions. Regions are designed to remove shared single points of failure with other regions and guarantee low inter-zone latency within the region.
An availability zone is a logically and physically isolated location within an IBM Cloud Region with independent power, cooling, and network infrastructures. It is isolated from other zones to strengthen fault tolerance by avoiding single points of failure between zones, while also guaranteeing high bandwidth and low inter-zone latency within a region.
We can deploy a VPC within a region. A VPC can encapsulate zones that can be thought of as an isolated infrastructure location. If we wanted to deploy servers for high availability, we would do so by deploying them across multiple zones within a region.
Within each zone, we can define subnets that logically divide IP networks. By doing so, we can place different compute resources depending on the routing rules for that subnet that govern traffic to those resources.
Network subnets and a three-tier architecture
Considering a three-tier architecture that consists of a webserver, app server, and database server, we are going to design our network subnets according to these tiers.
First, we pick an IP address range and define it using CIDR block notation. We'll assign the 10.10.0.0/16 IP address range for Zone 1. Basically we will need to define subnets within this IP address range.
For our web tier, let's define 10.10.10.0/24 as our IP address range. This means we can assign 256 IP addresses (however, you have to take into consideration reserved IP addresses used by IBM within the CIDR block range, which leaves us with 251 IP addresses that can be used for hosts within this subnet). We can adjust the number of hosts by altering the netmask value.
Next, we can create our application tier and database tiers with IP address ranges of 10.10.20.0/24 and 10.10.30.0/24 respectively.
Defining security groups and access control lists
To restrict access to the subnets and to the specific compute resources within each subnet, we can define security groups and access control lists (ACLs). ACLs restrict inbound and outbound traffic to a subnet while security groups act like a virtual firewall and control traffic to your virtual servers.
In our example, we can define a security group for servers in our web tier that can accept traffic inbound from port 80 and all outbound traffic. We can define similar security groups for our app tier and database tiers. For added security, we could add ACLs that allow or deny traffic inbound and outbound.
To design a high availability (HA) architecture and ensure that in the event of resource failures in a particular zone, you can fail-over to resources in another zone, we can replicate the resource deployment in Zone 2.
In our example, we will replicate the web, app, and database tiers in Zone 2 using three additional subnets: 10.20.10.0/24, 10.20.20.0/24, 10.20.30.0/24 respectively. We can then extend out the security groups and apply the same ACLs and attach this to the newly created subnets so we have similar firewalls and access rules defined in Zone 2.
Public load balancer
To support user traffic and scale our environment appropriately, you can attach a public load balancer that will test backend connectivity to the web-tier servers. You can also apply load balancing rules—such as round robin—to route traffic between each server based on inbound requests.
For restricted subnets, you can also attach a private load balancer with similar load balancing without public Internet accessibility. In our example, we have a public load balancer attached to our web tier and a private load balancer situated between the web and application tier.
Finally, we have traffic from an application tier connected to a provisioned database instance called DB1. We can set up replication policies in DB1 to DB2 and failover using clustering capabilities, but we have simplified this in the diagram.
Please see the following video for a detailed explanation:
Creating a secure and accessible digital workspace with IBM Cloud Virtual Private Cloud —The Inspire-Tech Story by Ting Teck Wei.
Balancing between security and accessibility is one of the biggest challenges for organisations of all sizes. Inspire-Tech recognizes how critical this challenge is, and with our products, we bring a secure digital workspace to our clients. Let’s focus on how we revolutionize their entire journey with our secure and accessible file sharing platform, EasiShare.
The existing environment and architecture
One of the challenges that organizations face is how to allow internal users to share files with external parties while isolating Intranet from the Internet. To address this, we deploy EasiShare using what we refer to as “H-Model Architecture.”
In “H-Model Architecture,” we deploy three-tier architecture in an Intranet consisting of web, application, and database servers and another set in DMZ. With this, only specific files meant for external parties are exposed to the Internet—other files remain isolated within the Intranet.
We have successfully deployed this solution to many customers using on-premises model. With increasing demand for cloud, we were looking out for a cloud platform that supports the same secure architecture.
Why use IBM Cloud VPC?
We decided to utilize IBM Cloud VPC for a number of reasons. Network rules and fine-grain access controls can be defined easily to limit access to resources deployed within the cloud environment. Also, by leveraging an additional VPC with peering, we were able to mirror the H-Model Architecture between public and private users of Inspire-Tech’s application platform. This allows us to provide the same network-isolated architecture which aligns with our focus on security.
Our focus is now to work on deploying more instances of EasiShare in the cloud for our customers and working with IBM Cloud to further expand the solution—specifically, leveraging other technologies like IBM Cloud Object Storage to scale our solution
We are looking forward to working with IBM in future projects to add more value to our customers.