Containers and Infrastructure as Code

What it is

Container orchestration services run your images for you, keep the desired number of copies alive and replace them during updates. Infrastructure as code (IaC) describes the surrounding resources in a template, so the same environment can be created again and reviewed like source code.

The two ideas combine: a template creates the cluster, task definition and service, and a pipeline updates the image tag.

How it works

Amazon ECS task definitions

A task definition is a JSON blueprint for your containers. It sets the image, CPU and memory, port mappings, environment variables, secrets, log configuration and the roles. Each change registers a new numbered revision of the task definition family.

Two roles are often confused:

The secrets field injects a value from Secrets Manager or Parameter Store into a container as an environment variable, using the valueFrom ARN. This keeps the secret out of the image.

Launch types

With the Fargate launch type you set task level CPU and memory and AWS manages the servers. Fargate tasks use the awsvpc network mode, so each task gets its own network interface. With the EC2 launch type you run and patch the container instances yourself, which gives more control over instance types and daemon workloads.

ECS services and rolling updates

An ECS service keeps a desired count of tasks running and can register them with a load balancer. The default rolling update replaces tasks gradually, controlled by two values:

• minimumHealthyPercent is how much capacity must stay running during the update.
• maximumPercent is how far above the desired count the service may go.

The deployment circuit breaker stops a deployment that keeps failing and can roll back to the last completed deployment. ECS also supports blue/green deployments, where the new revision runs beside the old one and traffic shifts after validation.

Amazon EKS manifests

On EKS you describe the application in Kubernetes YAML manifests. A Deployment declares the image, replicas and update strategy, and a Service exposes the pods. You apply them with kubectl apply -f. The default RollingUpdate strategy uses maxSurge and maxUnavailable, and kubectl rollout undo returns to the previous revision. Pods get AWS permissions through EKS Pod Identity or IAM roles for service accounts, not through the node role.

CloudFormation templates

A template is JSON or YAML. Only the Resources section is required. The others are common:

• Parameters accept values at deploy time.
• Mappings hold fixed lookup tables.
• Conditions switch resources on or off.
• Outputs return values and can be exported for other stacks.

Useful intrinsic functions are !Ref, !GetAtt, !Sub, !Join, !If and !ImportValue. A change set previews an update, and drift detection finds resources changed outside the stack.

AWS SAM

AWS SAM is a shorthand on top of CloudFormation. The line Transform: AWS::Serverless-2016-10-31 makes CloudFormation expand SAM resource types such as AWS::Serverless::Function, AWS::Serverless::Api, AWS::Serverless::HttpApi and AWS::Serverless::SimpleTable.

A short Events block on a function creates the API route or queue mapping for you, and AutoPublishAlias publishes a version and alias on each deploy.

The AWS CDK is the code based alternative. You write constructs in a programming language, run cdk synth to produce a CloudFormation template, and cdk deploy to create the stack. A one time cdk bootstrap prepares each account and Region.

How the exam asks about this

• "A container must read a database password without storing it in the image." -> Reference the secret in the task definition secrets field.
• "The ECS agent cannot pull from ECR." -> The task execution role lacks ECR permissions.
• "Define a Lambda function and API with the least template code." -> An AWS SAM template.