This blog will focus on different design patterns for cloud segmentation. As the workloads and applications grow in the cloud, enterprises need to isolate the workload depending on compliance/regulation requirements and security reasons.
It is challenging to create segmentation for workloads in the cloud. It is even harder to do the segmentation in the Multi-Cloud environment. There is no policy-driven option to create multiple security domains provided by the cloud providers, i.e., AWS, Azure, GCP, etc.
At Alkira, we dramatically simplify and streamline cloud network segmentation across multi-cloud architectures. The Alkira Cloud Network-as-a-Service platform provides IT with a unified center for managing, scaling, and operating multi-cloud network segmentation in a true end-to-end fashion.
Figure 1: Cloud Network Segmentation Example
Within the Alkira solution, a segment represents a unique routing and policy space, with each segment capable of supporting overlapping IP addressing and independent route policy. A segment is like a network wide VRF or MPLS VPN, providing an identical standard of secure network isolation without the associated complex deployment and operational burden.
Let’s look at a couple of design patterns for segmentation. These design patterns are supported for all major Cloud Service Providers (CSPs), including AWS, Azure, GCP, and OCI.
Design Pattern 1: Intra-Cloud Segmentation
Suppose the enterprise has multiple departments/business units and wants to isolate the traffic in each department. This can be achieved using the Alkira solution by configuring different segments for different departments and then onboarding the VPCs in each department to the relevant segment.
Figure 2: Design Pattern 1 – Intra-Cloud Segmentation
In the above diagram, we have VPCs in a single CSP that are part of different segments, i.e., Green and Yellow, creating an isolated environment for traffic flows.
Design Pattern 2: Inter-Cloud Segmentation
In this design pattern, if an enterprise organization acquires another organization and they have subnet/prefixes which overlap, they can isolate those environments by creating different segments and onboarding the VPCs to the relevant segments.
The same design pattern is also applicable when isolating applications in a multi-cloud environment if required.
Figure 3: Design Pattern 2 – Inter-Cloud Segmentation
In the above diagram, we have multiple VPCs which are part of different CSPs and are part of different segments.
Design Pattern 3: OnPrem to Cloud Segmentation
If the enterprise organization has an on-prem environment where they have created multiple VRFs, whether SD-WAN or legacy MPLS, those same VRFs can be extended to the cloud by creating the relevant segments, and end-to-end isolation can be maintained for the workloads using this design pattern.
Figure 4: Design Pattern 3 – OnPrem to Cloud Segmentation
The above diagram highlights how different VRFs in an on-prem environment can be extended to the cloud side.
Alkira CXP Segmentation Configuration Example
Figure 5-6: Alkira CXP Segmentation Configuration Example
A single segment with multiple groups is shown in the above UI view. The segment is highlighted by the purple color lines for different connectors.
Micro-Segmentation Design Patterns
Alkira’s approach to micro-segmentation centers around the concept of groups which enable the further subdivision of segments into discrete policy domains. Groups pool together a collection of connectors requiring everyday policy handling. Using Alkira’s intent-based policy, administrators can now implement granular control of intra-segment traffic based on 6-tuple and application-based traffic identification and enforcement.
The intra-segment policy can be supplemented with third-party security services available through the Alkira Network Services Marketplace. Groups can be mapped to an auto-scaling set of the next-generation cloud firewalls hosted within the Alkira Cloud Exchange Points, allowing administrators to deploy consistent security policies across the environment. Alkira’s solution makes sure to symmetrically route the traffic across the firewalls in single-region, multi-region, and multi-cloud scenarios.
Design Pattern 1 – Micro-segmentation in the same CSP
In this design pattern, if an enterprise organization has workloads for the prod and the dev environment, but they are part of the same business unit and want to keep those isolated, this can be achieved by creating groups and onboarding the relevant VPCs to the required group.
Figure 7: Design Pattern 1 – Micro-segmentation in the same CSP
In the above diagram, we have two VPCs in a single CSP which are part of the same segment but part of two different groups; hence traffic can be isolated between these two VPCs if required.
Design Pattern 2 – Micro-segmentation across different CSPs
Suppose the enterprise has a business unit whose workloads are present in multiple CSPs. In that case, they can isolate those across CSPs by creating groups and onboarding the VPCs in different CSPs to those relevant groups.
Figure 8: Design Pattern 2 – Micro-segmentation across different CSPs
The above diagram shows multiple VPCs across multiple CSPs, part of the same segment but different groups. The traffic is isolated between the CSPs.
Alkira CXP Micro-Segmentation Configuration Example
Figure 9-10: Alkira CXP Micro-Segmentation Configuration Example
The Alkira CXP Portal figures show multiple segments with multiple groups in the above UI view. The segment is highlighted by the green and purple color lines for different connectors, and each connector is part of the same or other groups.
An Enterprise customer could have multiple segments for business or security purposes, where different LOB (Lines of Business) is carved out as separate segments. This allows customers to achieve segmentation and isolation between each segment.
However, as companies adopt segmentation, they also desire to share resources across these segments. Resource Sharing is otherwise known as Inter-Segment routing. Resources essentially constitute Network Prefixes. Segment BLACK can communicate with other segments in the resource sharing, i.e., GREEN and YELLOW, and exchange the relevant network prefixes.
Figure 11: Resource Sharing