The previous lesson ended on a concrete limitation: red-mercadofresco.yaml describes six almost identical subnets written out by hand, one after another, because YAML has no loops. It has no functions either, no types, and no way to wrap "MercadoFresco's standard network" into something reusable across three environments. And there is no way to write a test that verifies no template opens port 22 to the world. The AWS Cloud Development Kit solves all four problems in a single move: by letting infrastructure be written in a real programming language.

What matters from the first minute is that the CDK does not replace CloudFormation. Everything in 09-01 — stacks, change sets, drift, DeletionPolicy, ROLLBACK_COMPLETE — is still exactly as true as it was. The CDK writes the templates for you.

Cost warning. The CDK is free; you pay for the resources it creates. cdk bootstrap creates an S3 bucket, an ECR repository and five IAM roles per account and region: pennies a month while they sit empty. The examples in this lesson deploy a VPC with NAT (around 0.045 USD/hour each) and an ALB (around 0.025 USD/hour): if you follow the exercises, destroy the stacks when you finish using the command in the cleanup section. Fictitious data.

1. What the CDK is and how it relates to CloudFormation
2. Why it pays off, and when plain CloudFormation is still better
3. Installation, cdk init and project structure
4. App, Stack, Construct and the three construct levels
5. MercadoFresco's network in CDK
6. A construct of your own: MercadoFrescoVpc
7. The application and integration layers in Python
8. Assets: the Lambda code inside the stack
9. The lifecycle: synth, diff, deploy, destroy and bootstrap
10. Context, explicit environments and one stack per environment
11. Aspects: mandatory tagging and audit rules
12. Infrastructure tests
13. Stateful resources, RemovalPolicy and the danger of cdk destroy
14. CDK Pipelines: the pipeline that deploys itself
15. Terraform, CDK for Terraform and the honest comparison
16. Cost and cleanup
17. Common mistakes and tips
18. Exercises
19. Conclusion

The CDK is a library of classes — available in TypeScript, JavaScript, Python, Java, C# and Go — with which infrastructure is described as objects. When you run cdk synth, those objects are synthesised: they produce a CloudFormation template, which is then deployed as an ordinary stack.

Three practical consequences follow from that flow, and they are worth internalising before writing a single line:

• The deployment artefact is still a template. You can read it, version it, review it and deploy it without the CDK. cdk.out/ holds the exact result of synthesis, and cdk synth > plantilla.yaml leaves it in a file for you.
• CloudFormation failures still happen. A ROLLBACK_COMPLETE on a CDK stack is diagnosed and resolved exactly as in 09-01: by looking at the stack events.
• The code does not run in AWS. It runs on your laptop or in CodeBuild, and its only output is JSON. Nothing of the CDK is "alive" in the account except what bootstrapping creates.

What a programming language brings is not prettier syntax: it is five capabilities YAML does not have. Loops, for the six subnets. Real conditionals, evaluated at synthesis rather than at deployment, which makes the generated template simpler rather than more complex. Types, which turn a property mistake into a compile error in the editor instead of a CREATE_FAILED eight minutes later. Reuse, by wrapping patterns in named classes. And tests, runnable in the pipeline just like those of the application code.

But the CDK is not the right answer in every case, and that is worth saying plainly:

MercadoFresco picks CDK for two concrete reasons rooted in its situation: it has three environments that must be identical and a two-person team that already writes code every day. If the team were pure systems people and the infrastructure had gone untouched for two years, the right answer would be to stay with YAML.

The CDK is installed with npm, even for Python projects: the command line tool is Node.

cdk init generates a runnable project. What matters about its structure:

One warning about cdk.json: the context section includes feature flags (@aws-cdk/aws-*:featureFlag) that change the default behaviour of constructs. They are generated with the CDK version that created the project and must not be edited by hand: changing them can change the ARN or the name of already deployed resources, replacement included.

In the mercadofresco-infra repository, the project lives in infra-cdk/ alongside the 09-01 templates, which are kept for as long as the migration lasts.

Three concepts, and everything else follows from them:

• App: the complete CDK application, the root of the tree. An App contains stacks.
• Stack: the unit of deployment, mapping 1:1 to a CloudFormation stack. The 09-01 limits — 500 resources — still apply.
• Construct: any node in the tree. A resource, a group of resources or a whole stack are all constructs. They all take the same three arguments: scope (the parent), id (unique among siblings) and props.

