Skip to main content

CloudFormation Driven Development

CloudFormation Driven Development (CFNDD) is a methodology for building and maintaining cloud applications by thinking infrastructure-first, using AWS CloudFormation templates as the foundation for all features and deployments.

Philosophy​

Instead of manually creating AWS resources through the console or CLI, CFNDD advocates:

  1. Template-First Design: Every feature begins as a CloudFormation template
  2. Infrastructure as Code: All resources are version-controlled and reproducible
  3. Declarative Architecture: Define the desired state; AWS handles the how
  4. Automated Deployment: Use tools like carlin to deploy templates consistently

Core Principles​

1. Think in Templates​

When building a new feature, ask:

  • "What AWS resources does this need?"
  • "How would I define this in CloudFormation?"
  • "Can I reuse existing resource patterns?"

Traditional Approach:

1. Create Lambda via console
2. Set up API Gateway manually
3. Configure IAM roles by clicking
4. Hope you remember for next environment

CFNDD Approach:

Resources:
  ApiFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Events:
        ApiEvent:
          Type: Api
          Properties:
            Path: /users
            Method: GET

2. Version Control Everything​

All CloudFormation templates live in your repository:

project/
├── src/
│   └── lambdas/
│       └── api/
│           └── handler.ts
├── cloudformation/
│   └── template.yml       # Infrastructure definition
├── carlin.yml              # Deployment config
└── package.json

Benefits:

  • Track infrastructure changes over time
  • Review infrastructure in pull requests
  • Roll back to previous versions
  • Share knowledge across team

3. Repeatability and Consistency​

Deploy the same template to multiple environments:

# Staging
ENVIRONMENT=staging carlin deploy

# Production
ENVIRONMENT=production carlin deploy

Same template, different contexts:

  • Stack names: my-app-staging, my-app-production
  • Resource names: my-app-staging-function, my-app-production-function
  • Parameters: Different values per environment

4. Automation Over Manual Steps​

Eliminate click-ops:

Manual ProcessCFNDD Automation
Console → Lambda → Createcarlin deploy
Console → S3 → Create BucketCloudFormation resource
Console → IAM → Attach PolicyTemplate Policies property
Remember what you didGit history

AWS Well-Architected Alignment​

CFNDD directly supports the AWS Well-Architected Framework pillars:

PillarCFNDD Benefit
Operational ExcellenceInfrastructure as code enables change tracking, automated deployments, and rollback capability
SecurityConsistent IAM policies, encryption settings, and network configurations across environments
ReliabilityReproducible deployments reduce human error; disaster recovery via template redeployment
Performance EfficiencyParameterized templates allow right-sizing resources per environment
Cost OptimizationVersion-controlled resources prevent orphaned infrastructure; easy teardown of unused stacks

CFNDD with carlin​

carlin embodies CFNDD by:

Example Workflow:

# 1. Define your CloudFormation template with a Lambda function
# src/cloudformation.ts

# 2. Deploy (carlin auto-detects Lambda, builds code, uploads to S3, deploys stack)
carlin deploy

See CloudFormation Templates for details on template discovery and Lambda handling.

Common Patterns​

For template examples, see:

Best Practices​

  1. Small, focused templates: One stack per application component
  2. Use TypeScript templates: Get type safety and reusable helper functions
  3. Export outputs: Make ARNs/URLs available to other stacks via generate-env
  4. Review change sets: Preview updates before applying
  5. Tag everything: Include Environment, Application, ManagedBy
  6. Enable termination protection: Protect production stacks

Challenges and Solutions​

ChallengeSolution
Steep learning curveStart with carlin-generated templates; study AWS docs
Template size limits (51,200 bytes)Use nested stacks or split into multiple stacks
Complex intrinsic functionsUse helper scripts or tools like cfn-lint
Slow stack updatesParallelize independent stacks; use AWS::NoValue
Drift detectionRegularly run aws cloudformation detect-stack-drift

CFNDD vs Other IaC Tools​

ToolProsCons
CloudFormationNative AWS; free; broad resource supportVerbose YAML; slower updates
TerraformMulti-cloud; HCL syntax; fasterState management complexity; cost
CDKType-safe; familiar languagesSynthesizes to CloudFormation anyway
PulumiReal programming languagesSmaller community; state management

carlin's stance: Use CloudFormation as the deployment engine, but abstract complexity where possible (auto-generation, conventions).