By Tod Golding, Partner Solutions Architect at AWS

Networking is an area that doesn’t always jump out as a hot topic for teams designing and building software-as-a-service (SaaS) solutions. Instead, networking is often viewed as a foundational element of a system’s architecture.

The reality is there are plenty of scenarios where the networking footprint of a SaaS application can influence the functionality, extensibility, and management profile of your SaaS environment.

While there are plenty of creative ways developers leverage Amazon Web Service (AWS) networking constructs to refine SaaS solutions, the introduction of AWS PrivateLink adds new opportunities in the SaaS networking landscape. PrivateLink equips architects with a seamless experience for integrating with SaaS environments, enabling a new model and mindset to expose secure entry points into SaaS applications.

In this post, I will dig into the specifics of the PrivateLink model and identify areas where PrivateLink has the potential to impact the architecture, integration model, and compliance footprint of your SaaS solution.

The AWS PrivateLink Story

To understand the value proposition of AWS PrivateLink, we must first start by examining some of the fundamentals that influenced its introduction. Let’s look at a common network configuration for applications that are running on AWS. Figure 1

Figure 1 – Accessing AWS services with the Internet Gateway or VPC endpoints.

This example represents a common scenario where your application services may require access to an AWS managed service (in this example, Amazon Simple Storage Service, or Amazon S3). AWS provides two paths to these services.

Traditionally, to access Amazon S3 from within a VPC, you have to pass through an Internet gateway to get to Amazon S3 since it wasn’t part of your VPC. The need to pass through the Internet to access AWS services was less than ideal and, ultimately, led to the introduction of VPC endpoints that allow you to connect to a service like Amazon S3 from your VPC without leaving the AWS network.

The diagram in Figure 1 illustrates both of these access scenarios. Along the top, you’ll see where our VPC router is sending traffic through the Internet Gateway to the internet. From there, you can access Amazon S3. The alternate path here (at the bottom of the diagram) illustrates the use of a VPC endpoint. With the VPC endpoint exposed by Amazon S3, the service can interact directly with Amazon S3 service without leaving the AWS network.

Taking VPC Endpoints to the Next Level

Endpoints solved an important problem for AWS developers. They also exposed developers to an integration model that opened the door to a whole new set of possibilities. With endpoints, developers saw the value of exposing and accessing services in a more seamless model. It was only natural they would see the power of this construct and begin to wonder how they could leverage this same mechanism to enable access to their own services.

If developers could somehow create entry points into their own VPCs using the endpoint model, they would be able to support new strategies for safely exposing application services within their environments.

This, of course, is precisely the mindset that drove the introduction of what is now known as AWS PrivateLink. This networking construct is focused on extending the capabilities of VPC endpoints, allowing developers to expose native services via VPC endpoints. Figure 2 provides a high-level view of a sample PrivateLink implementation.

Figure 2 – Exposing native services via VPC endpoints.

You’ll notice that in Figure 2 we have a SaaS solution hosted in its own VPC on the right-hand side of the diagram. Within this VPC, the SaaS provider hosts a range of services that implement various features and logic of the provider’s SaaS solution.

Let’s presume, for this example, that these services include functionality the provider would like to make available to consumers that are running in their own VPCs (often other businesses). While they’d like to expose these services, they’d like to achieve this without relying on a public interface. Instead, they’d prefer all the traffic remain within the confines of the AWS networking infrastructure. This is equally important to SaaS consumers that prefer to integrate with SaaS providers without requiring their traffic to cross the public internet.

This is now directly in the sweet spot of the problem PrivateLink solves. With PrivateLink, we can put a Network Load Balancer (NLB) in front of our services and attach a VPC endpoint to the load balancer. This configuration assigns a private IP address to the endpoint that can be accessed without touching the public network. In fact, these endpoints will appear as if they reside directly in the consumer VPC.

While PrivateLink has merits in any number of scenarios, it’s of particular interest to SaaS organizations. Through PrivateLink, SaaS providers see new and creative opportunities to use this networking construct to enhance and expand the architectural and business models of their solutions. The sections that follow highlight some of the common ways SaaS providers are employing PrivateLink in their offerings.

Enabling Third-Party Integrations

Many SaaS providers support integrations with third-party solutions that are also hosted on AWS. In many cases, SaaS providers are extending the capabilities and value proposition of their products through third-party integrations. Without PrivateLink, of course, tackling these integrations meant exposing a public network paths between these systems—even when they all reside with the same AWS infrastructure.

PrivateLink reduces the risk and efficiency of these integrations, providing a natural and more secure mechanism for connecting SaaS environments. In many respects, consuming the capabilities of another SaaS provider becomes like consuming other native services on the AWS network. In fact, a PrivateLink-based solution that has been vetted and published on AWS Marketplace can be whitelisted and appear in the console alongside other AWS services.

Figure 3 provides a high-level view of the integration model that SaaS providers might employ to enable third-party integrations.

Figure 3 – Using AWS PrivateLink to promote SaaS integration.

Here, we have examples of three separate SaaS integrations. The first SaaS provider on the left has used PrivateLink to create an integration with another SaaS solution (SaaS Solution 2). This provider has also relied on an integration of its own with yet another SaaS provider (SaaS solution 3).

On the surface, this may seem like a less than monumental achievement. Certainly, SaaS providers have been creating models for integration long before the introduction of PrivateLink. What’s new here is the idea that these integrations are being achieved without any reliance on public network exposure. They cross boundaries and integrate more seamlessly, benefiting from all the perks that come with staying in the confines of the AWS network infrastructure.

By relying on PrivateLink for integrations, these services inherit all the AWS-supported mechanisms for controlling and constraining the accessibility. SaaS providers can configure their endpoints to require consent from both parties before opening any connection between the parties. This added level of control is essential in multi-tenant SaaS environments where there is a premium on preventing any form of cross-tenant access to resources.

Frictionless Onboarding with AWS Marketplace

Once you have added PrivateLink support to your SaaS application, you’ll want to promote the availability of this option to prospects and customers. AWS Marketplace provides you with just such a vehicle. You can list your SaaS solutions on AWS Marketplace along with other SaaS providers, increasing your ability to promote this option and drive new and, potentially, unanticipated business relationships.

Through AWS Marketplace, you’ll be able to create a frictionless experience that will streamline the provisioning and configuration of PrivateLink integrations. In fact, SaaS providers that use PrivateLink can use their own DNS names to brand and simplify the naming of their endpoints. Learn more about PrivateLink on AWS Marketplace.

On-Premises Integration

Some SaaS providers rely on a hybrid delivery model, where portions of their applications are hosted on-premises. Implementing solutions of this nature can be challenging and undermine the agility of your SaaS architecture. The network constructs used to support this model can also add layers of complexity to your SaaS environment.

PrivateLink provides a new option that significantly reduces the complexity of these environments. Figure 4 illustrates how you can use PrivateLink to simplify the networking model of SaaS solutions that rely on a partial on-premises footprint.

Figure 4 – Using AWS PrivateLink to access services from on-premises environments.

You can see that our SaaS provider has a collection of services that are part of the provider application running on AWS. This could represent a scenario where you’ve only hosted a specific feature of your product in the cloud. Or, it could be that your system is in a transitional state where the services of your application are currently split between AWS and on-premises environments.

The beauty of this model is that PrivateLink makes integrations of this nature relatively straightforward. The services that are exposed in your AWS environment will be able to participate as first-class citizens in your on-premises environment, removing much of the complexity and streamlining the fundamentals of your integration.

Control Plane for Tenant VPCs

Some SaaS providers deliver solutions in what’s referred to as a silo model. In siloed environments, each SaaS tenant is provisioned and deployed into its own VPC with its own dedicated infrastructure stack. This model is often the byproduct of specific regulatory or domain considerations.

Managing and operating siloed environments can be particularly challenging. Ultimately, you’d like to have a single control plane that spans all the individual VPCs, providing a single operational and management experience for tenants. Some have addressed this issue through a combination of security groups, IP restrictions, and other measures that control the public accessibility of your VPCs.

