Native Cloud Infrastructure as Code: AWS CloudFormation & Azure Bicep

While Terraform dominates multi-cloud engineering, cloud providers provide their own Native Infrastructure as Code engines: AWS CloudFormation for Amazon Web Services, and Azure Bicep / ARM Templates for Microsoft Azure. Native tools provide Day-0 support for brand-new cloud features and eliminate the need to manage external remote state files, because state is managed natively by the cloud provider itself.

1. AWS CloudFormation

CloudFormation treats collections of AWS resources as a single unit called a Stack. You define stacks in JSON or YAML formatting:

• Change Sets: Like terraform plan, Change Sets allow you to preview proposed changes to running stacks before executing them, preventing unexpected resource replacement.
• Automated Rollbacks: If a single resource fails to provision during a stack update (e.g., invalid subnet CIDR), CloudFormation automatically rolls back all previously created resources to the last-known good state.
• CloudFormation StackSets: Enables you to deploy, update, or delete stacks across multiple AWS accounts and multiple geographic regions with a single operation.

2. Azure Bicep: The Evolution of ARM Templates

Historically, Azure used verbose, nested JSON Azure Resource Manager (ARM) templates that were notoriously difficult to read and write. In 2021, Microsoft introduced Azure Bicep, a clean domain-specific language (DSL) that transpiles directly into ARM JSON:

// storage.bicep - Clean, type-safe Azure Bicep template
param location string = resourceGroup().location
param storageAccountName string = 'veewomstore${uniqueString(resourceGroup().id)}'

resource storageaccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

output storageId string = storageaccount.id

CloudFormation vs Azure Bicep vs Terraform Comparison