The id is the equivalent of the logical name from 09-01, and it inherits its most important rule: changing the id of a deployed construct destroys and recreates the resource. The CDK composes logical identifiers by concatenating the tree path and adding a suffix, so moving a construct elsewhere also recreates it.

Constructs come in three levels of abstraction, and the same bucket illustrates the difference:

Two warnings. From the L2 you can always drop down to the L1 with resource.node.defaultChild as s3.CfnBucket to touch a property the API does not expose; it is the escape hatch that stops you getting stuck. And L3s are convenient and opaque: they create more resources than you expect and fine-tuning them costs more than writing it by hand, so MercadoFresco uses them to prototype and then drops down to L2.

Another piece that saves a great deal of time are the grant* methods: cola.grantConsumeMessages(rol) generates the correct IAM policy — including permissions on the KMS key — without anyone writing a line of JSON. In practice, it is the least privilege of 04-01 by default.

The 190 lines of YAML from 09-01 turn into this:

Twenty-eight lines against a hundred and ninety, and the synthesised result is equivalent: the same VPC, six subnets (three configurations × two AZs), the internet gateway, the NATs, four route tables with their associations and the S3 endpoint. What has disappeared is not infrastructure, it is mechanical repetition.

Three details are worth pausing on:

• subnetConfiguration is the loop. You declare three subnet types and the CDK creates one per AZ, calculating the CIDRs automatically from the VPC block and cidrMask. Adding a third AZ means changing maxAzs: 2 to 3.
• SubnetType encodes intent, not implementation: PRIVATE_WITH_EGRESS means "private with egress through NAT" and PRIVATE_ISOLATED, "no internet egress". MercadoFresco's data subnets are exactly the latter, and the CDK gives them no route to 0.0.0.0/0 because the type forbids it.
• The NAT conditional is resolved at synthesis. In 09-01 it took a Mappings, a Condition and an Fn::If; here it is a TypeScript ternary operator and the resulting template has no condition at all. That is the difference between evaluating at synthesis time and evaluating at deployment time, and it is why generated templates tend to be simpler than hand-written ones.

One honest caveat: that concision has a price. The ec2.Vpc L2 makes decisions for you — the CIDR split, the names, the number of route tables — and to know exactly what it created you have to look at the synthesised template. That is why cdk synth is not an occasional debugging command: it is part of the normal flow.

Real reuse arrives when the pattern is wrapped in a class with MercadoFresco's decisions already made:

Using it across the three environments is one line per environment, and any improvement to the pattern reaches all three at once: if tomorrow the decision is to enable flow logs in pre-production too, it changes in one place. That is what did not exist in 09-01, because a Mappings with three columns is not an abstraction: it is a table.

MercadoFresco's convention is that in-house constructs expose what consumers need and nothing more — here, vpc and sgTienda — so the internals can change without breaking anyone. It is encapsulation applied to infrastructure, and it is exactly why a programming language pays off.

The CDK is genuinely multi-language: the libraries are generated with jsii from the same TypeScript source, so the API is identical apart from naming style. Luis prefers Python for the application layer:

Things happen here that took dozens of lines in YAML. add_listener and add_targets create the listener, the target group, the ASG registration and the security group rules needed for the ALB to reach the instances: the SourceSecurityGroupId of 09-01 is inferred by the CDK from the object graph. And scale_on_request_count creates the scaling policy with its associated CloudWatch alarm.

The integration layer is just as compact, and shows the 07-05 pattern with the dead letter queue:

add_subscription creates the subscription and the queue policy that lets SNS write to it, with the aws:SourceArn condition included. It is the twenty-line block from the 09-01 exercise solution, reduced to one call and impossible to forget.

There is one thing CloudFormation cannot do on its own and the CDK solves almost invisibly: uploading the code. A template can declare a Lambda function, but its code has to be in a bucket already, with a key that somebody had to fill in by hand or from a script. In 09-01 that stayed outside the template and the pipeline handled it.

The CDK's assets close that gap: during cdk deploy, the tool packages the given directory, computes its fingerprint, uploads it to the bootstrap bucket and substitutes the reference in the template.

