The Architecture Patterns AWS Expects for SaaS Competency

Introduction: The Difference Between SaaS on AWS and AWS SaaS Competency

There is a meaningful distinction that many ISVs miss when they first learn about the AWS SaaS Competency. Running a software product on AWS infrastructure does not automatically qualify it for SaaS Competency validation. The Competency is not validating that your software runs on AWS. It is validating that your software is built as SaaS in the way AWS defines that term architecturally.

AWS has a detailed and specific view of what production-grade SaaS architecture looks like. That view is codified in the AWS SaaS Factory program's guidance, the AWS Well-Architected SaaS Lens, and the specific validation criteria that reviewers apply during the SaaS Competency assessment.

The architecture patterns AWS expects reflect years of work with hundreds of SaaS companies at every stage of maturity. They are not arbitrary standards. They reflect the architectural decisions that separate SaaS products that scale reliably, operate economically, and maintain tenant security from those that encounter fundamental problems as they grow.

This post breaks down the core architecture patterns that reviewers assess, explains why each one matters, and identifies where ISVs most commonly fall short of the Competency standard.

Pattern One: Purpose-Built Multi-Tenancy

The most foundational architectural pattern in the AWS SaaS Competency is multi-tenancy, and it is also the area where the most significant gaps appear between ISV claims and reviewer findings.

AWS distinguishes between several approaches to multi-tenancy, and the Competency assessment looks carefully at which approach your architecture uses and whether it is genuinely designed for multi-tenant operation or is a single-tenant architecture that happens to serve multiple customers.

Silo model multi-tenancy deploys separate infrastructure for each tenant. Each customer has their own compute instances, databases, networking, and storage. Isolation is strong because tenant environments are physically separate. This model is appropriate for specific use cases, particularly those with strict compliance requirements that mandate dedicated infrastructure, but it is operationally expensive and does not scale economically as tenant count grows.

Bridge model multi-tenancy uses shared compute infrastructure but maintains separate storage for each tenant. Compute is pooled across tenants but data is isolated at the storage layer through separate database instances or schemas. This model provides better resource utilization than the silo model while maintaining strong data isolation.

Pool model multi-tenancy shares both compute and storage infrastructure across tenants, with isolation enforced through application logic and data partitioning strategies. This model provides the best resource utilization and the most economics of scale but requires the most sophisticated isolation implementation to maintain tenant security.

The Competency review does not mandate a specific multi-tenancy model. It assesses whether the model your architecture uses is appropriate for your use case, consistently implemented across your full stack, and genuinely enforced rather than aspirationally described.

The failure patterns reviewers encounter most frequently include architectures where multi-tenancy was added to a previously single-tenant system without a consistent strategy, resulting in mixed approaches across different parts of the stack. A product where the compute layer uses pool model multi-tenancy but the data layer uses per-tenant databases without a clear strategy for why that combination was chosen raises questions about architectural coherence.

Pattern Two: Tenant Isolation Enforcement

Tenant isolation is the property that prevents one tenant's actions from affecting another tenant's data, resources, or service experience. It is a non-negotiable requirement for production-grade SaaS, and its implementation is one of the most carefully assessed areas in the SaaS Competency review.

AWS expects tenant isolation to be enforced at multiple layers of the architecture, not just at the application logic layer. Relying entirely on application code to prevent tenant data leakage is considered insufficient because application code vulnerabilities can create isolation failures. Architectural isolation provides defense in depth that application logic alone cannot.

The AWS-native mechanism for enforcing tenant isolation at the infrastructure layer is IAM. The pattern involves generating tenant-scoped IAM credentials or policies that limit each tenant's access to only their own resources. When implemented correctly, even if application code contains a bug that would otherwise allow cross-tenant data access, the IAM boundary prevents the access from succeeding.

Reviewers assess whether IAM-based tenant isolation is implemented consistently across your resource types, whether tenant context is propagated correctly through your application stack so that IAM policies can be applied at the appropriate points, and whether the isolation mechanism has been tested to confirm that cross-tenant access is genuinely prevented.

