Eight modules have built a complete architecture: six subnets, two auto scaling groups, five Lambda functions, four queues, one Aurora cluster, two DynamoDB tables, five buckets, a load balancer, a CloudFront distribution, fourteen alarms and a pipeline that deploys without taking the service down. It all works. And none of it exists in any file: it exists because somebody typed a command one day. This lesson fixes the asymmetry Marta pointed out when closing module 8, using the native AWS tool for the job: CloudFormation, the service that turns a text file into real resources and maintains the relationship between the two.

Cost warning. CloudFormation is free when it manages AWS resources: you pay for the resources, not for the stacks. It only charges for third-party resources and registered private types (0.0009 USD per handler second). The network template creates two NAT gateways: around 0.045 USD/hour each plus traffic, about 65 USD a month if you leave it up. The cleanup section deletes it with one command. Fictitious data.

1. The asymmetry between code and infrastructure
2. What infrastructure as code is, and declarative versus imperative
3. Anatomy of a template
4. Parameters: types, constraints and values from SSM
5. Mappings, Conditions and intrinsic functions
6. Stacks: lifecycle, states and ROLLBACK_COMPLETE
7. Deletion policies and termination protection
8. Change sets and the three types of update
9. Drift detection
10. MercadoFresco's network in a template
11. The application layer that imports the outputs
12. Several stacks: exports versus SSM
13. Nested stacks, modules and custom resources
14. Importing existing resources into a stack
15. StackSets and deployment from the pipeline
16. Best practices, cfn-lint and cfn-guard
17. Limits, cost and cleanup
18. Common mistakes and tips
19. Exercises
20. Conclusion

Marta takes stock in one afternoon and writes down four facts:

The third one is the most expensive. In module 5 a security group turned up with a rule pointing at an IP range nobody recognised and nobody deleted: it might have belonged to a supplier. That is the real cost of not having infrastructure as code: it is not that you cannot create it; it is that you cannot change it with confidence.

It consists of describing the infrastructure in text files versioned in Git and letting a tool make reality match the description. It is not "automating creation": it is that the file is the source of truth. Four properties follow from that:

• Reproducibility. The same file produces the same result in another region, in another account or six months from now.
• Review. Infrastructure goes through a pull request just like the code in 08-01: a change to a security group gets commented on, approved and left with an author, a date and a reason.
• Controlled drift and living documentation. The tool knows what should exist, so it can compare that with what does exist — without IaC, drift is invisible by definition — and the file cannot fall out of date with reality, because it is what creates it.
• It can be deleted without fear. When bringing an environment up costs one command, switching it off on Friday stops being a risk and becomes a saving. It is the property that convinces the sceptics.

MercadoFresco has used the imperative approach so far: commands that describe how to reach the state. CloudFormation is declarative: you describe what you want and the service works out the steps.

The script knows nothing about the previous state: every command creates. Making it idempotent would mean wrapping every line in a check, handling the generated identifiers and deciding what to do if the resource already exists with a different configuration; in other words, reimplementing CloudFormation in Bash.

The imperative does not go away: it is still the right thing for one-off operations (aws s3 cp, restarting an instance, querying metrics). The rule: if the resource has to still be there tomorrow, it goes in a template; if it is an action that happens once, it goes in a command.

A YAML or JSON document with nine possible sections. Only Resources is mandatory.

Missing are Rules (validation of parameter combinations) and Hooks, both far less common. The structure of a resource is always the same, with Type and Properties mandatory and the rest optional:

First important rule: changing the logical name of a resource is the same as deleting it and creating another one. CloudFormation identifies resources by their logical name, not by what they do. Renaming Vpc to VpcPrincipal in a deployed template destroys the VPC.

Without parameters you would need three almost identical templates for the three environments.

Three things separate an amateur template from a professional one:

