Software that isn’t “built for the cloud” can be lifted-and-shifted to run on the cloud in a virtual machine on EC2, or even in a Docker container…but what about if you want that software to run as a SaaS platform on AWS? You need to learn how to architect SaaS on AWS, or partner with an expert team like Ibexlabs.

You can’t lift-and-shift any old software, drop into onto the cloud, and call it SaaS. Moving to SaaS means transforming the software delivery model, which in turn means the software needs to be architected not just for the cloud, but specifically for SaaS.

With SaaS, customers are no longer just expecting you to ‌build the software features they need: now, they are expecting you to run it for them too:

  • Maintaining versions without breaking anything.
  • Keeping the software up and running, from bug fixes to scaling.
  • Keep my stuff isolated and protected from other tenants.
  • Making sure it’s secure, including customer data for SOC-2.

There’s a long list of operational responsibilities that have shifted from the customer to the vendor when SaaS is how software is delivered. How you meet those responsibilities starts with the way you architect for them.

In this article we’ll explore these important aspects of architecting SaaS on AWS:

  1. What the customer expects the vendor to own in SaaS.
  2. Well-architecting your SaaS.
  3. 14 General design principles for SaaS on AWS
  4. 6 Pillars of AWS SaaS Lense
  5. More resources

What the customer expects the vendor to own in SaaS

In layman’s terms, SaaS is a way for an online, digital and on-demand way for and ISV to deliver software to customers. It transforms the old way of buying and consuming software (us older folks remember getting compact disks and licenses in the post!).

This is best described by looking at the right hand side of the AWS Shared Responsibility Model. Now the ISV us sharing responsibility with AWS for nearly all of the stack. This is often why specialist ISVs work with AWS partners like Ibexlabs, to complement their software skills with AWS skills.

64abf8692a80e050abaa6a0c KSfuLYIwA2ZM80JAQoWQ92v lRnlldEkQ9BYPYq

✅ Ibexlabs is an approved AWS Well-Architected Framework practitioner and uses the SaaS Lens as part of their methodology, complemented by AWS skills and experience, to help ISVs to plan their future SaaS architecture.

14 general design principles for SaaS on AWS

The Well-Architected Framework SaaS Lens identifies a set of general design principles to facilitate good design in the cloud for SaaS applications. An experienced SaaS on AWS builder like Ibexlabs can help an ISV to (re-)architect their software around these design principles.

💥 Not all of these principles are related to technical software changes: they also cover non-functional operations and business models.

1. Adaptability is key 

There are often multiple options for each design consideration or well-architected pillar.

 Every SaaS setup is unique, shaped by business requirements, market segments, and compliance needs. The goal is to offer agility, customer experience, and efficiency within a single management pane, regardless of system design.

2. Break down services based on multi-tenant load and isolation

A SaaS solution is rarely a single monolith. For each component (e.g. AWS service), consider factors such as multi-tenant loads, tenant tiers, and isolation requirements when segmenting your system. Different services may handle data in different ways based on these factors.

3. Ensure tenant resource isolation

Protect against bad and noisy neighbors. A successful SaaS system must have a security model that prevents cross-tenant access, thus ensuring the safety of tenant resources across all architecture layers.

4. Plan for growth

Aim to grow in line with demand and shrink in times of churn. Design your SaaS environment to easily accommodate a growing number of tenants without expanding your operational or infrastructure footprint significantly.

5. Track and analyze tenant metrics

“See inside” your tenants’ behavior without breaking privacy and confidentiality. Invest in systems that can provide insights into tenant usage patterns, system loads, bottlenecks, and costs. These insights can inform your business and architectural strategy.

6. Standardize tenant onboarding

Automate as much as possible. Make the process of onboarding new tenants streamlined and repeatable to enable scalability and fast customer value realization.

7. Cater to diverse tenant experiences

Be wary of forking your SaaS into multiple versions. Be prepared to support varying tenant profiles, demands, and expectations without needing to create custom versions of your product. Feature and/or tenant flags can help.

8. Enable customization while maintaining efficiency

If customers request customizations, include them as configuration options for all customers, maintaining a single environment for all. It’s also technically possible to use feature flags to turn on “hidden” or special features for specific tenants, out-of-band of their in-tenant configuration settings.

9. Link user identity to tenant identity

Make sure shared components and services are operating on the correct tenant at all times. Ensure that tenant context is easily accessible across your application layers, tying user authentication and authorization to tenant identity.

10. Align resource consumption with tenant activity

Avoid over-provisioning by aligning infrastructure consumption with real-time tenant activity, which can significantly vary.

11. Limit developer exposure to multi-tenant concepts

Hide the details of tenancy from developers as much as possible by providing them with libraries and reusable constructs.

12. SaaS is about business strategy, not just technology

Design an architecture that fosters innovation, agility, and efficiency. A technically perfect architecture that lacks these attributes may not compete effectively in the SaaS marketplace.

13. Develop tenant-aware operational views