Additional isolation patterns that reviewers look for include network-level isolation through VPC and security group configuration that prevents direct network communication between tenant resources in silo or bridge deployments, encryption key isolation through separate KMS keys or key policies for tenant data in pool deployments, and storage-level isolation through bucket policies, table conditions, or schema-level access controls depending on the storage services used.

The documentation requirement for tenant isolation is significant. Reviewers expect not just that isolation is implemented but that it is documented clearly enough that the implementation can be understood, audited, and verified by someone who did not build it.

Pattern Three: Automated Tenant Onboarding

The automation of tenant onboarding is a key operational excellence pattern in the SaaS Competency because it reflects the scalability of the SaaS operation, not just the technology.

A SaaS product that requires significant manual steps to onboard a new tenant has a fundamental operational constraint that limits its ability to scale. As the customer base grows, the cost and time to onboard new tenants becomes a bottleneck. Manual onboarding also introduces variability and error risk that automated onboarding eliminates.

AWS expects tenant onboarding to be fully automated, from the moment a new tenant is provisioned through to the point at which the tenant has a functional, isolated environment and their users can begin using the product. The automation should cover resource provisioning, configuration, isolation setup, initial data structure creation, and any integration or customization that the tenant's service tier requires.

The specific AWS services most commonly used in automated onboarding workflows include AWS CloudFormation or CDK for infrastructure provisioning, AWS Step Functions for orchestrating multi-step onboarding workflows, Amazon EventBridge for triggering onboarding processes from provisioning events, and Amazon Cognito for user pool setup and identity configuration.

Reviewers assess whether the onboarding automation is idempotent, meaning it can be run multiple times without creating duplicate or conflicting resources, and whether it includes appropriate error handling and rollback capabilities for cases where onboarding fails partway through. An onboarding process that leaves orphaned resources or partially configured tenant environments when it fails is a reliability risk.

The time to onboard a new tenant is also assessed qualitatively. An automated onboarding process that takes several hours due to sequential dependencies or polling loops is technically automated but architecturally inefficient. Reviewers look for designs that minimize onboarding time through parallelization and event-driven triggering rather than sequential execution.

Pattern Four: Tiering Reflected in Architecture

Most SaaS products offer multiple service tiers with different feature sets, usage limits, and performance characteristics. The AWS SaaS Competency assesses whether those tiers are reflected in the architecture of the system, not just in the business logic and pricing page.

The concept of tier-aware architecture means that the infrastructure, resource allocation, and operational behavior of the system vary meaningfully based on the tenant's service tier. This is a more demanding standard than having application code that checks the tenant's tier before allowing access to premium features.

A basic tier architecture pattern might route tenants to shared, lower-performance infrastructure while premium tier tenants run on dedicated or higher-performance resources. A standard tier might have per-tenant usage limits enforced at the infrastructure level through IAM policies or service quotas, while premium tiers have higher or unlimited allocations. Operational responses to incidents might differentiate by tier, with premium tier tenants receiving faster response SLAs backed by dedicated monitoring and alerting.

The purpose of tier-aware architecture is to ensure that the economics of the SaaS product are architecturally sound. A SaaS product where basic tier customers consume the same infrastructure resources as premium tier customers has a unit economics problem that becomes more acute as the customer base grows. Tier-aware architecture ensures that the cost to serve each tier is proportional to the revenue that tier generates.

Reviewers assess whether tiering is implemented consistently across the architecture, whether the tier boundaries are technically enforced rather than just logically described, and whether the architecture can accommodate adding new tiers or modifying existing tier boundaries without requiring fundamental redesign.

Pattern Five: Tenant-Level Observability

Standard infrastructure monitoring tells you whether the system is healthy in aggregate. Tenant-level observability tells you which tenants are experiencing problems, which tenants are consuming disproportionate resources, and how the system behaves for any individual tenant at any point in time.

The AWS SaaS Competency requires tenant-level observability because it is foundational to operating a SaaS product at scale. Without the ability to answer the question of what is happening for a specific tenant, diagnosing customer-reported issues requires broad investigation rather than targeted analysis, and the operational cost of supporting customers grows with tenant count rather than remaining manageable.