Three practical consequences. The first: the content fingerprint is part of the asset name, so changing the code changes the asset and cdk diff detects it; if it does not change, the deployment does not touch the function. The second: add_event_source creates the event source mapping and the consumption permissions on the queue, including the KMS key. And the third, which is a warning: assets pile up in the bootstrap bucket and nobody deletes them, so the lifecycle rule in the cleanup section stops being optional after six months.

A nuance about the division of responsibilities. That the CDK can deploy the code does not mean it should in production: MercadoFresco keeps the 08-05 separation — the shop artefact is built once and CodeDeploy deploys it — and uses assets only for the Lambdas, whose code is small and tightly coupled to their infrastructure. Mixing the lifecycle of application code with that of infrastructure puts back together exactly what module 8 pulled apart.

cdk bootstrap deserves an explanation, because it is the part that confuses people most. It creates a stack called CDKToolkit with: an S3 bucket for artefacts (large templates, Lambda code, assets), an ECR repository for container images, and five IAM roles — deployment, asset publishing, lookup, CloudFormation execution and images. Without it, cdk deploy fails with an explicit message.

There are three things to know about bootstrapping: it is per account and per region, so deploying into us-east-1 for a CloudFront certificate means bootstrapping that region too; the version matters, and an old version causes cryptic failures that are fixed by running it again; and the roles it creates are powerful by default, with AdministratorAccess on the CloudFormation execution role, which in a shared account is a decision to be taken consciously — --cloudformation-execution-policies lets you narrow it down.

cdk diff is the day-to-day equivalent of the 09-01 change set, and its output marks with [-], [+] and [~] what gets deleted, added and modified, also flagging the changes that force replacement. MercadoFresco's rule is the same as there: no deployment without having read the diff.

Here we take on head-first the problem that shows up in every incident: pre-production is not the same as production. The CDK's answer is to make the three stacks come out of the same code, with one configuration file per environment as the only difference.

That leaves nine stacks with predictable names: MercadoFrescoRedProduccion, MercadoFrescoAplicacionPreproduccion, and so on. And the difference between environments is no longer an archaeological mystery: it is a twenty-line file you can read in ten seconds. The first time it was generated, Marta found three divergences that had been sitting there for months: pre-production had a single NAT declared as if it were production, log retention was 7 days in all three environments and the development CIDR overlapped with pre-production's.

Two important concepts in this block:

Explicit environments. If you leave out env, the stack is environment-agnostic and cannot use real account information: Vpc.fromLookup, the number of AZs or existing certificates. The CDK then generates templates with two fictitious AZs and surprises at deployment time. Always declare env with literal account and region.

Context and cdk.context.json. Lookups (fromLookup) query the account during synthesis and cache the result in cdk.context.json, which is versioned: it guarantees synthesis is reproducible and that the pipeline does not depend on live queries. When reality changes, it is refreshed with cdk context --clear. The practical rule: prefer explicit references over lookups, because a lookup is a hidden dependency on the state of the account.

Passing values between stacks is more natural than in 09-01: passing network.vpc to AplicacionStack makes the CDK create the CloudFormation export and import automatically. It is convenient and carries the same trap as there — an export in use is a lock — with an aggravating factor: the CDK creates it without you seeing it. If two stacks are going to evolve separately, it is still better to publish to Parameter Store and read with StringParameter.valueForStringParameter.

An aspect is a visitor that walks the whole construct tree and acts on every node. It serves two purposes that were impossible in YAML: applying something to all resources at once, and auditing rules against what is about to be deployed.

MercadoFresco's mandatory tagging is trivial with Tags, which is internally an aspect:

And an audit rule of your own is a twenty-line class:

Three details make the difference between this working and this producing false negatives. Aspects visit L1 constructs, so you have to check CfnBucket and not Bucket: L2s create L1s underneath and that is where the real properties live. addError stops synthesis, which turns the rule into a genuine quality gate rather than a warning nobody reads. And aspects run after the tree is built but before synthesis, so they can also modify resources — adding encryption instead of failing — although MercadoFresco prefers to fail: infrastructure that fixes itself hides the mistake instead of correcting it.

This is what cfn-guard did in 09-01 with a separate language. Here it is the same language, with the same editor, the same debugger and the same tests.

The 08-05 testing pyramid had an obvious gap: infrastructure was not tested. With the CDK it is, because a synthesised template is a JSON object you can assert against.

There are two families of tests and they serve different purposes:

