Phase 5: Advanced & Multi-Cloud

Custom lenses for SaaS, serverless & industry-specific workloads

Advanced ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you have a fantastic big cookbook at home. It’s full of great advice for almost any meal: how to make sure your food is cooked safely, how to keep your kitchen clean, how to cook efficiently so you don't waste energy, and how to get the most flavor out of your ingredients. This cookbook is super helpful for making everyday dinners, family breakfasts, or even a simple birthday cake. In the world of online services, we have something similar called the Well-Architected Framework – our big, general cookbook for building great software and systems.

But what if you're not making an everyday meal? What if you're trying to bake a huge wedding cake, or prepare a gourmet meal for a guest with specific allergies, or run a super-fast snack bar that only makes food the second someone orders? Your general cookbook might not have all the super specific tips you need. It won't tell you how to perfectly stack cake layers, avoid cross-contamination for allergies, or get a hot snack ready in under a minute without wasting ingredients. These special cooking challenges need more specific guidance.

That's where "custom lenses" come in. Think of a custom lens as a special, extra cookbook that you use alongside your big general one. For example, if you're building an online game where lots of different players share the same powerful computer system but need their own private game saves and unique characters (what we call SaaS, or Software as a Service), you'd pull out your "Multi-Player Game Catering Cookbook." This special book would have extra questions like "How do we make sure Player A's game saves never get mixed up with Player B's?" or "How do we charge each player fairly?" Or, if you're making a super-fast online tool that only does its job when someone clicks a button and then immediately stops (a serverless setup), you'd use your "Instant Snack Prep Guide." It would focus on questions like "How can we make this tool wake up and do its job in a blink?" and "How do we make sure it doesn't cost money when nobody's using it?"

So, when someone is designing a very specialized online system, they don't just use the general advice. They combine it with the expert guidance from these custom lens cookbooks. This means they can build incredibly clever and efficient online tools, making sure that everything from a personalized app used by thousands of people to a lightning-fast data processing service is perfectly designed for its unique purpose, safe, and ready for anything.

The Well-Architected Framework provides a robust, general set of best practices across key pillars like operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. However, for specialized workloads such as multi-tenant Software-as-a-Service (SaaS) platforms, highly dynamic serverless applications, or those operating in regulated industries, the standard framework might not delve deep enough into their unique challenges and requirements. This is where "custom lenses" come into play. A custom lens extends the core Well-Architected Framework by introducing additional questions, best practices, and architectural guidance specifically tailored to the nuances of these distinct environments, allowing for a far more granular and effective review and optimization process.

For SaaS applications, a custom lens would typically focus on aspects like tenant isolation and data segregation, billing and metering per tenant, upgrade strategies for multi-tenant environments, and the operational complexities of managing diverse customer needs on a shared infrastructure. For serverless workloads, the lens would shift focus to optimizing function invocation costs, managing cold starts, implementing robust distributed tracing for ephemeral functions, optimizing API Gateway design, and handling state management in an event-driven paradigm. These custom lenses ensure that reviews cover the unique operational, security, and cost considerations that are paramount for these specific architectural styles.

Similarly, industry-specific custom lenses are vital for sectors with stringent regulatory requirements. For instance, a healthcare lens might emphasize HIPAA compliance, data residency for patient records, and specific auditing requirements, while a financial services lens would prioritize PCI-DSS compliance, fraud detection patterns, and real-time transaction processing reliability. Implementing these custom lenses, often through policy-as-code or integrated into WAF review tools, allows organizations to move beyond generic best practices to achieve true architectural excellence and compliance relevant to their precise operational context, mitigating risks and unlocking specialized optimization opportunities that standard frameworks might overlook.

Key Takeaways

  • Standard WAF provides general best practices; custom lenses provide specialized, deeper guidance.
  • Essential for addressing unique challenges in SaaS (multi-tenancy, tenant isolation, billing), Serverless (cold starts, invocation costs, distributed tracing), and specific industries.
  • Enables more granular reviews, ensuring architecture aligns with workload-specific operational, security, and compliance needs.
  • Helps identify specific risks and optimization opportunities often missed by generic frameworks.
  • Can be implemented via codified policies (e.g., policy-as-code) or integrated into WAF review tools.

Code Example

yaml
# Example: Policy-as-Code for a "SaaS Multi-Tenancy Lens" in AWS Config Rule
# This rule checks if EC2 instances have a 'TenantId' tag, crucial for SaaS resource isolation and cost allocation.
Parameters:
  TenantIdTagKey:
    Type: String
    Default: TenantId
Resources:
  SaaSTenantTagCheck:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: SaaSTenantTaggingCompliance
      Description: "Checks if EC2 instances are tagged with the required TenantId key, enforcing a SaaS custom lens requirement."
      Scope:
        ComplianceResourceTypes:
          - AWS::EC2::Instance
      Source:
        Owner: AWS
        SourceIdentifier: REQUIRED_TAGS
        SourceDetails:
          - EventSource: aws.config
            MessageType: ConfigurationItemChangeNotification
            MaximumExecutionFrequency: TwentyFour_Hours
      InputParameters:
        tag1Key: !Ref TenantIdTagKey

How this code works

This code defines an AWS Config Rule aimed at enforcing a key requirement for SaaS multi-tenancy: ensuring every EC2 instance is tagged with a TenantId. This is vital for maintaining resource isolation and attributing costs correctly to specific customers. The rule essentially acts as an automated compliance check, continuously monitoring EC2 instances within a cloud environment to ensure they adhere to this crucial tagging standard.

The Parameters section defines TenantIdTagKey, allowing the specific tag name to be easily customized, defaulting to "TenantId". The Resources block then declares the SaaSTenantTagCheck, giving it a ConfigRuleName and Description. Its Scope limits the rule's application to AWS::EC2::Instance resources only. The Source specifies Owner: AWS and SourceIdentifier: REQUIRED_TAGS, which is a powerful, pre-built AWS managed rule that handles the logic for checking if specific tags exist. A subtle point is that the REQUIRED_TAGS rule expects the tag key to be passed as tag1Key in its InputParameters, so !Ref TenantIdTagKey dynamically inserts the chosen tenant ID tag name into the managed rule's expected format. This setup flags any EC2 instance missing the specified tag as non-compliant.

Related Articles

Hand-picked reads to go deeper on well-architected framework.

Back to Cloud Architect Roadmap