The implementation pattern involves propagating a tenant identifier through every layer of the application stack and including that identifier in all log entries, metrics, and traces. When every CloudWatch log entry and metric includes the tenant ID, you can filter and aggregate observability data by tenant to understand what any individual customer is experiencing.

AWS X-Ray or equivalent distributed tracing with tenant context propagation is the mechanism most commonly used for end-to-end tenant visibility in complex architectures with multiple microservices. Reviewers look for whether tenant context flows correctly through asynchronous processing pipelines, background jobs, and third-party integrations, not just through synchronous API request paths.

Tenant-level cost attribution is a related pattern that reviewers assess in more mature SaaS architectures. The ability to understand what it costs to serve each tenant, broken down by service tier and usage patterns, is foundational to SaaS unit economics management. AWS tagging strategies combined with AWS Cost Explorer provide the mechanism for this, but the tagging needs to be consistently applied across all tenant-associated resources.

Pattern Six: Control Plane and Data Plane Separation

One of the more architecturally sophisticated patterns that the SaaS Competency assesses is the separation of the control plane from the data plane in the SaaS architecture.

The control plane encompasses the administrative functions of the SaaS system: tenant provisioning and onboarding, billing and subscription management, user management, policy enforcement, and operational tooling. The data plane encompasses the customer-facing application functionality that tenants use to derive value from the product.

Separating these two planes provides several important architectural benefits. It allows the control plane and data plane to scale independently, which is important because control plane operations are typically low-frequency administrative actions while data plane operations are high-frequency customer-facing requests. It isolates control plane failures from data plane availability, so administrative system problems do not affect customer-facing service. And it provides a clear architectural boundary that makes it easier to reason about the security implications of each plane.

Reviewers assess whether this separation exists in the architecture, how clearly the boundary between control and data plane is defined and enforced, and whether the operational tooling for managing the SaaS platform is built on the control plane rather than directly accessing data plane resources.

ISVs that have grown their architecture organically without deliberate plane separation often find that administrative and customer-facing functionality is deeply intertwined in ways that are difficult to separate retroactively. Identifying this gap early and planning the separation as a structured refactoring effort is preferable to discovering it during the review.

Where ISVs Most Commonly Fall Short

The most frequent gap in SaaS Competency candidates is tenant isolation implementation. Many ISVs have multi-tenancy in their application logic but have not implemented the IAM-based or infrastructure-level isolation that AWS expects. This is both a security finding and an architectural finding that requires significant work to remediate.

The second most common gap is tenant-level observability. Infrastructure monitoring is typically present but tenant context is not propagated through the logging and metrics infrastructure, making it impossible to answer the question of what a specific tenant is experiencing.

The third gap is onboarding automation completeness. Many ISVs have automated the happy path of tenant onboarding but have not invested in error handling, rollback, and idempotency that make the automation reliable in failure scenarios.

Building Toward the Competency Standard

The most effective preparation path for the SaaS Competency is a systematic review of your architecture against the AWS SaaS Factory guidance, which provides detailed recommendations on each of the patterns above with AWS-specific implementation examples.

Engage your AWS Partner Development Manager early in the preparation process. AWS SaaS Factory team members can provide architectural guidance and pre-review assessments that identify gaps before the formal review.

Prioritize the tenant isolation and observability gaps because they tend to require the most significant architectural investment and have the longest implementation timelines. Onboarding automation and tiering improvements can often be addressed in parallel once the foundational patterns are in place.

The Strategic Takeaway

The AWS SaaS Competency is a rigorous architectural assessment that validates whether your SaaS product is built the way AWS expects production-grade SaaS to be built. The patterns it assesses, multi-tenancy, tenant isolation, automated onboarding, tier-aware architecture, tenant observability, and control plane separation, are not arbitrary requirements. They are the architectural foundations of a SaaS product that can scale reliably, operate economically, and maintain the security guarantees that enterprise customers require.

ISVs who build toward these patterns are not just preparing for a Competency review. They are building a more scalable, more operable, and more trustworthy product. The Competency is the validation of work that is worth doing regardless of whether the review existed.