MercadoFresco uses both with a strict rule: assertions cover what must never fail — six subnets, two NATs in production, no open SSH, encryption on every bucket — and snapshots act as a safety net. Plus a review rule: an updated snapshot in a PR obliges you to explain the diff in the description. Without that rule, jest -u becomes a reflex and the test stops being worth anything.

The real gain shows when upgrading aws-cdk-lib: the snapshot shows exactly what changed in the generated templates before anything is deployed. On a minor library upgrade, MercadoFresco discovered this way a change of default behaviour in a queue's encryption that nobody would have noticed.

The CDK's RemovalPolicy is the DeletionPolicy of 09-01, with one dangerous difference: L2 constructs choose a default value, and not always the one you expect.

And here is the real danger, which at MercadoFresco is concrete because the three environments share account 111122223333: cdk destroy --all does not ask which environment each stack belongs to. An --all launched from the wrong directory, or a cdk destroy MercadoFrescoRedProduccion with an unfortunate autocompletion, touches production. Three measures, in order of effectiveness:

1. deletion_protection and termination_protection on the production stacks, which make deletion fail in the service rather than in the goodwill of whoever types the command. cdk.Stack accepts terminationProtection: true.
2. Never --all in a human terminal. Production deployments come out of the pipeline; locally you name the stack in full.
3. Separate accounts, which is the real solution and arrives in 09-04. Until then, the two above are conscious patches.

One final nuance: RemovalPolicy.RETAIN leaves the resource orphaned, and the next cdk deploy will try to create another one with the same physical name and fail. It is the flip side of safety, and the reason fixed physical names — table_name, bucket_name — carry a cost, exactly as in 09-01.

One last piece of the module 8 asymmetry remains: the pipeline was created by hand. pipelines.CodePipeline solves that with a property called self-mutation: the pipeline is defined in the same repository as the infrastructure and, on every run, its first stage updates itself before deploying anything.

A Stage is a group of stacks deployed together — network, data, integration, application and observability for one environment — and the CDK infers the deployment order from the dependency graph between them. npm test runs the tests from the previous section, so a template that breaks a rule never gets deployed.

With this, MercadoFresco closes the module 8 circle: pipeline-mercadofresco-tienda deploys the application and pipeline-mercadofresco-infra deploys the infrastructure and itself. Adding a new stage is a PR, not a click in the console.

Two warnings. The first: a self-mutating pipeline is powerful and dangerous — whoever can merge into main can change the pipeline itself — so the branch protection of 08-01 and mandatory review stop being good practice and become a security control. The second: the synthesis stage needs lookup permissions, so a versioned cdk.context.json is not optional if you want reproducible synthesis.

Terraform, from HashiCorp, is the most widely used multi-provider alternative: its own declarative language (HCL), state in a file that has to be stored and locked, and providers for AWS, Azure, GCP, Datadog or GitHub. CDK for Terraform (CDKTF) lets you write Terraform configuration with TypeScript or Python, just as the CDK does with CloudFormation.

The recommendation is simple and does not depend on taste. If everything is in AWS, CloudFormation or CDK, because managed state and automatic rollback are real advantages that come dear in Terraform. If there are several providers — AWS plus Cloudflare, plus GitHub, plus Datadog — Terraform wins, and the cost of maintaining the state is justified. MercadoFresco is entirely in AWS and already has the pipeline built on native services: switching would be work with no return.

The CDK is free; bootstrapping leaves a bucket, an ECR repository and five roles whose cost is negligible while they sit empty. It is worth putting a lifecycle rule on the asset bucket, though, which grows with every deployment and does not clean itself.

The order matters for the same reason as in 09-01: consumers first, network afterwards. If a stack refuses to be deleted, the cause is usually an export in use or a bucket with objects, and it is diagnosed in the CloudFormation events, not in the CDK.

Mistake: changing the id of a deployed construct. Renaming 'Vpc' to 'VpcPrincipal' recreates the resource, exactly as in 09-01. Tip: ids are immutable in practice; if you really must reorganise, cdk diff warns you — read it — and overrideLogicalId lets you keep the previous identifier.

Mistake: deploying without cdk diff. The CDK makes deploying so easy that people skip the preview. Tip: cdk diff on every PR, posted as a comment, and --require-approval any-change in production.

Mistake: stacks without an explicit env. They produce templates with two fictitious AZs and fromLookup does not work. Tip: declare env with literal account and region on every stack.