1. The AWS-specific types validate before anything starts. With Type: String for a non-existent SSH key, the stack creates half a dozen resources and fails when it reaches the instance. With AWS::EC2::KeyPair::KeyName it fails at second zero, without creating anything.
2. AWS::SSM::Parameter::Value<...> decouples the template from the values. The shop's AMI changes every month; the template should not have to change because of that. MercadoFresco uses it with /mercadofresco/produccion/ami-tienda.
3. NoEcho does not encrypt, it only hides. Passwords do not belong in parameters: they belong in Secrets Manager (04-03) and are referenced with dynamic resolution, which is evaluated at deployment time without the value ever entering the template:

Mappings is a static two-level lookup table, useful for varying by region or by environment; it is read with Fn::FindInMap. Conditions computes booleans with Fn::Equals, Fn::And, Fn::Or and Fn::Not.

They are read with !FindInMap [ PorEntorno, !Ref Entorno, Tipo ]. A resource with Condition: CrearSegundoNat is only created if the condition is true: nat-mercadofresco-b exists in production and not in development with the same template, and that saves around 32 USD a month per non-production environment. A word of warning: use them sparingly. A template with twelve nested conditions is unreadable and impossible to reason about when it fails; if the difference between environments is large, what you need is different templates, not more conditions.

Each one has a long form (Fn::Sub) and a short form (!Sub). In YAML the short one is used except when two short forms have to be nested one straight after the other, which YAML does not allow.

What causes the most confusion is !Ref, because it returns different things depending on the type: on a VPC or a subnet, its identifier; on a bucket, the name; on an SQS queue, the URL; on an SNS topic, the ARN; on an IAM role, the name; on a Lambda, the name. That table explains 80 % of the Value of property X must be of type String errors. When you need an ARN it is almost always !GetAtt Recurso.Arn; the "Return values" section of each type has the exact list.

The pseudo-parameters are variables AWS always provides: AWS::AccountId (111122223333), AWS::Region (eu-west-1), AWS::StackName, AWS::StackId, AWS::Partition, AWS::URLSuffix and AWS::NoValue.

A stack is a deployed template: resources that are created, updated and deleted as a unit. It is the unit of management, of permissions and of drift.

The state that baffles everyone on day one is ROLLBACK_COMPLETE: it happens when the initial creation fails and CloudFormation undoes what it created. The stack carries on existing but in a terminal state: it cannot be updated, only deleted and created again with the corrected template. Not to be confused with UPDATE_ROLLBACK_COMPLETE, which is healthy: the stack went back to its previous version and can carry on being updated.

Stack tags propagate to every resource that supports them: it is the cheapest way to comply with MercadoFresco's mandatory tagging without repeating it resource by resource (picked up again in 11-02). For day-to-day work, deploy creates the stack if it does not exist and updates it if it does, with a change set underneath:

--no-fail-on-empty-changeset stops the pipeline going red when there is nothing to change, which is the most frequent case. --capabilities is mandatory when the template creates IAM resources: it is an explicit acknowledgement that you know you are creating permissions (CAPABILITY_IAM, CAPABILITY_NAMED_IAM if you name them, CAPABILITY_AUTO_EXPAND for macros and nested stacks).

By default, deleting a stack deletes its resources. For aurora-mercadofresco-pedidos and mercadofresco-catalogo-fotos that is unacceptable.

UpdateReplacePolicy is the one people forget and the one that prevents the most grief: changing Aurora's DBClusterIdentifier causes a replacement, and without it the old cluster — with the data — disappears as soon as the new one is ready. Termination protection is one more layer, at stack level: aws cloudformation update-termination-protection --stack-name mercadofresco-datos-produccion --enable-termination-protection, and with it active delete-stack simply fails. MercadoFresco's rule: termination protection on the three production stacks, and Retain or Snapshot on every stateful resource, in every environment.

A change set is a simulation: CloudFormation compares the new template with the current stack and says what it would do, without doing it. It is the answer to the question nobody could answer in module 8: what is going to happen if I apply this?

The last line is a red alert: Replacement: True means the subnet is deleted and another one created, with a new identifier, and everything that depends on it is affected. Without looking at the change set, that would have happened on a Friday at eleven.