SaaS operations teams need to analyze and profile individual tenant activities. A robust SaaS operational setup provides insights into the usage patterns of specific tenants or tenant tiers.

14. Measure individual tenant cost impact

Understanding how individual tenants affect your SaaS environment’s cost footprint can provide valuable insights to shape your business model and architecture.

With these general SaaS design principles in mind, an AWS SaaS partner like Ibexlabs will guide an ISV through the well-architected framework process to come up with an action plan to build a robust SaaS solution on AWS. There are six stages – or pillars – in this process.

The 6 pillars of the AWS Well-Architected Framework – SaaS Lens

To build a robust SaaS platform on AWS, Ibexlabs uses this 6-pillar framework that provides helpful definitions, best practices, questions, considerations, and key AWS services that are relevant when architecting solutions for multi-tenant SaaS applications.

💡 These best practices are based on real-world AWS practitioner experience and provide a common language, perspective and process between the ISV, Ibexlabs and AWS.

1. Operational Excellence

A more detailed operational view of health is often essential to the success and growth of a SaaS business. Any outage or health issue has the potential of cascading across all the tenants of your system and taking a SaaS service down for all customers. This means that SaaS organizations must place a premium on creating an operational experience that will enable operations teams to effectively analyze and respond to the continually shifting workloads of a SaaS environment.

SaaS solutions are highly focused on maximizing agility and innovation. Tenant onboarding plays a key role in this agility story. By creating an architecture that promotes a frictionless, repeatable onboarding process, SaaS organizations are able to streamline, optimize, and scale their ability to introduce new tenants into their SaaS environment. This enables SaaS companies to support rapid growth and offer customers an experience that accelerates their overall time to value.

Read more about the AWS SaaS Lens – Operational Excellence Pillar.

2. Security

The move to a multi-tenant architecture often begins with identity. Each user that accesses your

application must be connected to a tenant. This binding of a user identity to a tenant is informally referred to as a SaaS identity. The key attribute of the SaaS identity is that it elevates tenant context to a first-class construct, connecting it directly to the overall authentication and authorization model of your SaaS application.

There are five best practice areas for security in the cloud:

  1. Identity and access management
  2. Detective controls
  3. Infrastructure protection
  4. Data protection
  5. Incident response

One of the most important security aspects of SaaS is the multi-tenant isolation model. This is explained in depth in the SaaS Lens, but the summary of concerns is:

  • Silo isolation – full stack isolation for some tenants.
  • Pool isolation – shared infrastructure for multiple tenants.
  • Bridge model – mixed model of full and shared.
  • Tier-based isolation – isolation mode is different in tiers (e.g. enterprise = full silo).
  • Targeted isolation – per service isolation mode (some are shared, some are dedicated).

Read more about the AWS SaaS Lens – Security Pillar.

3. Reliability

In a multi-tenant environment, you need to be especially proactive in your efforts to identify workloads and patterns of consumption that could impact the reliability of your system. Reliability issues in a multitenant environment can easily cascade through your system and, potentially, impact the experience of all of your customers.

Use limiting mechanisms like API throttling to protect tenants.

Read more about the AWS SaaS Lens – Reliability Pillar.

4. Performance Efficiency

The performance efficiency pillar focuses on the efficient use of computing resources to meet requirements and maintaining that efficiency as demand changes and technologies evolve.

Take a data-driven approach to selecting a high-performance architecture. Gather data on all aspects of the architecture, from the high-level design to the selection and configuration of resource types.

By reviewing your choices on a cyclical basis, you will ensure that you are taking advantage of the continually evolving AWS Cloud. Monitoring will ensure that you are aware of any deviance from expected performance and can take action on it. Finally, your architecture can make tradeoffs to improve performance, such as using compression or caching, or relaxing consistency requirements.

  • Selection (compute, storage, database, network)
  • Review
  • Monitoring
  • Tradeoffs

Read more about the AWS SaaS Lens – Performance Efficiency Pillar.

5. Cost optimization

The cost optimization pillar includes the continual process of refinement and improvement of a system over its entire lifecycle. From the initial design of your very first proof of concept to the ongoing operation of production workloads, adopting the practices in this paper will enable you to build and operate cost-aware systems that achieve business outcomes and minimize costs, thus allowing your business to maximize its return on investment.

There are four best practice areas for cost optimization in the cloud:

  • Cost-effective resources
  • Matching supply and demand
  • Expenditure awareness
  • Optimizing over time

Read more about the AWS SaaS Lens – Cost Optimization Pillar.

6. Sustainability

The sustainability pillar focuses on the long-term environmental impacts of SaaS products. The six architecture considerations in this pillar aim to reduce the sustainability impact of your cloud workload by maximizing utilization, and minimizing waste and the total resources deployed and powered to support your workload.

  1. Region selection
  2. User behavior patterns
  3. Software and architecture patterns
  4. Data patterns
  5. Hardware patterns
  6. Development and deployment patterns

Read more about the AWS SaaS Lens – Sustainability Pillar.