Others have relied on VPC peering to address this need. However, this adds a layer of complexity to IP addressing schemes of tenant VPCs. Both strategies are valid; they simply require an added level of care and forethought.

As you can imagine, PrivateLink represents a compelling alternative for managing multi-VPC environments. Figure 5 provides a high-level view of how this control plane might be implemented with PrivateLink.

Figure 5 – Using AWS PrivateLink to build a multi-VPC control plane.

Here you’ll notice that we’ve introduced two VPCs on the right-hand side the diagram the represent the individual tenant VPCs. Now, to enable management and configuration of these tenant environments, we have created a separate VPC that hosts our management service (on the left-hand side). This management service uses PrivateLink to invoke management operations on each of the tenant VPC environments. It achieves all of this without leaving the AWS network, adding a layer of efficiency and control to the management profile of your environment.

This model certainly overcomes many of the challenges associated with VPC peering. It also tends to meet a higher security threshold than any of the mechanisms that rely on exposing public entry points to your VPCs.

Improving the Compliance Footprint

Compliance represents a significant challenge many SaaS providers—especially those relying on integrations or interactions that require them to interact with external environments. For these solutions, any attempt to move data across a public network path must be given careful scrutiny. To make this work, SaaS providers often employ a range of a security measures (keys, encryption, etc.) to satisfy the compliance requirements of their domain.

PrivateLink provides a natural fit for SaaS solutions that have a heavy compliance footprint. Since all the traffic that flows through a PrivateLink endpoint remains on the AWS network, this traffic inherits the security and compliance features that are already supported by AWS. This allows your solution to piggyback on the compliance models that are directly supported by AWS, such as PCI-DSS, HIPAA, GLBA, and FISMA.

These compliance considerations can add immediate value to the integrations you might create with other SaaS vendors. This added level of compliance and security can promote integrations with your product and, potentially, drive new integrations you may not have previously considered.

The Cost Model

As you consider the integration model for PrivateLink, you must also consider how you’ll manage cost as part of this experience. With PrivateLink, the cost of adding an endpoint to a solution is viewed as separate from the cost of enabling a new integration between a given consumer and your PrivateLink endpoint. Each separate connection that is made to a PrivateLink endpoint incurs its own cost.

This cost model raises interesting questions for SaaS providers. If, for example, the integration is requested by a SaaS tenant, these costs could be passed along directly to the tenant that has enabled the integration. There will also be scenarios where SaaS providers want to limit a tenant’s awareness of these costs. In this model, a SaaS provider would have to provision the connection using an account of their own and absorb this as part of their AWS costs.

The key here is that you should factor this cost model into your design. If you expect to make these costs transparent to you tenants, you’ll want to determine how this might influence your overall SaaS tiering and cost model.

One-Way Flow

In looking at the scenarios described above, you’ll notice that each of the diagrams represent the network flow as a one-way path into a PrivateLink enabled service. This is intentional and fundamental to achieving the goals of PrivateLink. However, it’s important to note that some integration patterns you may be considering could rely on a two-way integration model.

Getting Started

Hopefully, this post gives you a good sense of some of the key areas where AWS PrivateLink can influence the architecture and integration models of your SaaS solutions. The simplicity, security, performance, and compliance aspects of PrivateLink open up new models for discovering and integrating SaaS solutions on AWS.

For some, PrivateLink will solve fundamental integration and management problems. For others, it may also represent an opportunity to create a more appealing model for building integrations with other SaaS products that, previously, may not have been achievable.

About AWS SaaS Factory

AWS SaaS Factory provides AWS Partner Network (APN) Partners with resources that help accelerate and guide their adoption of a SaaS delivery model. SaaS Factory includes reference architectures for building SaaS solutions on AWS; Quick Starts that automate deployments for key workloads on AWS; and exclusive training opportunities for building a SaaS business on AWS.

APN Technology Partners who develop SaaS Solutions are encouraged to join the program!