The third row is the one that hurts: a replacement on mercadofresco-catalogo-fotos means a new empty bucket and the old one deleted with the 40,000 photos inside, unless UpdateReplacePolicy prevents it. The documentation for each type states, property by property, the "Update requires", and it has to be checked before writing the change, not afterwards.

A word of caution: if somebody modifies the stack between your creating it and executing it, the simulation is no longer valid; that is why pipelines create it and execute it in consecutive stages, not hours apart.

Drift is the difference between what the template says and what is actually there. It always appears: during an incident, at three in the morning, nobody edits a template.

The per-resource states are IN_SYNC, MODIFIED, DELETED and NOT_CHECKED. That last one matters: not every type supports drift detection, so an IN_SYNC at stack level does not guarantee nothing has changed. When drift is found there are two paths: update the template to reflect reality, if the manual change was legitimate, documenting the reason in the PR; or reapply the stack to undo it. An important nuance: CloudFormation has no automatic "fix drift", because an update only touches what changed in the template; to force it you have to alter the drifted value in the template and update. At MercadoFresco a scheduled job runs it every week over the production stacks and publishes the result to alertas-mercadofresco. AWS Config (05-04) also has the cloudformation-stack-drift-detection-check rule, which does this continuously.

red-mercadofresco.yaml, in the mercadofresco-infra repository, reproduces the network from module 3.

Four comments. The creation order is nowhere to be found: CloudFormation works out that SubredPublicaA needs Vpc because it references it with !Ref, and creates independent things in parallel; the only DependsOn is the only dependency that cannot be deduced from the properties. !GetAZs avoids pinning eu-west-1a. !If with !Ref NatB degrades gracefully in small environments without duplicating the template. And the outputs are exported with the ${AWS::StackName} prefix, so that production and pre-production do not clash: export names are unique per region.

Seven minutes later — the NATs take about two minutes each — the complete network exists. And this time it exists in a file as well, with a history in Git.

aplicacion-mercadofresco.yaml builds the ALB, the target group and the ASG on top, without knowing a single identifier:

Two details. YAML does not allow two short tags in a row, so !ImportValue with !Sub inside forces the inner one to be written in long form ('Fn::Sub'); the error you get for forgetting, unsupported structure, is no help at all. And UpdatePolicy decides what happens when the launch template changes: without it, CloudFormation updates the ASG and does not touch the existing instances, so the change is not applied until the next scaling event. It is the 08-03 rolling deployment applied to infrastructure.

A stack with 300 resources takes 40 minutes, rolls back in its entirety on any failure and cannot be touched by one person without coordinating with the other two. The split follows two criteria: by lifecycle (what changes together goes together) and by ownership (each stack has a clear owner).

The first row is the key: an export in use is a lock. That is good — it stops things breaking — and it is bad — it blocks evolution. MercadoFresco's rule: exports for the structural things that are not going to change (VPC and subnets), and SSM parameters for everything else and whenever the value crosses accounts or regions (queue ARNs, table names, key aliases).

Nested stacks include one template inside another as if it were a resource; the child must live in S3 (mercadofresco-artefactos will do) and its outputs are read with !GetAtt PilaSubredes.Outputs.SubredesApp.

Sooner or later something turns up that CloudFormation does not know how to create: a user in an external tool, an initial data load. A custom resource delegates to a Lambda: CloudFormation sends it an event with a RequestType and a presigned URL, and the function must respond to that URL.

Resource providers are the formal alternative: you register a new type, for example MercadoFresco::Facturacion::Cliente, with its JSON schema and its handlers, and from then on it is used like any other resource, drift and validation included. It costs more and you pay per handler second, but the public registry already carries third-party types — Datadog, MongoDB Atlas, GitHub — that are activated in one click.

This is the operation MercadoFresco really needs, because its infrastructure already exists. The naive alternative — creating new stacks and deleting the old ones — would mean migrating data and a cutover window. Importing adopts the existing resources without touching them. Four steps:

1. Write the template that describes exactly what exists. There is no improvising here: if it says /health and the real target group has /salud, the import goes through and the next update-stack changes reality without warning.
2. Add DeletionPolicy: Retain to every resource being imported — it is mandatory — and prepare the identifiers file, which pairs each logical name with the real resource.
3. Create and execute a change set of type IMPORT.

