Secure Deployment with IaC

What it is

Manual changes in the console are slow, hard to review and easy to get wrong. Infrastructure as code (IaC) describes resources in files that are reviewed, tested and deployed the same way every time, which is the foundation of secure and consistent deployment.

The security goals are that every resource starts in a compliant state, that deployments use only the permissions they need, and that bad changes are caught before they reach production.

How it works

AWS CloudFormation essentials

CloudFormation creates resources from templates, grouped in stacks. These features support safe deployment.

Use dynamic references instead of putting secrets in parameters. A parameter with NoEcho is masked in the console but is still a value you passed, so a secret store is better for real secrets.

Resources:
  DataBucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      VersioningConfiguration:
        Status: Enabled
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: aws:kms
              KMSMasterKeyID: !Ref DataKey
            BucketKeyEnabled: true
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

This template builds a bucket that is encrypted, versioned, kept on deletion and private (the DataKey resource is defined elsewhere in the template). Putting secure defaults into shared templates means every team inherits them.

Deploying across accounts with StackSets

CloudFormation StackSets deploys one template to many accounts and Regions. With service managed permissions and AWS Organizations, you target OUs, and StackSets can deploy automatically to accounts that join the OU later.

# AWS CLI, in the management or delegated administrator account
aws cloudformation create-stack-set --stack-set-name response-role \
  --template-body file://role.yaml \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
  --capabilities CAPABILITY_NAMED_IAM

aws cloudformation create-stack-instances --stack-set-name response-role \
  --deployment-targets OrganizationalUnitIds=ou-ab12-cdef3456 \
  --regions us-east-1

Use StackSets for baselines such as security roles, Config rules and logging settings. Self managed permissions need administration and execution roles in each account and suit cases outside an organization.

Checking templates before deployment

• Linting and policy as code. Tools such as cfn-lint check syntax, and AWS CloudFormation Guard evaluates rules, for example "every bucket must have encryption".
• CloudFormation Hooks. A Guard or Lambda hook runs during stack operations and can block a non compliant resource. Control Tower proactive controls use hooks.
• Static analysis in the pipeline. Scan templates, code and container images before release.
• AWS Config and Security Hub. Detect non compliance after deployment as a second line.

Service Catalog

AWS Service Catalog lets administrators publish approved products (CloudFormation or Terraform based) in portfolios that are shared with accounts or OUs. Users launch products without needing permissions to the underlying services, because a launch constraint runs the deployment with a specified role.

Choose Service Catalog when you want self service with guardrails: developers pick from a vetted list, the template is fixed, and parameters are limited.

Least privilege pipelines

• Give the pipeline a separate role per stage, and limit each to its target accounts.
• Deploy to accounts through roles that the pipeline assumes, with short sessions.
• Use OIDC federation or roles for external build tools, with no stored access keys.
• Keep production deployments in separate accounts, behind a manual approval step.
• Encrypt and restrict artifact buckets, and log all pipeline actions to CloudTrail.
• Pin dependencies and verify image signatures before deployment.

Consistency and tagging

Immutable infrastructure means you replace resources instead of changing them in place, so drift cannot build up. Build AMIs with Image Builder, and deploy new instances from them. Enforce tags with tag policies, SCPs that require tags on creation, and Config rules that report missing tags.

Handling drift and emergencies

Drift detection finds manual changes. Decide whether to revert the resource to the template or update the template. Emergency console changes should be rare, logged and followed by a template update.