Mistake: cdk destroy --all in the shared account. It is MercadoFresco's concrete risk until 09-04. Tip: terminationProtection: true on production stacks, always name the stack, and never --all outside a test environment.

Mistake: updating snapshots with -u without looking. It turns the test into decoration. Tip: require in review that every updated snapshot comes with an explanation of the diff.

Mistake: assuming the L2 does what you would do. ec2.Vpc makes dozens of decisions for you. Tip: cdk synth and read the template the first time you use a new construct; it is the only way to know what you actually asked for.

Tip: pin the aws-cdk-lib version and upgrade it deliberately. With snapshot tests, every upgrade shows you exactly what changes in the templates before you touch anything.

Tip: use the grant* methods instead of writing policies. They generate genuine least privilege, including the KMS permissions almost everyone forgets.

Tip: do not put business logic in infrastructure code. The CDK invites you to, being a full language. A stack that reads a database during synthesis is a stack that cannot be synthesised in the pipeline.

Write your own construct ColaMercadoFresco (TypeScript or Python) that wraps the 07-05 pattern: a main queue with its dead letter queue, encryption with alias/mercadofresco-datos, a configurable maxReceiveCount defaulting to 5, 14-day retention on the DLQ, and a CloudWatch alarm that fires when the DLQ has messages. It must expose the main queue, the DLQ and a concederConsumo(rol) method. Use it to create MercadoFresco's four queues. State which RemovalPolicy you put on each queue and why.

Write four tests for RedStack and AplicacionStack that verify invariants MercadoFresco genuinely cares about: (a) that production has two NATs and development one; (b) that no data subnet has a route towards a NAT; (c) that the ALB only accepts HTTPS; (d) that every taggable resource carries the five mandatory tags. For each one, say whether you would solve it with an assertion or a snapshot and why, and what would be needed besides the test for the rule to always hold.

MercadoFresco already has the mercadofresco-red-produccion stack deployed from the 09-01 YAML template, with the VPC and the six subnets in production. Marta wants to move that stack to CDK without recreating anything and without service downtime. Describe the complete strategy: what options exist, which one you pick and why, what commands you run, how you check the migration will change nothing, and what you do if cdk diff shows differences. Explain as well the concrete risk of the option you discard.

Solution 1

The removal policies. The DLQ is always RETAIN, in every environment: it holds messages that were not processed and that somebody will have to examine; deleting it when a stack is destroyed destroys the evidence of an incident. The main queue, RETAIN in production and DESTROY elsewhere: in production there may be in-flight messages whose loss would be lost orders, whereas in development a leftover that stops the stack being recreated costs more than it protects.

And one detail you notice after using it four times: the four-line loop replaces a hundred and twenty lines of YAML with twelve resources, and it guarantees the four queues have exactly the same configuration — encryption, retries, alarm — which is precisely what does not hold at MercadoFresco today.

Solution 2

(a) Assertion. It is a business invariant with two concrete values, and the test expresses it better than any snapshot could. It also survives refactoring: if the constructs are reorganised tomorrow, the test still holds.

(b) Assertion, but indirect. Checking that "no data subnet has a route to a NAT" means following the relationship between RouteTable, Route and SubnetRouteTableAssociation in the template, which is tedious. The pragmatic approach is to assert that no AWS::EC2::Route with a NatGatewayId belongs to a table associated with a datos subnet, and to lean on the fact that the CDK guarantees the property by construction when you use PRIVATE_ISOLATED. The test is worth having as a safety net against a change of subnet type.

(c) Assertion, with the negative part included. Checking that a 443 listener exists is not enough: what matters is that none exists on port 80 without a redirect. Tests that only verify presence let through precisely the errors of addition, which are the ones that actually happen.

(d) Neither assertion nor snapshot: an aspect. A test walking every resource checking tags is fragile, because many types do not accept them and you would have to maintain the list of exceptions. The right answer is an aspect that fails synthesis if a mandatory tag is missing, plus a test that the aspect is registered in the App. You test the mechanism, not each instance.

What is needed besides the tests. None of this is worth anything if the tests do not block: they have to run in npm test inside the CDK Pipelines synthesis stage, and the build must fail, not warn. It is the same conclusion as 08-02, applied to infrastructure: a check that does not block is documentation.

Solution 3

There are two options and they are not equivalent.