Importing does not check that the template matches reality: only that the resources exist and are of the declared type. Drift detection immediately afterwards is what reveals the differences. Marta finds three:

The third case explains why the order matters: import and detect first, correct afterwards. Writing the template "as it ought to be" and applying it directly would have relaxed a security policy without anybody noticing. MercadoFresco imports layer by layer, starting with the network — the most stable one — and leaving the data layer until last, with an agreed window and a recent Aurora backup.

A StackSet deploys the same template across a set of accounts and regions from a single operation. Today MercadoFresco has one account, so its usefulness is limited; in 09-04, with four, it will be the piece that guarantees every new account is born with the baseline in place: trail, Config recorder, billing alarms and roles.

SELF_MANAGED requires creating two IAM roles by hand; SERVICE_MANAGED leans on Organizations and requires nothing. With --auto-deployment Enabled=true, an account added to a target OU gets the stack on its own. And the practical conclusion from module 8: if the infrastructure is code, it gets deployed from the pipeline. CodePipeline has a native action with four modes; MercadoFresco's pattern separates simulation from execution with an approval in between.

RoleArn is key: CloudFormation assumes that role to create the resources, not the permissions of whoever launched the pipeline, so Luis can trigger an infrastructure deployment without having permission to create VPCs himself. And TemplateConfiguration points at a per-environment JSON in the repository with Parameters and Tags: with that, the difference between pre-production and production stops being a mystery and becomes a file you compare with diff in ten seconds.

Six rules in the README of mercadofresco-infra:

1. Small templates with a single responsibility. More than 400 lines or 80 resources: split it, by lifecycle.
2. Minimal parameters. Every parameter is a decision somebody can get wrong. What does not vary between environments is a constant, not a parameter.
3. No magic values, and physical names only when they are needed. No hand-written AMIs, no repeated CIDRs, no raw ARNs: !Sub, Mappings and SSM cover every case. And pinning BucketName or GroupName prevents no-interruption updates and blocks deploying the same template twice in one account.
4. Everything goes through a PR and through automatic validation. No manual deploy against production; an emergency means opening the reconciliation PR the same day.

That second rule is the one that would have prevented the pre-production versus production difference from the start of the lesson. Both tools run in build-mercadofresco-integracion (08-02) and fail the build: they are not warnings.

CloudFormation does not charge for managing AWS resources; it charges 0.0009 USD per handler second on third-party resources and private types, with 1,000 free operations a month. The real cost is always that of the resources created.

If the deletion ends in DELETE_FAILED, the cause is almost always a bucket with objects inside or a network interface created by hand in the subnet; --retain-resources lets you finish the deletion leaving those specific resources out.

Mistake: renaming a logical resource and losing the resource. Changing Vpc to VpcPrincipal does not rename anything: it deletes the VPC and creates another. Tip: logical names are immutable in practice; if you have to rename, do it in two steps with DeletionPolicy: Retain plus a later import.

Mistake: deploying without looking at the change set. It is merging a PR without reading the diff. Tip: have the pipeline generate it and publish it before the approval, paying attention to the Replacement column. Mistake: not understanding ROLLBACK_COMPLETE. It is the terminal state of a failed creation. Tip: delete it and create it again, but look at the events before deleting, filtering on CREATE_FAILED: the first is the cause, the rest are consequences.

Mistake: passwords in parameters with NoEcho, believing they are safe, or exports for everything. With twenty cross-stack exports the network becomes unmodifiable. Tip: {{resolve:secretsmanager:...}} or {{resolve:ssm-secure:...}} for the secrets, exports only for the structural, and SSM for the rest.

Mistake: believing that importing validates the template. It does not: drift detection right after every import, without exception.

Tip: use --role-arn on every deployment and a stack policy on the resources holding data. The first is the difference between "anyone who can deploy can create anything" and "only the reviewed template creates what it declares"; the second, with set-stack-policy, denies Update:Replace and Update:Delete on specific resources, a belt for the braces of UpdateReplacePolicy.

