Managing Multiple Environments in AWS SAM (dev/prod)

Posted on by




Introduction

Separating development and production environments is essential—even for personal projects.

With AWS SAM (Serverless Application Model), it’s fairly easy to manage multiple environments by tweaking your template and configuration files.

In this post, I’ll walk you through the exact method I use to separate and deploy dev and prod environments using AWS SAM.



Why Separate Environments?

Here’s why I always create separate environments—even for solo projects:

  • Prevent production issues before they happen
  • Reflect real-world projects where multi-environment setups are the norm

This approach makes development, testing, and deployment safer and more realistic—especially when you’re preparing for actual client work.



How to Manage Environments in AWS SAM

By combining a few key features in AWS SAM, you can clearly separate deployments by environment.



1. Use Parameters and !Sub for Environment-Aware Naming

In your template.yaml, use the Parameters section to define environment-specific values. Then apply those values dynamically with !Sub.

# template.yaml
Parameters:
  Environment:
    Type: String
    Default: dev

Resources:
  WeatherAppFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub weather-function-${Environment}
      CodeUri: lambdas/function/
      Handler: app.lambda_handler
      Runtime: python3.13
Enter fullscreen mode

Exit fullscreen mode

By passing dev or prod as a parameter, the resource names (like Lambda functions) are automatically environment-specific.



2. Use Globals for Shared Settings

Common configurations across all Lambda functions—such as timeout or runtime—can be set using the Globals section:

# template.yaml
Globals:
  Function:
    Timeout: 30
    Runtime: python3.13
Enter fullscreen mode

Exit fullscreen mode

This helps you avoid repeating boilerplate settings across multiple functions.



3. Configure samconfig.toml per Environment

samconfig.toml is a config file SAM reads when deploying. You can define environment-specific sections like [dev.deploy.parameters] and [prod.deploy.parameters].

# samconfig.toml
[dev.deploy.parameters]
stack_name = "weather-app-dev"
s3_prefix = "weather-app-dev"
region = "ap-northeast-1"
parameter_overrides = "Environment=dev"

[prod.deploy.parameters]
stack_name = "weather-app-prod"
s3_prefix = "weather-app-prod"
region = "ap-northeast-1"
parameter_overrides = "Environment=prod"
Enter fullscreen mode

Exit fullscreen mode

parameter_overrides passes values to the Parameters defined in template.yaml, enabling you to reuse the same template across multiple environments.

To deploy with the appropriate config:

# Deploy to development
sam deploy --config-env dev

# Deploy to production
sam deploy --config-env prod
Enter fullscreen mode

Exit fullscreen mode

Tip: Run sam deploy --guided the first time to generate a samconfig.toml file interactively.



How Many Environments Should You Use?

In my case, I keep it simple with two environments:

  • dev: for development and testing changes
  • prod: for production-ready deployments

Unless your app handles sensitive data or requires complex staging, this setup is usually enough for personal projects.

Be mindful of cost—each environment may create its own resources.



Final Thoughts

Even in serverless projects using AWS SAM, environment management is crucial.
Starting with clear separation between dev and prod will save you headaches later.

If you have tips for structuring or automating environments in AWS SAM, I’d love to hear them!



Source link