The first is to recreate the network in CDK and migrate: deploy a new VPC alongside the old one, move the instances, the database and the ALB, and delete the old one. It is conceptually clean and it is the one to discard, because it means moving Aurora and the ALB between VPCs: endpoint changes, a cutover window, risk to customer data and, above all, zero benefit — the resulting network is identical. All the risk, none of the gain.

The second, the chosen one, is to have the CDK adopt the existing stack. The key point is that a CloudFormation stack does not know whether its template was written by a person or by the CDK: it only compares logical identifiers. If the synthesised template is equivalent, the update touches no resource.

The procedure. You write the CDK stack with the same stack name, mercadofresco-red-produccion, and force the logical identifiers to match those in the YAML template, using overrideLogicalId resource by resource:

The check, which is the heart of the exercise:

An empty cdk diff is the acceptance condition. As long as it shows anything, nothing gets deployed.

If it does show differences, there are three cases. If they are only CDK metadata (CDKMetadata, the analytics version) they are accepted: they affect no resource. If they are cosmetic properties — a description, a tag — it is decided case by case and documented. And if there is any [~] with replacement or any [-], you stop: it means the generated template is not equivalent and the code has to be adjusted until it is. A [-] on a production subnet is exactly the disaster this migration exists to avoid.

The safety net, in two steps. Before anything else, --enable-termination-protection on the stack and DeletionPolicy: Retain on the critical resources, so that not even a serious mistake destroys anything. And the full rehearsal first in development, then in pre-production and only then in production, which is the same promotion order as 08-04 applied to infrastructure.

The same infrastructure, in a programming language. The 190 lines of YAML for the network have become 28 lines of TypeScript that synthesise an equivalent template, and the six almost identical subnets have vanished inside a three-entry subnetConfiguration that the CDK multiplies per AZ. What has not changed is what lies underneath: the CDK does not replace CloudFormation, it writes the templates for you, and the change sets, drift, ROLLBACK_COMPLETE and deletion policies of 09-01 still govern what actually happens.

You have the three construct levels — the L1 that copies CloudFormation, the L2 with safe defaults and grant* methods that generate least privilege, and the convenient, opaque L3 — with the node.defaultChild escape hatch to drop a level when the API falls short. You have your own construct, MercadoFrescoVpc, which is the difference between a three-column table and a real abstraction: an improvement to the pattern reaches all three environments at once. And you have the complete lifecycle, with cdk bootstrap explained — the bucket, the ECR repository and the five roles, per account and region, with administrator permissions that must be narrowed down consciously — and with the rule inherited from 09-01: no deployment without having read the diff.

The three environments now come out of the same code, and the difference between pre-production and production has stopped being archaeology: it is config/entornos.ts, twenty lines readable in ten seconds, which the first time it was written exposed three divergences that had been sitting there for months. With explicit environments on every stack — no env means no lookups and yes fictitious AZs — and a versioned cdk.context.json so synthesis is reproducible in the pipeline.

And infrastructure finally enters the 08-05 testing pyramid. Aspects apply mandatory tagging in one go and audit rules — unencrypted buckets, port 22 open — with addError, which stops synthesis instead of warning; always visiting L1 constructs, which is where the real properties live. Assertions cover what must never fail and snapshots act as a safety net, with the review rule that keeps them alive: an updated snapshot obliges you to explain the diff. Plus CDK Pipelines, which closes the module 8 asymmetry by deploying the infrastructure and updating itself — and which turns the branch protection of 08-01 into a security control, because whoever merges into main changes the pipeline.

One risk remains, flagged three times and unresolved: cdk destroy pointed at production. Termination protection and the discipline of always naming the stack are conscious patches, not solutions, because the underlying problem is that the three environments share account 111122223333. While that stays true, a mistyped command, a forgotten environment variable or an --all in the wrong directory can reach the shop in production. And the blast radius is not the only issue: quotas are shared, a development deployment can exhaust production's elastic IP limit, the bill does not really separate and no IAM policy fully isolates someone who already has broad permissions in the account.

In 09-03, "AWS Elastic Beanstalk", we take a step back to look at the managed alternative: what a platform as a service does for you, when it would have been the right decision for MercadoFresco — and why it no longer is. After that, 09-04, "AWS Organizations", attacks the underlying problem: genuinely separating environments into different accounts, with service control policies, consolidated billing and a baseline that deploys itself into every new account.