Tip: look at the deployed template, not just the one in the repository. get-template --template-stage Processed returns it with macros and transformations already applied; that is what you have to review when the result does not match what you thought you were writing.

Tip: Description in the template, in every parameter and in every output. It is the living documentation from the start of the lesson, and it costs thirty seconds.

Write integracion-mercadofresco.yaml: the cola-mercadofresco-pedidos queue with its mercadofresco-pedidos-fallidos DLQ and 5 attempts, the mercadofresco-pedido-confirmado topic, the subscription of the queue to the topic and the publication of the queue ARN in Parameter Store. Requirements: encryption with alias/mercadofresco-datos, 14 days of retention on the DLQ and 4 on the queue, an environment suffix in the names, complete mandatory tagging and an appropriate DeletionPolicy on the DLQ. State which type of update changing VisibilityTimeout would cause, and which one changing QueueName would.

alb-mercadofresco-tienda and tg-mercadofresco-tienda have been in production for eight months, created by hand. Marta wants to adopt them into mercadofresco-aplicacion-produccion without taking the service down. Describe the procedure: what to gather beforehand and with which commands, what the template must contain, how the identifiers file is built, which commands are run and in what order, and what is done immediately afterwards. Explain what would happen if the template declared HealthCheckIntervalSeconds: 30 when the real target group has 15, and at exactly which moment it would show up.

A colleague has written a 780-line template with 96 resources: VPC and subnets, Aurora, two DynamoDB tables, ElastiCache, ALB, ASG, four queues, event bus, twelve alarms and three buckets. It takes 41 minutes and any failure rolls everything back; last week, an error in an alarm also rolled back a perfectly good subnet change. Propose the split: which stacks, with what contents and on what criterion; for each boundary, whether you would use an export or SSM and why; the deployment order and the deletion order; and what would have happened last week with your split.

Solution 1

Changing VisibilityTimeout is no interruption: SQS applies it in place and the URL does not change. Changing QueueName is with replacement: SQS does not allow renaming, so a new queue is created and the old one deleted with the messages inside. It is a perfect example of why pinning physical names has a cost and of why the DLQ carries Retain. And one detail that is easy to forget: without the queue policy, SNS cannot deliver and the messages are lost silently; the aws:SourceArn condition stops any other topic in the account writing to it, the least privilege of 04-01 applied to resources.

Solution 2

Beforehand: read the real configuration, never write it from memory.

The template is written from those files, property by property, including the attributes that are not obvious: deregistration_delay.timeout_seconds, stickiness.enabled, the listener's TLS policy and the ACM certificate. Mandatory: DeletionPolicy: Retain on the ALB, the target group and the listener; without it the import is rejected, and it is worth adding UpdateReplacePolicy: Retain too. The identifiers file pairs LogicalResourceId with LoadBalancerArn and TargetGroupArn, using the full ARN (arn:aws:elasticloadbalancing:eu-west-1:111122223333:loadbalancer/app/alb-mercadofresco-tienda/a1b2c3).

Order: cfn-lint; create-change-set with --change-set-type IMPORT; describe-change-set to confirm that all the actions are Import and none is Add or Modify — a single Modify means the template does not match reality and has to be fixed first; execute-change-set; wait stack-import-complete. Immediately afterwards: drift detection, resolving case by case whether the template or reality wins. The 30 versus 15 case. The import goes through without complaining: it only verifies existence and type. Drift would flag it as MODIFIED. And if nobody looks, the problem shows up at the next update-stack, whatever it is about, even if it has nothing to do with the target group: CloudFormation applies the complete template and the interval becomes 30 seconds. In practice, the ALB takes twice as long to detect a downed instance — from 30 to 60 seconds with two failed checks — exactly the kind of silent degradation nobody connects with a deployment of something else. That is the entire argument in favour of the drift step.

Solution 3

