AWS Partner Network (APN) Blog
Architecting Successful SaaS: Interacting with Your SaaS Customer’s Cloud Accounts
Editor’s note: This is the second post in a series about SaaS strategies. Read Part 1 >>
By Gary Stafford, Partner Solutions Architect at AWS
You’re a software vendor selling a Software-as-a-Service (SaaS) product hosted on the cloud.
As part of your solution, the SaaS product needs to interact with customers’ cloud-based resources—data, applications, or perhaps even their compute resources.
As a vendor, you must architect your SaaS product—and its capability to interact with your customer’s cloud-based resources—to be scalable, reliable, performant, cost optimized, and, most importantly, secure.
In this post, I will explore several common Amazon Web Services (AWS) tools and architectural patterns used by SaaS vendors to interact with their customers’ cloud accounts. Although multi-cloud and hybrid cloud SaaS interactions are prevalent in many SaaS solutions, for brevity we’ll limit ourselves to interactions across accounts within AWS.
Reasons for Interaction
There are many reasons SaaS products need to interact with a customer’s AWS accounts. Examples of SaaS products requiring some level of account interaction often fall into the categories of logging and monitoring, security, compliance, data analytics, DevOps, workflow management, and resource optimization.
SaaS products, such as the ones in these categories, regularly interact with resources in the subscribing customer’s AWS account.
Examples of interactions include products that:
- Data analytics: Connects to private data sources within a customer’s cloud accounts.
- Logging and monitoring: Continuously aggregates, analyzes, and visualizes logs from a customer’s cloud accounts.
- Security: Uses machine learning (ML) and artificial intelligence (AI) to continuously scan a customer’s cloud accounts for suspicious activities.
- Workflow management: Remotely manages resources in a customer’s cloud account to optimize costs.
- Security: Intercepts and inspects traffic, in real-time, to and from a customer’s cloud-based applications, detecting fraud and other malicious activities.
- DevOps: Creates resources and deploys assets to a customer’s cloud accounts.
- Compliance: Continuously audits a customer’s cloud account activities for regulatory compliance and corporate governance violations.
Scaling Interactions
As individuals and businesses, we often interact and share resources between our own AWS accounts. We can delegate access across our accounts using AWS Single Sign-On (SSO) or AWS Identity and Access Management (IAM) roles, referred to as cross-account access.
A typical example is allowing a developer, an IAM user in the Development account, limited access to the Production account, to troubleshoot a customer issue. We can implement cross-account VPC sharing, within our AWS Organization, or VPC peering, to route traffic, privately, between two or more accounts.
We use these methods when applications, deployed to different AWS accounts, such as accounting and shipping, need to communicate with each other.
Figure 1 shows a typical example of an Enterprise AWS account structure, modeled around the software development lifecycle (SDLC), using good DevOps practices.
Figure 1 – Typical enterprise AWS account structure.
Cloud services and architectural patterns that work for an individual cloud customer may not scale for a SaaS vendor. Implementing a scalable and reliable architecture to interact with tens, hundreds, or thousands of a SaaS vendor’s customer accounts can be vastly more complex and challenging than implementing it across a single organization’s accounts, even those of a large organization.
Similarly, losing or exposing data can be devastating to an organization. Losing or exposing customer data is likely fatal to a SaaS vendor’s reputation and business.
Figure 2 shows a typical example of a SaaS vendor’s AWS account structure, modeled around a multi-tier pricing and support strategy. Free Trial and Business customers are pooled together using a multi-tenant architecture, while enterprise customers are isolated using a single-tenant architecture.
Figure 2 – Typical SaaS vendor account structure.
Tenancy Models
The tenant isolation strategy of a SaaS vendor can have a direct impact on the methods the vendor implements to integrate with their customer’s accounts. For those unfamiliar with the terms Tenancy Model or Tenant Isolation, think of housing.
A tenant (the SaaS vendor’s customer) might reside in a single-family house, referred to as a single-tenant architecture. In this model, a tenant is isolated or siloed from its neighbors (other SaaS customers).
Alternately, a tenant might reside in an apartment building, living adjacent to other tenants. This model is referred to as a multi-tenant architecture. Tenants (customers) share the same structure with limited isolation compared to a single-tenant architecture. In a multi-tenant architecture, customer resources are pooled.
Combining Tenancy Models
An application’s tenancy model is seldom binary. The degree to which the resources of a SaaS customer are isolated or pooled varies based on a vendor’s architecture. It’s also influenced by the underlying technologies used by the vendor.
Different tiers of the application—front-end, back-end, data—may differ in their degree and means of tenant isolation. For example, on AWS, isolation may be achieved at different levels of the network. A SaaS vendor may assign each customer to their own AWS account, providing a very high level of isolation.
Alternatively, a vendor might choose to use a single account and separate customers within their own virtual private cloud (VPC). Customers may be housed within the same VPC, but separated by compute instance or other software constructs.
Additionally, many SaaS vendors have more than one tenancy model. Frequently, a SaaS vendor will offer a multi-tier pricing structure. For example, a Business Tier, which is based on a shared, multi-tenant architecture; and an Enterprise Tier, which is based on an isolated, single-tenant architecture.
Vendors may also offer a free tier or trial offer, which is almost always multi-tenant.
The cloud services and architectural patterns used by vendors to integrate with customer accounts each have their own advantages and disadvantages. Some AWS services and architectural patterns may be inherently better at scaling to meet a SaaS vendor’s large growing customer base. They are well-suited for multi-tenant architecture.
Other services and architectural patterns may provide a high level of interaction but lack scalability. They may be better suited for a single-tenant architecture.
To learn more about tenancy, I recommend watching this AWS re:Invent 2019 presentation from Tod Golding of AWS: SaaS Tenant Isolation Patterns.
AWS Services
Several AWS services are capable of enabling integrations between a vendor’s SaaS product and their customer’s resources within their AWS accounts. Some AWS services were even designed with SaaS in mind, including AWS PrivateLink and Amazon EventBridge. Services with common architectural patterns are often combined.
In this section, I’ll summarize the main characteristics of these AWS services:
- Cross-account IAM roles
- AWS Transfer for SFTP
- Amazon S3 Access Points
- Amazon API Gateway
- VPC Peering
- VPC Endpoints
- AWS EventBridge
- JDBC and ODBC Database connections
Cross-Account IAM Roles
Customers can use an IAM role to delegate access to resources that are in different AWS accounts, often referred to as a cross-account role.
With IAM roles, you can establish trust relationships between your trusting account and other AWS trusted accounts. By setting up cross-account access in this way, you do not need to create redundant IAM users in each account.
Using External IDs in Cross-Account IAM Roles
Using external IDs is a good way to improve the security of cross-account role handling in a SaaS solution, and should be used by vendors who are implementing a SaaS product that uses cross-account roles. Choosing this option restricts access to the role only through the AWS Command Line Interface (CLI), Tools for Windows PowerShell, or the AWS API.
Using cross-account roles with external IDs, a SaaS customer gives their SaaS vendor programmatic access to their AWS account. The cross-account role’s policies tightly control the permissions of the vendor (trusted account) and limit access within the customer’s account (trusting account).
Vendors use cross-account access for many activities, including resource optimization, DevOps functions, patching and upgrades, and managing their agents.
AWS Transfer for SFTP
AWS Transfer for SFTP is a fully managed service that enables the transfer of files directly into and out of Amazon Simple Storage Service (Amazon S3) using the Secure File Transfer Protocol (SFTP)—also known as Secure Shell (SSH) File Transfer Protocol.
AWS SFTP is fully compatible with the SFTP standard, connects to your Active Directory, LDAP, and other identity systems, and works with Route 53 DNS routing.
Using Amazon S3 to transfer objects (files) between a SaaS vendor’s account and its customer’s accounts is very common. You can use multiple AWS services, including AWS Transfer for SFTP, to interact with a customer’s account using Amazon S3. A vendor may choose to pull from or push to the customer’s S3 bucket using one of these services. Alternately, a customer might push to or pull from a vendor’s S3 bucket, as shown in Figure 3.
To use AWS Transfer for SFTP, you set up users and assign them each an IAM role. This role determines the level of access that they have to your S3 bucket. When you create an SFTP user, you make several decisions about user access. These include which S3 buckets the user can access, what portions of each S3 bucket are accessible, and what privileges the user has; for example, PUT or GET.
Figure 3 shows an example of a SaaS vendor exposing a secure FTP site, backed by Amazon S3. The SaaS customers use SFTP to exchange data between their account and their SaaS application. File transfer may be managed by the customer or by a vendor agent, deployed into the customer’s account.
Figure 3 – SaaS vendor exposing a secure FTP site to its customers.
In April 2020, AWS announced AWS Transfer Family, which is the aggregated name of AWS Transfer for SFTP, FTPS, and FTP. In addition to Secure File Transfer Protocol (SFTP), AWS announced the expansion of the service to add support for File Transfer Protocol over SSL (FTPS) and File Transfer Protocol (FTP).
Amazon S3 Access Points
Amazon S3 Access Points simplify managing data access at scale for applications using shared data sets on S3. Access Points are unique hostnames that customers create to enforce distinct permissions and network controls for any request made through the access point.
Access Points can easily scale access for hundreds of applications by creating individualized access points with names and permissions customized for each application.
Access Points support IAM resource policies that allow you to control the use of the access point by resource, user, or other conditions. For an application or user to be able to access objects through an access point, both the access point and the underlying bucket must permit the request.
Using an Access Point policy, you can enable another account to access objects within an S3 bucket. The access point policy gives you fine-grain control over which users and which permissions, such as to GET and PUT objects, are allowed.
Figure 4 shows an example of the SaaS vendor exposing an Amazon S3 Access Point. Its customers use the supplied access points to exchange data between their account and their SaaS application. The interchange of data may be managed by the customer or by a vendor agent, deployed into the customer’s account.
Figure 4 – SaaS vendor exposing an Amazon S3 Access Point.
Amazon API Gateway
Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. APIs act as the front door for applications to access data, business logic, or functionality from backend services.
Using Amazon API Gateway, you can create RESTful APIs and WebSocket APIs that enable real-time two-way communication applications. Amazon API Gateway supports containerized and serverless workloads, as well as web applications.
Amazon API Gateway and its accompanying APIs serve as a scalable, reliable, performant, and secure connection to backend resources in either the customer’s or the SaaS vendor’s account.
Its backend resources include AWS Lambda functions, HTTP endpoints, VPC Links, and other AWS services. Those AWS services include Amazon Simple Queue Service (SQS) and Amazon Kinesis. These services are often used to exchange data between a SaaS vendor account and its customer accounts.
Eric Johnson of AWS gave an informative presentation on Amazon API Gateway at re:Invent 2019 called I Didn’t Know Amazon API Gateway Did That.
When using Amazon API Gateway, you can take advantage of several security features to secure communications between the vendor and customer accounts. These include encrypting transmitted data using SSL/TLS Certificates (HTTPS), AWS WAF integration, Client Certificates to ensure HTTP requests to your backend services are originating from Amazon API Gateway, Authorization using Amazon Cognito User Pools or a Lambda function, API Keys, and VPC Links.
Figure 5 shows an example of the SaaS vendor exposing an API, backed by an SQS queue. The customers use the API to programmatically exchange data between their account and SaaS application. The interchange of data may be managed by the customer or by a vendor agent, deployed into the customer’s account.
Figure 5 – SaaS vendor exposing an API backed by an Amazon SQS queue.
VPC Peering
Amazon Virtual Private Cloud (Amazon VPC) enables customers to launch AWS resources into a virtual network they have defined. A VPC peering connection is a networking connection between two VPCs that allows you to route traffic between them using private IPv4 addresses or IPv6 addresses.
You can create a VPC peering connection between your VPCs, or with a VPC in another AWS account. VPCs can be in different regions, known as inter-region VPC peering.
Figure 6 shows an example of the SaaS vendor and customer using VPC peering to enable direct interaction between an application within the customer’s account, and their SaaS application in the vendor’s account.
Figure 6 – Example of VPC Peering.
One of the limitations of VPC Peering, which may impact its ability to scale for SaaS vendors using multi-tenant architectures, is overlapping Classless Inter Domain Routing (CIDR) blocks.
You cannot create a VPC peering connection between VPCs with matching or overlapping IPv4 CIDR blocks. Given tens or hundreds of customers, VPC peering presents challenges in managing individual CIDR blocks when using a multi-tenant SaaS architectural approach.
VPC Endpoints
VPC endpoints enable you to privately connect your VPC to supported AWS services and VPC endpoint services powered by AWS PrivateLink, without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the AWS network.
There are two types of VPC endpoints. An interface endpoint, powered by AWS PrivateLink, is an elastic network interface (ENI) with a private IP address. This private IP address comes from the IP address range of your subnet, and serves as an entry point for traffic destined to a supported service. Interface endpoints support a large and growing list of AWS services.
The second type of VPC endpoint is a gateway endpoint, which you specify as a target for a route in your route table for traffic destined to a supported AWS service. Both Amazon S3 and Amazon DynamoDB are currently supported by gateway endpoints.
AWS PrivateLink simplifies the security of data shared with cloud-based applications by eliminating the exposure of data to the public Internet. AWS PrivateLink provides secure private connectivity between VPCs, AWS services, and on-premises applications on the AWS network.
AWS PrivateLink makes it easy to connect services across different accounts and VPCs to simplify the network architecture significantly. James Devine of AWS delivered an informative presentation on AWS PrivateLink at re:Invent 2018 called Best Practices for AWS PrivateLink.
Figure 7 shows an example of routing API calls from the customer account to the SaaS vendor account, using an interface VPC endpoint (interface endpoint) powered by AWS PrivateLink. The customer’s requests are sent through ENIs in each private subnet to a Network Load Balancer (NLB) within the vendor’s account, using AWS PrivateLink. There is no need for an Internet Gateway to route traffic over the public Internet.
Figure 7 – Using an interface VPC endpoint to route API calls.
You can see in Figure 8 an example of routing messages in real-time from an application within the customer’s account to an Amazon Kinesis Data Firehose delivery stream in the SaaS vendor’s account, using an interface endpoint powered by AWS PrivateLink.
Again, there’s no need for an internet gateway to route traffic over the public internet. The interchange of data may be managed by the customer or by a vendor agent, deployed into the customer’s account.
Figure 8 – Routing messages in near real-time.
Amazon EventBridge
Amazon EventBridge is a serverless event bus that makes it easy to connect applications using data from your applications, integrated SaaS applications, and AWS services. EventBridge delivers a stream of near real-time data from event sources and routes that data to targets like AWS Lambda.
You can set up routing rules to determine where to send your data to build application architectures that react in real-time to all of your data sources. EventBridge makes it easy to build event-driven applications because it takes care of event ingestion and delivery, security, authorization, and error handling for you.
Mike Deck of AWS gave an informative presentation on EventBridge at re:Invent 2019 called Building Event-Driven Architectures with Amazon EventBridge.
Amazon EventBridge SaaS Integrations
Amazon EventBridge ingests data from supported SaaS partners and routes it to AWS service targets. With EventBridge, you can use data from your SaaS applications to trigger workflows for customer support, business operations, and more.
As show in Figure 9, currently-supported SaaS partners include Auth0, Datadog, Epsagon, MongoDB, New Relic, and PagerDuty, among others.
Figure 9 – SaaS partners currently supported by Amazon EventBridge.
Below, Figure 10 shows an example of routing custom events from the SaaS vendor’s account to multiple targets within the customer’s account using Amazon EventBridge.
We can also use interface endpoints powered by AWS PrivateLink within both accounts to eliminate the need to send data over the public Internet. Traffic to targets of EventBridge also remains on the AWS global infrastructure.
Figure 10 – Routing custom events.
JDBC and ODBC Database Connections
Lastly, for data sources on AWS, vendors can interact with their customer’s AWS accounts using Java Database Connectivity (JDBC) and Open Database Connectivity (ODBC) database connections.
Services such as Amazon Redshift, Amazon Athena, Amazon Relational Database Service (Amazon RDS), and Amazon Aurora can all be accessed using one or both of these two methods.
There are multiple ways to enhance the security of the connections, including SSL/TLS connections, data encryption at rest and in flight, AWS IAM service-linked roles, VPCs, and VPC peering.
Figure 11 shows an example of the application in the SaaS vendor’s account communicating over JDBC, with a private Amazon RDS instance in the customer’s account. We can communicate between private subnets, within two different accounts using VPC Peering.
Like AWS PrivateLink, traffic stays on the global AWS backbone, and never traverses the public Internet.
Figure 11 – Application communicating over JDBC with a private Amazon RDS instance.
Conclusion
Your SaaS product needs to interact with the cloud resources of your customers. This post, the second in a series about architecting successful SaaS solutions, describes the pros and cons of using different AWS services to make that connection.
We examined several AWS services that help SaaS vendors interact with customers’ accounts. In future posts, I will take a more in-depth look at the advantages and disadvantages of each service with respect to their scalability and a vendor’s tenant isolation strategy.
Be sure to read the first post in my series called Understanding Cloud-Based SaaS Models.
To learn more about SaaS on AWS, check out these resources: