Simplifying Microservices with SAM: Multi-Function Applications and Shared Layers

Simplifying Microservices with SAM: Multi-Function Applications and Shared Layers#

Building microservices on AWS Lambda can feel overwhelming when you’re juggling multiple functions, managing dependencies, and trying to keep code DRY across your application. The AWS Serverless Application Model, or SAM, makes this significantly easier—but only if you understand how to structure your application properly. In this article, we’ll explore how to organize multi-function serverless applications using SAM, leverage shared layers to reduce duplication, and scale your infrastructure without drowning in template complexity.

Whether you’re building an e-commerce backend, a content processing pipeline, or a real-time data system, these patterns will help you write cleaner, more maintainable serverless code that your team can actually understand and extend.

Understanding SAM as an Infrastructure-as-Code Framework#

Before diving into multi-function patterns, let’s ground ourselves in what makes SAM valuable. SAM is a framework that extends CloudFormation with serverless-specific resources and transforms. When you deploy a SAM template, the SAM CLI (or AWS services) expand your shorthand definitions into full CloudFormation templates behind the scenes. This abstraction matters because it lets you focus on what your serverless application does rather than getting tangled in the minutiae of role policies, environment variables, and permission configurations.

For a single-function application, SAM is already helpful. For a multi-function microservices backend, it becomes essential. Without SAM, you’d be writing dozens of lines of CloudFormation boilerplate for each function, repeating permission logic, and managing layer associations manually. SAM reduces that friction dramatically.

Structuring Multi-Function Applications in a Single Template#

Let’s start with a practical scenario: you’re building an e-commerce backend with three core functions. One handles orders, another processes payments, and a third manages inventory. All three need to call each other, log in a consistent way, and access shared utilities.

A SAM template for this might look like this:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2013-12-31
Description: E-commerce microservices backend

Globals:
  Function:
    Runtime: python3.11
    Timeout: 30
    Environment:
      Variables:
        LOG_LEVEL: INFO

Resources:
  OrderFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: ecommerce-order-function
      CodeUri: functions/order/
      Handler: app.lambda_handler
      Layers:
        - !Ref SharedLayer
      Environment:
        Variables:
          PAYMENT_FUNCTION_ARN: !GetAtt PaymentFunction.Arn
          INVENTORY_FUNCTION_ARN: !GetAtt InventoryFunction.Arn
      Policies:
        - Version: '2012-10-17'
          Statement:
            - Effect: Allow
              Action:
                - lambda:InvokeFunction
              Resource:
                - !GetAtt PaymentFunction.Arn
                - !GetAtt InventoryFunction.Arn
      Events:
        OrderAPI:
          Type: Api
          Properties:
            RestApiId: !Ref EcommerceApi
            Path: /orders
            Method: post

  PaymentFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: ecommerce-payment-function
      CodeUri: functions/payment/
      Handler: app.lambda_handler
      Layers:
        - !Ref SharedLayer
      Environment:
        Variables:
          INVENTORY_FUNCTION_ARN: !GetAtt InventoryFunction.Arn
      Policies:
        - Version: '2012-10-17'
          Statement:
            - Effect: Allow
              Action:
                - lambda:InvokeFunction
              Resource:
                - !GetAtt InventoryFunction.Arn

  InventoryFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: ecommerce-inventory-function
      CodeUri: functions/inventory/
      Handler: app.lambda_handler
      Layers:
        - !Ref SharedLayer

  SharedLayer:
    Type: AWS::Serverless::LayerVersion
    Properties:
      LayerName: ecommerce-shared-layer
      Description: Shared utilities and logging
      ContentUri: layers/shared/
      CompatibleRuntimes:
        - python3.11

  EcommerceApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
      TracingEnabled: true

Outputs:
  OrderFunctionArn:
    Description: ARN of the Order function
    Value: !GetAtt OrderFunction.Arn
    Export:
      Name: ecommerce-order-function-arn

  PaymentFunctionArn:
    Description: ARN of the Payment function
    Value: !GetAtt PaymentFunction.Arn
    Export:
      Name: ecommerce-payment-function-arn

  InventoryFunctionArn:
    Description: ARN of the Inventory function
    Value: !GetAtt InventoryFunction.Arn
    Export:
      Name: ecommerce-inventory-function-arn

  ApiEndpoint:
    Description: API Gateway endpoint
    Value: !Sub 'https://${EcommerceApi}.execute-api.${AWS::Region}.amazonaws.com/prod'

This template demonstrates several important patterns. Notice how each function is defined as its own AWS::Serverless::Function resource, each with a distinct CodeUri pointing to its own source directory. The Globals section at the top reduces repetition by setting runtime, timeout, and environment variables that apply to all functions unless overridden.

Layers are one of the most underutilized features in serverless development, yet they’re transformative for multi-function applications. A layer is essentially a packaged set of libraries or code that multiple functions can reference without duplicating the code in each function’s deployment package.

In our example, the SharedLayer resource points to layers/shared/, which might contain utilities like logging helpers, validation functions, or database connection logic. Here’s what that directory structure might look like:

layers/shared/
├── python/
│   └── shared_utils/
│       ├── __init__.py
│       ├── logging.py
│       ├── validators.py
│       └── database.py

The python/ directory is crucial—it’s how Lambda knows this is a Python layer. When you deploy this layer, Lambda packages it and makes the contents available to any function that references it. Inside your function code, you’d simply import from it:

from shared_utils.logging import get_logger
from shared_utils.validators import validate_order

logger = get_logger(__name__)

def lambda_handler(event, context):
    try:
        order_data = validate_order(event.get('body'))
        logger.info(f'Processing order: {order_data}')
        return {'statusCode': 200, 'body': 'Order received'}
    except ValueError as e:
        logger.error(f'Validation failed: {e}')
        return {'statusCode': 400, 'body': str(e)}

Layers keep your functions lean and focused, and they make maintenance easier because you update shared code in one place. If you have a bug in your validation logic, you fix it in the layer, redeploy, and all functions automatically benefit from the fix.

Using Outputs to Enable Cross-Function Invocation#

One challenge in microservices is that functions often need to invoke each other. The Order function might call the Payment function, which might call Inventory. How do they know where to find each other?

The answer is in the Outputs section of your SAM template. By exporting the ARN (Amazon Resource Name) of each function, you make that information available throughout your AWS account. In the template example above, we export the ARN of each function:

Outputs:
  OrderFunctionArn:
    Value: !GetAtt OrderFunction.Arn
    Export:
      Name: ecommerce-order-function-arn

Then, in the Order function’s environment variables, we inject these ARNs:

Environment:
  Variables:
    PAYMENT_FUNCTION_ARN: !GetAtt PaymentFunction.Arn
    INVENTORY_FUNCTION_ARN: !GetAtt InventoryFunction.Arn

Inside the Order function’s code, you’d retrieve these environment variables and invoke the other functions:

import json
import boto3
import os

lambda_client = boto3.client('lambda')

def lambda_handler(event, context):
    order = json.loads(event['body'])
    
    # Invoke the payment function
    payment_response = lambda_client.invoke(
        FunctionName=os.environ['PAYMENT_FUNCTION_ARN'],
        InvocationType='RequestResponse',
        Payload=json.dumps({
            'order_id': order['id'],
            'amount': order['amount']
        })
    )
    
    payment_result = json.loads(payment_response['Payload'].read())
    
    if payment_result.get('status') == 'success':
        # Invoke inventory function
        inventory_response = lambda_client.invoke(
            FunctionName=os.environ['INVENTORY_FUNCTION_ARN'],
            InvocationType='RequestResponse',
            Payload=json.dumps({
                'order_id': order['id'],
                'items': order['items']
            })
        )
        # Handle the response...
    
    return {'statusCode': 200, 'body': json.dumps(payment_result)}

Notice that we’re using InvocationType: RequestResponse, which means the Order function waits for the Payment function to complete before proceeding. This is synchronous invocation, useful when you need the result immediately. For fire-and-forget scenarios, you’d use InvocationType: Event instead.

Also important: the IAM policies allow each function to invoke only the functions it needs to call. The Order function has explicit permissions to invoke Payment and Inventory, but not vice versa. This principle of least privilege is a security best practice that SAM makes straightforward.

Managing IAM Policies for Cross-Function Communication#

When functions invoke each other, they need the appropriate IAM permissions. In the template above, each function that needs to invoke others has a Policies section granting the lambda:InvokeFunction action on specific function ARNs.

For larger applications, repetition in policies can become tedious. SAM offers a shorthand through managed policies and policy templates. For instance, you could use a simplified approach:

OrderFunction:
  Type: AWS::Serverless::Function
  Properties:
    FunctionName: ecommerce-order-function
    CodeUri: functions/order/
    Handler: app.lambda_handler
    Layers:
      - !Ref SharedLayer
    Policies:
      - LambdaInvokePolicy:
          FunctionName: !Ref PaymentFunction
      - LambdaInvokePolicy:
          FunctionName: !Ref InventoryFunction

The LambdaInvokePolicy is a SAM policy template that automatically creates the correct permissions without you needing to write the full IAM statement. SAM offers many such templates for common patterns, including S3CrudPolicy, DynamoDBCrudPolicy, and SQSPollerPolicy. These reduce boilerplate and make your templates more readable.

Splitting Large Templates with Nested Stacks#

As your microservices backend grows, a single SAM template can become unwieldy. A template with dozens of functions, multiple APIs, databases, and supporting resources becomes hard to navigate and reason about. This is where the nested stacks pattern comes in.

Nested stacks let you break a large template into logical pieces, each managing a subset of resources. You might have one template for your API layer, another for functions, another for databases, and so on. The parent template orchestrates everything.

Here’s how you’d restructure the e-commerce example using nested stacks:

Parent template (template.yaml):

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2013-12-31
Description: E-commerce microservices root stack

Resources:
  SharedLayer:
    Type: AWS::Serverless::LayerVersion
    Properties:
      LayerName: ecommerce-shared-layer
      ContentUri: layers/shared/
      CompatibleRuntimes:
        - python3.11

  ApiStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: stacks/api.yaml
      Parameters:
        SharedLayerArn: !GetAtt SharedLayer.LayerVersionArn

  FunctionsStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: stacks/functions.yaml
      Parameters:
        SharedLayerArn: !GetAtt SharedLayer.LayerVersionArn
        ApiId: !GetAtt ApiStack.Outputs.ApiId

Outputs:
  ApiEndpoint:
    Value: !GetAtt ApiStack.Outputs.ApiEndpoint

API Stack (stacks/api.yaml):

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2013-12-31

Parameters:
  SharedLayerArn:
    Type: String

Resources:
  EcommerceApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
      TracingEnabled: true

Outputs:
  ApiId:
    Value: !Ref EcommerceApi
  ApiEndpoint:
    Value: !Sub 'https://${EcommerceApi}.execute-api.${AWS::Region}.amazonaws.com/prod'

Functions Stack (stacks/functions.yaml):

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2013-12-31

Parameters:
  SharedLayerArn:
    Type: String
  ApiId:
    Type: String

Globals:
  Function:
    Runtime: python3.11
    Timeout: 30
    Layers:
      - !Ref SharedLayerArn

Resources:
  OrderFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: ecommerce-order-function
      CodeUri: functions/order/
      Handler: app.lambda_handler
      Environment:
        Variables:
          PAYMENT_FUNCTION_ARN: !GetAtt PaymentFunction.Arn
      Policies:
        - LambdaInvokePolicy:
            FunctionName: !Ref PaymentFunction
      Events:
        OrderAPI:
          Type: Api
          Properties:
            RestApiId: !Ref ApiId
            Path: /orders
            Method: post

  PaymentFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: ecommerce-payment-function
      CodeUri: functions/payment/
      Handler: app.lambda_handler

Notice how the parent template orchestrates everything. It passes the shared layer ARN as a parameter to child stacks, and child stacks output values that the parent can reference. This separation makes each stack focused and maintainable.

To deploy this nested stack architecture, you’d simply deploy the parent template:

sam build
sam deploy --template-file template.yaml --guided

SAM handles uploading nested templates to S3 and orchestrating the CloudFormation stack creation.

Practical Considerations for Production Microservices#

Building microservices with SAM goes beyond just defining resources. There are several patterns worth considering for production readiness.

Environment-based configuration is essential. You likely want different settings for development, staging, and production. SAM supports parameter overrides:

Parameters:
  Environment:
    Type: String
    Default: dev
    AllowedValues: [dev, staging, prod]

Globals:
  Function:
    Environment:
      Variables:
        ENVIRONMENT: !Ref Environment
        LOG_LEVEL: !If [IsProd, WARN, DEBUG]

Conditions:
  IsProd: !Equals [!Ref Environment, prod]

Versioning your shared layer prevents breaking changes. When you update the layer, increment its version:

SharedLayer:
  Type: AWS::Serverless::LayerVersion
  Properties:
    LayerName: ecommerce-shared-layer
    Description: v2.1 - Added order validation enhancements
    ContentUri: layers/shared/

Each deployment creates a new version, and functions can pin to a specific version if needed.

Dead Letter Queues (DLQs) catch failed async invocations. If the Order function invokes Payment asynchronously and it fails, having a DLQ ensures you don’t lose that message:

OrderFunction:
  Type: AWS::Serverless::Function
  Properties:
    # ... other properties ...
    DeadLetterConfig:
      Type: SQS
      TargetArn: !GetAtt OrderDLQ.Arn

OrderDLQ:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: ecommerce-order-dlq

X-Ray tracing gives you visibility into function calls across your microservices. Enable it at the API level (as shown in our template) and SAM automatically instruments your functions. You’ll see trace maps showing how the Order function calls Payment, which calls Inventory, with timing and error information.

Testing Multi-Function Applications Locally#

One advantage of SAM is the ability to test your entire application locally before deploying. The SAM CLI includes a local Lambda runtime and API Gateway simulator.

sam local start-api

This command starts a local API Gateway on port 3000. You can then curl your endpoints:

curl -X POST http://localhost:3000/orders \
  -H "Content-Type: application/json" \
  -d '{"id": "order-123", "amount": 99.99}'

The functions run locally, and you can set breakpoints in your IDE. This dramatically speeds up development because you get fast feedback without deploying to AWS each time.

For testing individual functions outside the API context, use:

sam local invoke OrderFunction -e events/order-event.json

Where events/order-event.json contains a mock Lambda event. This is particularly useful for testing the payment or inventory functions that are invoked by other functions.

Organizing Your Repository Structure#

For a multi-function SAM application, a clean directory structure is essential. Here’s a recommended layout:

ecommerce-backend/
├── template.yaml
├── functions/
│   ├── order/
│   │   ├── app.py
│   │   ├── requirements.txt
│   │   └── tests/
│   ├── payment/
│   │   ├── app.py
│   │   ├── requirements.txt
│   │   └── tests/
│   └── inventory/
│       ├── app.py
│       ├── requirements.txt
│       └── tests/
├── layers/
│   └── shared/
│       └── python/
│           └── shared_utils/
│               ├── __init__.py
│               ├── logging.py
│               ├── validators.py
│               └── database.py
├── stacks/
│   ├── api.yaml
│   └── functions.yaml
├── events/
│   ├── order-event.json
│   ├── payment-event.json
│   └── inventory-event.json
├── tests/
│   ├── unit/
│   └── integration/
└── README.md

Each function has its own directory with its code and tests. The shared layer lives in layers/shared/, and nested stack templates live in stacks/. This structure makes it clear what belongs where and how things are organized.

Deploying and Managing Multiple Environments#

As your application matures, you’ll typically have development, staging, and production deployments. SAM makes this straightforward with parameter overrides and separate parameter files.

Create a samconfig.toml file in your project root:

[default]
[default.build]
cached = true

[default.build.parameters]

[default.deploy]
region = "us-east-1"
confirm_changeset = true
capabilities = "CAPABILITY_IAM"

[prod]
[prod.deploy]
parameters = "Environment=prod"
s3_bucket = "my-prod-deployment-bucket"

[dev]
[dev.deploy]
parameters = "Environment=dev"
s3_bucket = "my-dev-deployment-bucket"

Now you can deploy to different environments:

sam deploy --config-env dev
sam deploy --config-env prod

Each environment gets its own S3 bucket for artifacts and its own CloudFormation stack, keeping them completely isolated.

Monitoring and Debugging Multi-Function Systems#

With multiple functions calling each other, observability becomes critical. CloudWatch Logs provides basic logging, but X-Ray gives you the full picture.

Enable X-Ray tracing in your template, and then use the AWS SDK to capture subsegments:

from aws_xray_sdk.core import xray_recorder

@xray_recorder.capture('invoke_payment')
def invoke_payment_function(order):
    response = lambda_client.invoke(
        FunctionName=os.environ['PAYMENT_FUNCTION_ARN'],
        InvocationType='RequestResponse',
        Payload=json.dumps(order)
    )
    return response

The @xray_recorder.capture decorator creates a subsegment in the trace. In the X-Ray console, you’ll see a service map showing how your functions interact, with latency and error rates for each interaction. This is invaluable for understanding bottlenecks and failures in your microservices.

CloudWatch Insights lets you query logs across all functions:

fields @timestamp, @message, @duration
| filter ispresent(error)
| stats count() by functionName

This query shows you which functions are generating errors, helping you quickly identify issues.

Conclusion#

Building serverless microservices with SAM transforms what could be a complex infrastructure puzzle into a manageable, maintainable system. By organizing multiple functions in a single template, sharing code through layers, and using outputs to enable cross-function communication, you create applications that scale in complexity without proportional growth in management overhead.

The patterns covered here—nested stacks for large applications, IAM policies for least-privilege access, layers for shared code, and outputs for function discovery—form the foundation of production-ready serverless systems. Combined with SAM’s local testing capabilities and CloudFormation’s infrastructure-as-code philosophy, you have a powerful toolkit for building the microservices of tomorrow.

Start with a single template if your application is small, then migrate to nested stacks as it grows. Invest in shared layers early to prevent code duplication. And always enable X-Ray tracing from day one—observability in distributed systems isn’t a luxury, it’s a necessity. With these practices in place, you’ll build serverless applications that your team can understand, test, and operate with confidence.