Five stacks, the same ones from the table in the lesson: red (almost immutable, everything depends on it), datos (state, catastrophic deletion, needs protection), integracion (no durable state, owned by Luis), aplicacion (what changes most) and observabilidad (changes with incidents, zero risk). Boundaries and order. Network → everything: export, because the VPC and subnet identifiers are structural, they are not going to change, and we want the lock: nobody should be able to delete the network while there is anything on top of it. Data → application (Aurora endpoint, table names): SSM, because they change more easily than it seems — a migration to Serverless v2, a read endpoint — and an export would block precisely that. Integration → application: SSM, and also because in 09-04 these stacks are going to live in different accounts, where exports do not work. Everything → observability: SSM; the stack that matters least and changes most must not be able to block anybody.

The deployment order is network → data and integration in parallel → application → observability, and the deletion order is its exact inverse: the exports enforce it on their own in the network's case, and everywhere else it has to be respected out of discipline, because SSM enforces nothing.

Last week. The error in the alarm would have failed only mercadofresco-observabilidad, which deploys in under two minutes and holds no critical resources; the subnet change, in mercadofresco-red, would already have been applied and would not have been rolled back. The scope of the failure goes from 96 resources to 12, and the 41 minutes become four deployments of between 2 and 12 minutes, some of them in parallel. One honest nuance: the split is not free. It introduces a deployment order, it forces the boundaries to be maintained and it makes a change touching two layers need two stacks. The rule that justifies it is the same one from 08-05 about deployments: the scope of a failure must be proportional to the risk of the change, and mixing an alarm with a subnet violates that rule.

MercadoFresco's infrastructure is finally in files. red-mercadofresco.yaml describes the VPC, the six subnets, the internet gateway, the NATs — two in production and one everywhere else, with the same template — and the S3 endpoint, with a history in Git; aplicacion-mercadofresco.yaml builds the ALB, the target group and the auto scaling group on top without knowing a single identifier, importing the outputs of the first. And you have the anatomy of a template, with parameters that validate before anything starts thanks to the AWS-specific types, values arriving from Parameter Store without touching the template and secrets resolved with {{resolve:secretsmanager:...}} instead of the false friend that is NoEcho. You have the intrinsic functions and the table that avoids the most frequent error: that !Ref returns the URL of a queue, the ARN of a topic and the name of a role, and that what you are after is almost always !GetAtt Recurso.Arn. And you have the lifecycle of a stack, with the state that baffles everyone on day one: ROLLBACK_COMPLETE, which can only be deleted.

What really changes the way you work are three mechanisms. Change sets, which answer in writing the question nobody could answer in module 8 — what is going to happen if I apply this? — and which show the Replacement column that separates a routine change from the destruction of a subnet. Deletion and replacement policies plus termination protection, the only thing standing between a command and the Aurora data. And drift detection, which turns manual changes from invisible into a weekly report. With importing existing resources, MercadoFresco recreates nothing: it adopts what already works, layer by layer, starting with the network, and runs drift detection straight afterwards — the step nobody should skip, because importing checks that the resources exist, not that the template describes them properly. The five stacks per environment are split by lifecycle and by ownership, with exports for the structural and SSM for whatever can change or cross accounts, knowing that an export in use is a lock. And the infrastructure goes through the 08-04 pipeline with the same rigour as the code: cfn-lint and cfn-guard that fail the build, a published change set, Marta's approval and execution with RoleArn, so that whoever pulls the trigger does not need the permissions being exercised.

One limitation remains, and it shows up as soon as the template grows. The network describes six almost identical subnets repeated by hand: there are no loops, no functions, no way of writing "create one subnet per AZ" or of encapsulating "MercadoFresco's standard network" into something reusable. Conditions work for two cases and become unreadable beyond five. And there is no way of writing a test that verifies no template opens port 22 to the world: cfn-guard helps, but it is yet another language to learn.

In 09-02, "AWS CDK", that same infrastructure is written in TypeScript and in Python, with loops, conditionals, types, reusable constructs and real unit tests, and the result is still a CloudFormation template deployed as a stack. Everything in this lesson remains true underneath: the CDK does not replace CloudFormation, it writes it for you.