DEV Community: Alex

Terraform Modules vs CDK Constructs | What the Extra Layers Change

Alex — Wed, 29 Jul 2026 17:14:48 +0000

Terraform gives you two layers of abstraction. CDK gives you four. That difference decides how much your own module has to justify itself, and what a refactor costs you a year later.

The problem

Teams moving between the two tools compare the syntax. HCL against TypeScript, terraform plan against cdk diff, state files against CloudFormation. The syntax is the smallest difference of the three.

The larger one is how many layers sit between a line of your code and a resource in the account, and where that resource's identity comes from. In Terraform the identity is something you write. In CDK it is something the layer structure computes for you.

That sounds academic until a pull request that changes no behaviour deletes a bucket.

Terraform has two layers. CDK has four.

In Terraform there is the provider resource, and there is the module you write around it. That is the entire ladder. When a guide says "write a module", it means: wrap raw resources, add defaults, validate inputs, expose outputs.

CDK adds two rungs before you write anything.

Layer	What it is
L1 (`CfnBucket`)	Auto-generated from the CloudFormation resource spec. One construct, one resource, no defaults, raw property shapes.
L2 (`Bucket`)	Hand-written by AWS. Opinionated defaults, typed enums, helper methods. Can emit several resources.
L3 (patterns)	Several L2s wired together for a use case.
Your wrapper	Whatever your organisation adds on top.

The consequence is easy to miss: an L2 already is a module in the Terraform sense. Curated, opinionated, typed inputs, sensible defaults, maintained by someone else. When you write your own construct around s3.Bucket, you are writing a module around a module.

The layer count is not just conceptual, it shows up in the template. A plain L1 CfnBucket synthesises to exactly one resource. The L2 Bucket with enforceSSL: true and autoDeleteObjects: true synthesises to five: the bucket, a bucket policy, a custom resource, an IAM role and a Lambda function. One line of props, four extra resources, one of which executes code in the account.

Neither number is wrong. They are different amounts of decision made on your behalf.

Identity is where the layers bite

In Terraform, a resource's identity is the address you wrote: aws_s3_bucket.bucket. It is in the file. You can grep for it.

In CDK, identity is the CloudFormation logical ID, and CDK computes it by hashing the construct's path through those layers. You never write it. It does not appear anywhere in your source code.

Here is the same bucket, bucketName: "demo" throughout, synthesised on aws-cdk-lib 2.189.1:

Change to the code	Logical ID
baseline: `new s3.Bucket(this, "Bucket", …)`	`Bucket83908E77`
added `versioned`, a lifecycle rule, a new output	`Bucket83908E77`
renamed the TypeScript class	`Bucket83908E77`
renamed the construct id to `"Storage"`	`Storage07F31EBC`
extracted the bucket into a `SecureBucket` construct	`BucketD7FEB781`
added a grouping parent construct	`StorageBucket5CB7C8EA`

Properties are free. Class names, file names and variable names are free. What is not free is the id strings on the path from the stack down to the resource, and how many levels sit between them.

The middle three rows are the interesting ones. Adding versioning and a lifecycle rule changes real infrastructure behaviour and the identity holds. Extracting a construct changes no behaviour at all and the identity moves.

What CloudFormation does with that

It matches resources on the logical ID alone. Not on the bucket name, not on the properties. So the extraction reads as one resource removed and a different one added:

[-] AWS::S3::Bucket Bucket        Bucket83908E77   destroy
[+] AWS::S3::Bucket Bucket/Bucket BucketD7FEB781

cdk diff reports it accurately. The word destroy is right there. The difficulty is upstream of the diff: the pull request that produced it contains no bucket name, no property change and no resource. It contains a class extraction and two changed lines, which is normally the safest kind of change a reviewer sees. And the two logical IDs both begin with Bucket, differing only in eight hex characters.

With the default removal policy the same diff reads orphan instead of destroy, which leaves the old bucket behind in the account, unmanaged and still billing. Which of the two you get depends on a removal policy set somewhere else in the file.

The same trap has a name in Terraform

Terraform has this problem too. Rename a resource inside a module and consumers get a destroy and create.

The difference is that Terraform ships a repair tool:

moved {
  from = aws_s3_bucket.bucket
  to   = module.secure.aws_s3_bucket.bucket
}

That block lives inside the module. It travels with the version bump. A consumer who upgrades runs plan and reads "has moved to", followed by no changes. Once every consumer is upgraded, the author deletes the block in a later major.

CDK's equivalent arrived later and works differently. The cdk refactor command, in preview and gated behind --unstable=refactor, compares your code against the deployed state, detects constructs that have been renamed or moved, and uses CloudFormation's refactoring API to preserve the resources while their logical IDs change. AWS names this exact case in the command's documentation: "Reorganize your construct hierarchy (like grouping AWS resources under a new L3 construct) while preserving the underlying cloud resources."

That closes the gap, but not in the same place moved closes it. Terraform's block is written by the module author and travels inside the module, so a consumer repairs the break by upgrading and reading plan. cdk refactor is run by whoever owns the deployment, against deployed state, after the change has landed. For a construct published to other teams, the author can cause the break and cannot ship the fix.

It also refuses to run on a mixed change. The command verifies that the application contains exactly the same set of resources as the deployed state, differing only in their location in the construct tree, and rejects the operation if it detects any resource additions, deletions or modifications. A pull request that extracts a construct and adjusts a property in the same commit is not refactorable by it.

The older manual route is still there: reaching through the L2 to the L1 underneath and pinning the old value by hand.

const cfn = bucket.node.defaultChild as s3.CfnBucket;
cfn.overrideLogicalId("Bucket83908E77");

Three things separate that from moved. You have to know the hash, which means synthesising the old version or reading the deployed template. It cannot be removed later, because removing it changes the identity again. And it documents nothing: the code says SecureBucket/Bucket while claiming an identity from a shape that has not existed since the previous release.

Why this compounds with the layer count

The two findings are the same finding. Logical IDs are derived from the path through the layers, so every layer you add or remove is an identity change. Terraform's flatter ladder means fewer opportunities to move something by accident, and its repair is declarative, stable, and shipped by the author to the consumer. CDK has more rungs to move between, and its repair is a preview command run by the operator after the fact.

CDK's extra rungs buy real things: the L2s carry AWS's own defaults, and the assertion tests that check them run in milliseconds with no cloud credentials, which is a tier most Terraform teams never reach. The rungs are also the mechanism by which a tidy-up deletes a database.

The options

Keep the construct tree flat. Resources sit directly in the stack. Fewer levels means fewer identity changes available. Composition happens by writing a new stack rather than restructuring an existing one. Cheap while nothing is deployed, and the decision is effectively frozen at the first deploy.

Pin logical IDs by hand. overrideLogicalId or stack.renameLogicalId. Lets you restructure freely at the cost of a permanent hardcoded hash for every resource you move.

Diff the synthesised template in CI. Synthesise the previous release and the current commit, extract the logical IDs from both, fail the build when an existing one disappears. Catches the class of change rather than repairing it, and it makes the invisible part visible in the pull request where the decision is actually made.

Retain on delete for stateful resources. RemovalPolicy.RETAIN turns a deletion into an orphan. The resource survives, unmanaged, and the deploy may still fail if the physical name is taken.

cdk refactor. Preview, behind --unstable=refactor. Detects moved or renamed constructs and calls CloudFormation's refactoring API to keep the resources while their logical IDs change. --dry-run prints the mapping without applying it, and an override file resolves cases where more than one mapping is valid. Costs you a preview dependency, and it rejects any change that is not purely a relocation.

Where each one fits

A flat tree fits work where nothing is deployed yet and the abstraction is not yet earned. The cost is that a shared construct extracted later is a migration, not a refactor. Before the first deploy that decision is free, and it stops being free permanently on the day something exists in the account.

Hand-pinned logical IDs fit a small number of deliberate moves in an application stack you own end to end. They stop fitting in a shared construct library: the hashes accumulate across releases, and after the third one the tree's real identity lives in a pile of hex strings rather than in its shape.

Template diffing in CI fits anyone publishing constructs that other teams consume by version. There, a refactor by the author is a destroy in someone else's account, and the author is the only person positioned to catch it. It fits less well on a single application stack with one reviewer who already reads every diff.

cdk refactor fits a team that owns both the code and the deployment, can accept a preview command in the path to production, and is willing to split a restructuring commit from a behaviour commit so the command will accept it. It fits worst in the case that motivated this comparison: a construct library whose consumers are other teams. There the break travels with the version bump and the repair does not, so every consumer runs it separately in their own account, or does not run it at all.

Retain on delete fits databases, state buckets and anything holding data, in every setup. What it does not do is prevent the identity change, so it pairs with one of the options above rather than replacing them.

The layer question sits underneath all of this. If your organisation's wrapper adds real policy, naming guarantees and validated inputs that an L2 cannot express, the extra rung is doing work. If it forwards properties to s3.Bucket with a longer name, it is a layer of identity risk that buys nothing, and Terraform's guidance applies unchanged: a module wrapping one resource with pass-through variables is not abstraction.

Want us to look for issues like this in your account? We offer a free AWS audit: upstood.com

NAT Gateway, VPC Endpoints, or an Egress Proxy: What Each Way Out of Your VPC Costs

Alex — Tue, 21 Jul 2026 12:25:43 +0000

Most private subnets reach the internet through a NAT gateway. It is metered per gigabyte, and it keeps no record of where those gigabytes went. Both of those facts carry a price, and there are two other ways to route the same traffic.

The problem

Most private-subnet workloads reach the internet through a NAT gateway. It is one click in the console and it works, so it is rarely revisited after the day the VPC was built.

A NAT gateway charges two ways. It costs $0.045 an hour just to exist, about $33 a month per gateway. It then costs another $0.045 for every gigabyte it processes (us-east-1, AWS VPC pricing, checked July 2026). The hourly charge is small. The data processing charge scales with traffic, and it applies to all outbound traffic, including traffic to AWS services that never needed to leave the AWS network at all.

It also keeps no record of its own. A NAT gateway does not log which destinations your workloads reached, and it does not filter them. For a security or compliance review, the questions "what is this environment allowed to reach" and "what did it actually reach" have to be answered somewhere else.

The finding

Two separate costs come from the same property: everything leaves through one unfiltered, metered pipe.

The first is that a large share of "internet" traffic is not internet traffic. Container image pulls, S3 reads, CloudWatch Logs, Secrets Manager calls: all of it is AWS traffic routed out through the NAT gateway and billed at $0.045 per gigabyte. Container platforms concentrate this. Every task launch and every scale-out pulls image layers, and on a busy cluster that is gigabytes an hour.

Here is the math on a platform moving 2 TB of egress a month, split 1.4 TB of AWS-service traffic and 0.6 TB of genuine internet traffic. Through a single NAT gateway that is about $33 for the hourly charge, $90 for data processing on the full 2 TB, and $54 of data transfer out for the 0.6 TB that actually reaches the internet ($0.09 per gigabyte, first 10 TB, checked July 2026). Roughly $177 a month, of which $63 is processing charges on traffic that stayed inside AWS. At 20 TB of egress, the processing charge alone is $900 a month.

The second cost is visibility, and it arrives as a separate bill. VPC Flow Logs capture IP addresses and byte counts. Route 53 Resolver query logs capture the domains that were looked up. Both are metered: log delivery is billed per gigabyte of logs, $0.50 to CloudWatch Logs or $0.25 to Amazon S3, plus storage (CloudWatch vended-logs pricing, checked July 2026). Adding GuardDuty to flag suspicious egress is another $1.00 per gigabyte analyzed for the first 500 GB a month (Amazon GuardDuty pricing, checked July 2026). What that buys is a record of IP addresses after the fact. Against destinations behind a CDN, where many services share rotating addresses, that record often does not identify who the workload talked to, and none of it blocks anything.

The options

Three ways to route outbound traffic, and what each one costs.

The NAT gateway on its own

Managed, highly available within an Availability Zone, and it handles any protocol. Nothing to patch, nothing to scale, no failure mode you own. It costs $0.045 an hour plus $0.045 per gigabyte processed, applied to every byte regardless of destination, and it provides no destination logging or filtering of its own.

VPC endpoints for AWS-service traffic

A gateway endpoint for S3 costs nothing: no hourly charge, no data processing (AWS VPC pricing, checked July 2026). Because container image layers are stored in S3, it carries the heaviest AWS-bound flow most platforms have. Interface endpoints, including the two ECR endpoints (ecr.api and ecr.dkr) that complete a fully private image pull, cost $0.01 per hour per endpoint per Availability Zone plus $0.01 per gigabyte (AWS PrivateLink pricing, checked July 2026), under a quarter of the NAT processing rate (Amazon ECR docs, "Amazon ECR interface VPC endpoints").

Endpoints only move AWS-service traffic. They do nothing for third-party APIs or package registries, and each interface endpoint adds a fixed hourly cost per Availability Zone whether or not it is busy. On the 2 TB example, moving AWS traffic onto endpoints takes the $90 processing charge down to a few dollars, against the endpoint hours added.

A self-managed egress proxy

A forward proxy such as Squid on a small instance in a public subnet, with the private subnets given no default route to the internet at all. Applications reach outside only through the proxy via HTTPS_PROXY, which makes the proxy the single path out. A t3.small runs about $15 a month.

On cost, this takes the $0.045 per gigabyte NAT processing charge off internet-bound traffic. It does not touch data transfer out, which stays at $0.09 per gigabyte because those bytes genuinely leave AWS.

On visibility, the proxy brokered the connection, so its log already carries the hostname and the allow or deny decision, and domains can be allow-listed. That is a different kind of record from flow logs, and it does not need a separate log-delivery and threat-detection pipeline to turn IP addresses back into names.

What it costs elsewhere: it is infrastructure you own, keep available, patch and scale. It handles HTTP and HTTPS well and gets awkward with arbitrary TCP or UDP, which needs a transparent-proxy setup or a NAT gateway retained for those flows. It filters by domain on the TLS handshake and does not inspect inside encrypted connections without full interception, which carries its own risks and obligations.

Where each one fits

The NAT gateway's economics turn on volume. Below a few hundred gigabytes a month the processing charge is a rounding error and the hourly charge dominates, so the managed option is cheap in both money and attention. The crossover arrives when per-gigabyte processing outgrows the fixed cost of the alternatives: interface endpoint hours, or a proxy instance somebody maintains.

The AWS-service share is the second variable. A workload that pulls container images constantly sends most of its "egress" to S3 and ECR, where a free gateway endpoint applies. A workload that mostly calls third-party APIs sees little from endpoints, and whatever it saves comes from the proxy path or from nowhere.

Visibility moves independently of cost. If nothing needs to prove what the environment can reach, flow logs enabled on demand may be all the record required, and their per-gigabyte charge applies only while they run. If an auditor, a customer security review, or a data-residency obligation calls for a stated allow list and evidence of what actually left, that is not something a NAT gateway produces at any price, and the comparison stops being about dollars.

Operational appetite is a real cost, not a soft one. A proxy is a component with an on-call story attached. A team without the capacity to own one is weighing an operational risk against a line on the bill, and which way that lands depends on the team, not on the architecture.

Want us to look for issues like this in your account? We offer a free AWS audit: upstood.com

Is Multi-AZ Enough for Disaster Recovery? What DORA Actually Asks of Your Application

Alex — Wed, 15 Jul 2026 20:05:50 +0000

Some companies run their disaster recovery across availability zones. Each AZ is a separate datacenter, so three AZs are three sites. Others maintain a second region, because to them a recovery site belongs somewhere else entirely.

Both camps call it disaster recovery. Both have a point. And DORA, the regulation both camps worry about, does not pick a side.

DORA never mentions availability zones or multi-region. It asks a different question: for each application, how long can you afford to be down, how much data can you afford to lose, and can you prove it? That has a different answer per application. This article shows what each setup actually protects against and what the regulation actually requires, so you can answer it for yours.

The problem

Ask two engineering teams about disaster recovery and you get two confident, opposite answers.

The first team says: "we're multi-AZ". The reasoning is sound. AWS availability zones are physically separate datacenters, kilometers apart, with independent power, cooling, and physical security. Three AZs are three sites. Why would that not count as disaster recovery?

The second team says: "we have a standby in a second region". Also sound. A disaster that takes out the whole region takes every AZ with it. A recovery site should not share fate with the primary.

Then an auditor, a compliance framework, or a customer due-diligence questionnaire enters the room, usually citing DORA. It asks: what are your recovery objectives? Where is your secondary site? What happens if your provider's region fails? Both teams go looking for the sentence in the regulation that blesses their architecture. Neither finds it. It does not exist.

So we went to the primary sources: the regulation text, AWS's own documentation, and the post-mortem of the largest cloud outage in recent memory.

The finding

1. What DORA actually asks: objectives, not architecture

DORA, the EU's Digital Operational Resilience Act for financial entities, is the strictest widely-applicable regime here. That makes it the useful worst case. We searched the full text of the regulation and its ICT risk management RTS. The words "availability zone" and "multi-region" never appear. "Region" appears exactly once, in a clause about disclosing where a vendor processes data.

What DORA requires of a financial entity (Art. 12) is technology-neutral. Maintain "redundant ICT capacities equipped with resources, capabilities and functions that are adequate to ensure business needs". Restore backups on systems "physically and logically segregated from the source ICT system". Set recovery time and recovery point objectives per function, yourself, based on how critical the function is.

DORA does contain a "secondary processing site" requirement, in Article 12(5). It applies to central securities depositories, and the accompanying technical standards extend it to central counterparties. Those are the market infrastructures the rest of the financial system runs on. The requirement does not bind a typical bank, and it does not bind a SaaS vendor.

Even there, the language is about risk, not technology. The secondary site must sit "at a geographical distance from the primary processing site to ensure that it bears a distinct risk profile and to prevent it from being affected by the event which has affected the primary site". During the public consultation on the technical standards, respondents asked the three European Supervisory Authorities (EBA, ESMA and EIOPA, who drafted them) whether "secondary processing site" refers to secondary data centres. The authorities kept the risk-based wording and declined to name any technology (Final Report JC 2023 86, p. 173).

If you are a SaaS company, you are most likely not in DORA's direct scope at all. You meet it indirectly, through contract clauses and due-diligence questionnaires from financial customers. So the question you have to answer is the regulator's question: does your recovery setup bear a distinct risk profile from your primary, per application, and can you prove your recovery objectives? Neither "we're multi-AZ" nor "we have a second region" answers that by itself.

2. What the multi-AZ camp actually has

The multi-AZ camp is right about the physical world, and AWS backs them.

AZs are physically separate facilities, many kilometers apart, with independent power, cooling, and physical security. AWS's own disaster recovery whitepaper, Disaster Recovery of Workloads on AWS: Recovery in the Cloud, says plainly: "a multi-AZ architecture within an AWS Region may already meet much of your risk mitigation needs". A fire or a flood that takes out one datacenter is a disaster your multi-AZ architecture recovers from by design. For that risk profile, three AZs really are three sites.

But the same whitepaper has a section titled, in full, "High availability is not disaster recovery". The distinction: "Availability focuses on components of the workload, whereas disaster recovery focuses on discrete copies of the entire workload." And its "Disaster recovery options in the cloud" section draws the boundary precisely: "If your definition of a disaster goes beyond the disruption or loss of a physical data center to that of a Region or if you are subject to regulatory requirements that require it, then you should consider Pilot Light, Warm Standby, or Multi-Site Active/Active."

So AWS's position, in our words: multi-AZ is disaster recovery for datacenter-scale disasters. It is not disaster recovery for region-scale disasters. Which leaves one question: how often are disasters region-scale?

3. What the second-region camp actually has, and the outage that tested both

On October 19-20, 2025, us-east-1 suffered roughly 14 hours of cascading impact. The root cause, from AWS's own post-event summary: "a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record for the service's regional endpoint". One automation bug deleted the DNS records for DynamoDB's regional endpoint. The failure cascaded into EC2 launches, network load balancers, Lambda, and STS. Downdetector logged over 6.5 million reports across more than 1,000 services.

Here is what it means for the multi-AZ camp: every availability zone in the region was affected equally. The event was not a flood that your second AZ sits outside of. It was a software defect in a regional control plane, and all your AZs share that control plane. Against the failure mode that actually happened, multi-AZ provided zero isolation. And this keeps happening: December 2021, network congestion in us-east-1 disrupted sign-in globally. November 2020, a Kinesis failure took down Cognito authentication. The big cloud outages are software, not floods.

But the same outage carries a warning for the second-region camp. Some global AWS services are homed in us-east-1: the IAM control plane, console sign-in and identity federation, parts of Route 53. During the outage, customers in other regions could not sign in with federated identities and could not modify IAM roles or policies. Redshift customers "in all AWS Regions were unable to use IAM user credentials for executing queries". AWS's own Support Center "successfully failed over to another region as designed", and then broke anyway, because a subsystem it depended on had not. A second region is not automatically a distinct risk profile either. It only is if the failover path has no hidden dependency on the failed region.

So the honest scorecard. An availability zone gives you a distinct physical risk profile and an identical software risk profile. A second region gives you a distinct software risk profile only if you engineered the dependencies out. And the regulator's phrase "the event which has affected the primary site" covers both kinds of event.

The fix

Stop asking which camp is right. Decide per application, from recovery objectives. The technology follows.

Set RTO and RPO per application, as a business decision. Recovery Time Objective: the maximum acceptable delay between interruption and restoration. Recovery Point Objective: the maximum acceptable data loss, measured in time. This is exactly what DORA asks the entity to define per function. Most companies have never written them down. That absence is the real audit finding, not the architecture.
Map each application to one of the four AWS strategies. AWS's Well-Architected guidance (Reliability Pillar, REL13-BP02) gives the honest numbers. Backup and restore: RPO in hours, RTO in 24 hours or less. Pilot light: RPO in minutes, RTO in tens of minutes. Warm standby: RPO in seconds, RTO in minutes. Multi-site active-active: RPO near zero, RTO potentially zero. Cost and operational complexity climb steeply along that ladder.
The multi-AZ camp, done right: add cross-region backups. Run highly available in one region. Continuously back up to a second region: segregated copies, restorable on segregated systems, which is the exact backup-segregation language regulators use. Accept an honest RTO measured in hours for the rare region-scale event. For every application whose true business tolerance is a day, this is a legitimate, defensible DR strategy, and dramatically cheaper than a standby region.
The second-region camp, done right: engineer out the hidden dependencies. For the few applications that genuinely cannot be down for hours, build the standby region so it actually bears a distinct risk profile. Fail over using data plane operations only: control planes have lower availability design goals, and a control plane is exactly what broke in October. Use regional STS and sign-in endpoints, not the global ones homed in us-east-1. Pre-provision quotas and capacity. Make the failover decision independent of the failing region.
Test it and write it down. A recovery objective you have never tested is a guess. This is also the letter of the regulation: DORA Art. 11(6) requires testing continuity and recovery plans at least yearly, with scenarios that include "switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities". The artifact that satisfies an auditor, and a prospect's due-diligence questionnaire, is documented objectives per application plus evidence of a tested recovery. Not an architecture diagram with two of everything.

Impact

Which camp is right? Both, for different applications.

Multi-AZ plus segregated cross-region backups is a compliant, defensible answer for every application that can tolerate hours of recovery, and that is most of them. A properly engineered second region is the answer for the few that cannot. What DORA asks for is neither architecture. It asks for written recovery objectives per application, segregated restorable backups, and proof.

Teams that adopt this framing stop overbuilding and underproving. DR spend becomes proportional to each application's actual tolerance, instead of one anxious architecture decision applied to everything. And the due-diligence answer changes. "We're multi-AZ" and "we have a second region" both invite follow-up questions. "Here are our recovery objectives per application and the test evidence" ends them.

Want us to look for issues like this in your account? We offer a free AWS audit: upstood.com

Session Manager removes your public IPs. Is it enough for an audit?

Alex — Sun, 12 Jul 2026 13:49:54 +0000

Every public IP on an EC2 instance exists for one of two reasons: the instance serves the internet, or somebody needs to SSH into it. The second reason stopped being valid years ago, and it is still the most common one we see.

The problem

Instances get a public IP so an engineer can reach them over SSH. That single decision drags a chain of exposure behind it: a security group with port 22 open (often to 0.0.0.0/0 "temporarily"), key pairs shared over Slack and never rotated, an internet gateway route on subnets that never needed one, and a bastion host that is itself another public instance with another key pair.

From an audit standpoint, every one of these is a finding. From an attacker's standpoint, every public IP is scanned within minutes of being assigned. And from an operations standpoint, none of it is necessary: AWS Systems Manager Session Manager gives you a shell on any instance with zero inbound ports, zero public IPs, and zero SSH keys.

The biggest advantage deserves to be stated plainly: port 22 is not restricted, it is closed. Not narrowed to an office IP, not hidden behind a bastion: there is no listening port to protect at all, because access happens over the web. The shell opens in a browser tab from the AWS console (or from the CLI), authenticated by the IAM login the engineer already has.

We have applied this in two very different settings, and the experience splits cleanly. In startups and small companies, Session Manager is a pure win: public IPs disappear, key management disappears, and engineers open a shell on any instance on the fly from the console or CLI. In enterprises, the network part is just as easy, but a different question stops the rollout: once everyone enters the VM through the same door, how do you prove who did what inside it? That question, and what to ship to the SIEM, is where most of this article lives.

The finding

Session Manager inverts the connection model. The SSM Agent on the instance opens an outbound HTTPS connection to the Systems Manager service and waits. When you start a session, the service brokers it over that existing outbound channel. Nothing ever connects inbound to the instance, so there is nothing to expose. That inversion is what makes the browser shell possible: the operator's session rides the agent's outbound channel, which is why port 22 can stay closed on every instance in the fleet.

Three things have to be true for this to work, and they are smaller than most teams expect.

1. The minimum instance role

The instance needs an instance profile whose role allows the SSM Agent to talk to the service. The managed policy AmazonSSMManagedInstanceCore is the supported baseline. If you want the actual minimum instead of the managed policy, this is what the agent needs for sessions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ssmmessages:CreateControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:OpenDataChannel"
      ],
      "Resource": "*"
    }
  ]
}

Add s3:GetEncryptionConfiguration and s3:PutObject on your logging bucket, or logs:CreateLogStream and logs:PutLogEvents on your logging group, if you enable session logging (you should, see below). Add kms:GenerateDataKey and kms:Decrypt on the session KMS key if you encrypt sessions (you should as well).

Note what is not in this policy: nothing. No inbound rule, no key material, no ec2:*. The instance role is the entire server-side setup.

2. The minimum user policy

On the operator side, scope ssm:StartSession to the instances the person is allowed to reach. Tag-based scoping keeps this manageable:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": { "ssm:resourceTag/Environment": "dev" }
      }
    },
    {
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": "arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ssm:TerminateSession",
        "ssm:ResumeSession"
      ],
      "Resource": "arn:aws:ssm:*:*:session/${aws:username}-*"
    }
  ]
}

The session-document statement matters: without pinning the document, a user who can start any session can bypass your logging preferences by choosing a different session document.

3. The network path (the "firewall")

The agent needs outbound HTTPS to three service endpoints: ssm, ssmmessages, and ec2messages. In a private subnet with no NAT, that means three interface VPC endpoints:

com.amazonaws.<region>.ssm
com.amazonaws.<region>.ssmmessages
com.amazonaws.<region>.ec2messages

The security group on the endpoints allows inbound 443 from the instance security groups (or the VPC CIDR). The instance security group needs outbound 443 to the endpoint security group and nothing else. No inbound rules at all. If session logs go to S3 or CloudWatch, add the s3 gateway endpoint and the logs interface endpoint; add kms if sessions are encrypted.

If the subnets already have a NAT gateway, the endpoints are optional (the agent will happily use the regional public endpoints over NAT), but the interface endpoints keep session traffic off the NAT data-processing meter and inside the VPC.

With those three pieces in place, the public IPs, the bastion, port 22, and the key pairs are all deletable.

When to use it, and when an auditor pushes back

Session Manager is the right default for interactive administrative access to EC2. It is not automatically audit-clean. If we were reviewing your account, this is what we would check.

Use it when access is interactive, occasional, and administrative: debugging, incident response, one-off inspection. Every session start is a StartSession event in CloudTrail tied to an IAM principal, which is already better evidence than an SSH login against a shared key.

Turn on session logging before you call it a control. Out of the box, Session Manager records that a session happened, not what happened inside it. Session activity logging to S3 or CloudWatch Logs (with KMS encryption on both the session and the destination) captures the full terminal transcript. Without it, an auditor will correctly note that your privileged access has no content trail.

The identity gap: everyone is ssm-user. This is the finding most teams miss, and in our experience it is the single point where enterprise rollouts stall. Session Manager authenticates the AWS principal, but on the operating system every session lands as the same local account, ssm-user, with sudo rights by default. Your OS logs, auditd trail, and file ownership all say ssm-user did it. If your access policy or your regulator expects OS-level actions to be attributable to a named individual (and most do), the default setup fails that requirement even though AWS knows exactly who started the session.

What the console identity already gives you. Before reaching for workarounds, know what is attributable out of the box. When a user starts a session from the console or CLI, CloudTrail records the StartSession event with their full principal ARN, and the session ID itself is generated with the IAM user name as its prefix. This is why AWS's own example policies can scope ssm:TerminateSession to arn:aws:ssm:*:*:session/${aws:username}-*. Since the CloudWatch log stream for the session transcript is named after the session ID, the transcript of everything typed and returned in the session is already tied to the console identity by name. What AWS does not do is carry that identity into the operating system: there is no mechanism that logs the console IAM user into the box as themselves, and no automatic provisioning of OS accounts from IAM identities. Inside the VM, attribution stops at ssm-user unless you configure Run As.

Workarounds for the OS-level gap:

Run As. Session Manager preferences can run sessions as a named OS user instead of ssm-user, taken from the SSMSessionRunAs tag on the IAM principal. Three constraints to plan around: it is Linux and macOS only, the root account is not supported, and once Run As is on there is no fallback to ssm-user. A missing tag or missing OS account means no session. From an audit perspective the no-fallback behavior is a feature: nobody can silently drop back to the shared identity.
Run As works per person even under SSO. The obvious objection in a federated setup (Entra ID or any SAML IdP in front of AWS) is that everyone shares the same role, so a tag on the role would map everyone to the same OS user. The answer is session tags: the IdP passes SSMSessionRunAs as a SAML attribute (https://aws.amazon.com/SAML/Attributes/AccessControl:SSMSessionRunAs) with a per-user value, and each person's role session carries their own OS user name. With IAM Identity Center, enable Attributes for Access Control and map the attribute to ${path:userName} so it flows from the directory automatically. Same permission set, individual OS identity per human.
The OS account still has to exist first. Session Manager verifies the target account before starting the session and refuses the connection if it is missing. It never creates users. That leaves an enterprise with exactly two options: provision matching Linux accounts on every node ahead of time (user data, Ansible, or a State Manager association syncing the user list), or domain-join the instances so the Run As target is a domain user that exists everywhere by definition. The domain-join path is the cleanest where AD is already present, and OS-level attribution then matches the corporate identity, but be precise about what it is: Session Manager checks that the domain account exists and runs the session as it. The mapping from AWS principal to domain user is tag-based trust, not a Kerberos logon, and an auditor should understand it as such. Note for Entra ID shops: Entra ID alone is not a joinable domain in the classic sense; this path needs real Active Directory in the picture (AWS Managed Microsoft AD, or hybrid AD synced through Entra Connect).
Accept correlation as the control for small teams: session transcripts carry the IAM identity in their name (see above), CloudTrail carries the principal, and OS logs carry ssm-user plus timestamps. Documenting that correlation procedure is defensible for low-change environments and startups. It is weak for regulated ones, because it degrades exactly when you need it most: concurrent sessions on the same instance.

When OS logs need to reach the SIEM

Session transcripts in S3 are evidence, but they are not detection. Ship OS-level logs to the SIEM when any of these hold:

Regulated workloads. If the instance is in scope for PCI DSS, ISO 27001 A.8.15/A.8.16, or similar, privileged session activity must be centrally collected and reviewed, not just stored. A transcript bucket nobody reads does not satisfy "monitored".
Run As is your attribution control. Then /var/log/secure and the auditd trail are where the named OS user actually appears, and they need to be tamper-evident and off-box. CloudWatch Agent to CloudWatch Logs, then a subscription filter to Kinesis Data Firehose into the SIEM, is the standard path and keeps the instance role additions minimal.
You need alerting on what happens inside sessions, not just that they occurred: sudo to root, package installs, outbound connections initiated from an interactive shell. That is auditd or Sysmon territory, and it only has value if a detection pipeline consumes it.

If none of those apply (dev accounts, no compliance scope, low blast radius), CloudTrail plus encrypted session transcripts is a proportionate control, and the SIEM integration can wait.

Impact

For a startup, the impact is immediate and unambiguous: public IPs deleted, port 22 closed everywhere, key pairs revoked, bastion terminated, and engineers reach any instance on the fly with nothing but their existing IAM login. The whole migration is an instance profile, three VPC endpoints, and one afternoon.

For an enterprise, the network win is identical, but the honest impact statement includes the second phase: Run As backed by provisioned OS or domain accounts, session transcripts encrypted and centralized, and OS logs flowing to the SIEM where compliance scope demands it. That phase is real work. It is still less work than operating a bastion fleet with rotating SSH keys, and unlike the bastion, it ends with every privileged session attributable to a named person at both the AWS layer and the OS layer.

The end state in both cases is the same: zero inbound ports for administrative access, and the answer to "why does this instance have a public IP" is only ever "it serves the internet".

Want us to look for issues like this in your account? We offer a free AWS audit: upstood.com

Give Your Auditor AWS Access — Without Sharing a Single Credential

Alex — Fri, 10 Jul 2026 19:20:42 +0000

If your auditor asks for that, that should be the first finding. 🚩

An external auditor needs access to your AWS accounts, and the first instinct in most companies is one of two things: create an IAM user and share the access keys, or provision the auditor a user in your identity provider so they can log into the console.

Neither is necessary. An auditor doesn’t need a login in your organization at all — API access is enough. And AWS has had a mechanism for exactly this situation for over a decade. It’s the same one AWS partners and every third-party monitoring tool use:

A cross-account IAM role with a trust relationship. No credentials ever change hands.

In this article I’ll walk through how the pattern works and share two CloudFormation templates I built — one for a single AWS account, one that covers an entire AWS Organization. You can deploy either in about five minutes. Both templates are also on GitHub: https://github.com/up-cdk/aws-audit-access

Why not just create a user?

Because every credential you create is a liability you now own:

Access keys are long-lived. They work until someone remembers to delete them. Every audit I’ve read about that went wrong involved keys that outlived the engagement.
Passwords get shared insecurely. Email, Slack, a text message — the moment credentials travel, you’ve lost control of where they end up.
IdP users pollute your directory. An external party in your identity provider inherits whatever group memberships and app assignments someone clicks together, and deprovisioning is a manual step someone has to remember.

The pattern: cross-account role + External ID

The idea is simple. Instead of giving the auditor your credentials, you create a role in your account that the auditor’s own AWS account is allowed to assume.

Four pieces make it safe:

The trust policy names exactly one AWS account — the auditor’s. Not a user, not a password: an account-to-account trust. The auditor authenticates in their account with their credentials, then calls STS AssumeRole to get temporary credentials for the role in yours.
An External ID guards the trust. This is a shared secret agreed between you and the auditor, set as a condition on the trust policy. Without presenting it, the role cannot be assumed — even by the trusted account. This protects against the confused deputy problem: if the auditor works with many clients, a malicious client can’t trick the auditor’s tooling into accessing your account, because they don’t know your External ID.
All access is temporary. STS sessions expire (1 hour by default in these templates, configurable). There is no long-lived credential anywhere in the setup.
Everything is logged. Every AssumeRole call and every API call the auditor makes lands in your CloudTrail, attributable to the audit role’s session. You can see exactly what was looked at, and when.

And the permissions? Read-only, and scoped for the job: AWS’s managed ReadOnlyAccess and SecurityAudit policies, optionally AWSBillingReadOnlyAccess for cost review, plus a small supplementary policy for audit-relevant services the managed policies miss (GuardDuty findings, Security Hub, Cost Explorer, Trusted Advisor, and a few others).

Option 1: single account

Deploy this template in the account being audited. Two parameters matter: the auditor’s 12-digit AWS account ID, and the External ID they give you.

Template: aws-audit-readonly-role.yaml in the GitHub repo — https://github.com/up-cdk/aws-audit-access

Deploy it from the console (CloudFormation → Create stack → Upload template), or from the CLI:

aws cloudformation deploy --template-file aws-audit-readonly-role.yaml --stack-name external-audit-access --capabilities CAPABILITY_NAMED_IAM  --parameter-overrides AuditorAWSAccountId=111122223333 ExternalId=the-external-id-from-your-auditor

Then send the auditor the role ARN from the stack outputs. That’s it — that’s the entire exchange. An ARN is not a secret; combined with the External ID (which the auditor already has, since they generated it) and the trust policy, it’s everything they need and nothing more.

Option 2: the entire AWS Organization

Auditing one account is rare — most audits cover an Organization with anywhere from a handful to hundreds of member accounts. Creating the role by hand in each one doesn’t scale.

The second template solves this with a service-managed CloudFormation StackSet. You deploy one stack in the management account, and it:

creates the audit role in the management account itself,
creates a StackSet that rolls the same role out to every member account under the OUs you target (pass your root ID, e.g. r-abcd, to cover the whole organization),
optionally auto-deploys to any new account added to those OUs later — no gaps if accounts are created mid-audit,
and tears everything down centrally when you delete the stack.

One prerequisite: service-managed StackSets require trusted access between AWS Organizations and CloudFormation to be activated (CloudFormation console → StackSets → “Activate trusted access”, a one-time click in the management account).

Template: aws-audit-organization-stackset.yaml in the same repo. The deploy command:

aws cloudformation deploy --template-file aws-audit-organization-stackset.yaml --stack-name external-audit-access-org --capabilities CAPABILITY_NAMED_IAM --parameter-overrides AuditorAWSAccountId=111122223333 ExternalId=the-external-id-from-your-auditor TargetOrganizationalUnitIds=r-abcd DeploymentRegions=us-east-1

IAM is a global service, so one deployment region is enough for the stack instances.

After deployment, every in-scope account contains a role with the same name, so the auditor can iterate over account IDs with a single ARN pattern:

arn:aws:iam:::role/ExternalReadOnlyAuditRole

The auditor’s side

From their own account, the auditor assumes the role:

aws sts assume-role --role-arn arn:aws:iam::444455556666:role/ExternalReadOnlyAuditRole --role-session-name aws-audit --external-id THE_EXTERNAL_ID

For an organization audit, the auditor loops the same profile pattern over the account list — which they can fetch with organizations:ListAccounts, included in the role’s permissions.

Ending the audit

This is my favorite part, because it’s one line:

aws cloudformation delete-stack --stack-name external-audit-access

Delete the stack (or the org stack, which removes the StackSet instances from every member account). Access is gone. Nothing to rotate, nothing to deprovision, no forgotten IAM user with active keys waiting for the next auditor to find.

The way you grant audit access says a lot about how you manage access everywhere else. If your next audit starts with “please create a user for us” — send them this article instead.

I tried Karpathy's LLM Wiki pattern on my AWS consulting work — here's what changed

Alex — Tue, 14 Apr 2026 00:22:22 +0000

I tried Karpathy's LLM Wiki principle on my own AWS consulting work a few weeks ago, and I can't go back.

If you missed it, Andrej Karpathy published a short gist called LLM Wiki: A Pattern for Persistent Knowledge Bases. His thesis: instead of using RAG to re-derive answers from raw sources on every query, let the LLM maintain a persistent, compounding wiki. Humans curate sources and ask questions. The model handles the bookkeeping — summarizing, cross-linking, keeping pages consistent over time.

So I tried it. I rebuilt my entire AWS consulting knowledge base around Karpathy's three-layer pattern. This post is what I actually did, what the folder looks like now, the frontmatter schema that makes it queryable by Claude Code skills, and the three rules I had to enforce to stop it from rotting.

At the bottom there's a copy-pasteable Claude Code prompt that scaffolds the same structure in an empty directory — if you want to try it yourself.

Why I tried this on AWS consulting specifically

Every engagement I run has the same four information streams, and all four used to decay fast:

Client-specific context — their account structure, compliance posture, team, kickoff constraints.
Cross-project AWS patterns — cross-account alarm routing, IAM boundaries, cost allocation.
Decisions — why I picked Aurora over RDS for this client, what tradeoff I accepted.
Gotchas — what broke, in what AWS service, under what conditions.

Before Karpathy's pattern, all four lived, well not in the same place let's say. Every new engagement brought the same conclusion that I was the bottleneck :).

Now the LLM compiles it once and keeps it current for me. I'm not the bottleneck anymore.

The three layers, as I actually set them up

Layer 1 — Raw sources (immutable)

./raw/
├── assets/                      # Downloaded images, screenshots
├── aws-reinvent-2024-obs.md     # Clipped article
├── client-kickoff-2026-03.md    # Meeting transcript
├── datadog-quote-client-a.pdf   # Vendor docs
└── aws-bill-client-b-q1.csv     # Cost exports

Raw never changes. If the wiki layer gets corrupted or I change conventions, I can re-derive from raw. That immutability is what gave me the confidence to let Claude aggressively refactor the wiki.

Layer 2 — Wiki (LLM-maintained markdown)

./wiki/
├── projects/
│   ├── client-a/
│   │   ├── _status.md             # Dashboard — I start here every session
│   │   ├── client-a-overview.md   # Architecture + key decisions
│   │   ├── decisions/             # ADR-style, one file per decision
│   │   ├── workflows/             # Automation-ready procedures
│   │   └── gotchas/               # What broke and why
│   └── client-b/
├── sa/                            # Solutions architecture patterns (cross-client)
├── aws/                           # AWS service patterns + gotchas
└── standards/                     # CDK conventions, tagging, account standards

One vault, per-client folders. Cross-client patterns live in sa/, aws/, standards/ — my opinion library. Client folders stay isolated so I never accidentally leak Client A's IAM choices into a Client B audit.

Layer 3 — `CLAUDE.md` (the schema)

Karpathy calls this the "config for how the LLM operates on the wiki." For me, it's a single file at the vault root that defines the directory structure, the frontmatter schema, what belongs in the wiki and what doesn't, and the workflows I want Claude to follow (ingest a source, update _status.md, lint for orphans).

Change CLAUDE.md and you change how every future Claude Code session operates on the vault. It's the load-bearing file.

The frontmatter schema I landed on

Every page has YAML frontmatter. Not for me to read — for skills to query:

---
title: "Cross-account CloudWatch alarm routing"
type: pattern
tags: [aws, cloudwatch, cross-account, observability]
sources: [raw/aws-reinvent-2024-obs.md, project: client-a]
created: 2026-03-02
updated: 2026-04-11
---

sources is non-negotiable for me. It keeps the agent honest when it synthesizes — every claim in the wiki traces back to something in raw.

The first skill I wrote that made me a believer

Here's the one that convinced me this was worth the effort: an architecture-review skill I can run when a client proposes a change.

---
name: architecture-review
description: Reviews a proposed architecture change against client constraints and cross-client patterns
---

Inputs:
1. Client name (must match a folder in wiki/projects/)
2. Proposed change (free text or linked diagram)

Steps:
1. Read wiki/projects/<client>/_status.md for current phase and constraints
2. Read wiki/projects/<client>/<client>-overview.md for architecture baseline
3. Query wiki/sa/ and wiki/aws/ for pages where tags intersect with the change
4. Query wiki/projects/<client>/gotchas/ for anything relevant
5. Query wiki/projects/<client>/decisions/ for prior decisions that constrain this change
6. Produce a review document with:
   - Compatibility with existing architecture
   - Relevant cross-client patterns that apply
   - Prior decisions that would be affected
   - Gotchas that could bite
   - Recommended next steps

Output: wiki/projects/<client>/decisions/<YYYY-MM-DD>-<slug>.md (draft for human review)

There's no magic prompt here. The whole point is that the skill is running against structured, maintained context — not a blank LLM. The quality of the output is about the quality of the wiki, not the prompt.

The three rules I had to enforce

Karpathy warns that maintenance is what kills human wikis. Even with an LLM doing the work, I found three rules that actually matter in practice:

Frontmatter or it didn't happen. No frontmatter = skills can't index it. I make Claude add frontmatter before content on every new page.
_status.md updates at session end, not start. I set up a Claude Code Stop hook that blocks me from ending a session until the dashboard moves forward. Without the hook, dashboards went stale inside a week.
One page, one concept. Gotchas get their own pages, not subheadings under a shared "troubleshooting.md". The retrieval unit is a page — keep it small enough that multiple fit in context without bleed.

What actually changed in my work

Three concrete things shifted after a few weeks:

Architecture designs are regenerated, not rewritten. A client constraint changes → I update the relevant page → rerun the design skill → new design doc.
Audits are reproducible. Same vault + same skill on the same day = same findings. I couldn't get that property out of ad-hoc Claude chats no matter how careful I was with prompts.
Handover is the deliverable. At the end of an engagement, the client gets the CDK and their vault folder. The vault is the documentation.

The output layer

Everything Claude generates in my setup ends up as CDK. I open-sourced the constructs at up-cdk — compliance-aligned building blocks for S3, VPC, pipelines, so every stack is compliant by default. Wiki + skills + opinionated output library is the combination that finally made the setup reproducible across clients.

If you want to try it — the bootstrap prompt

The fastest way to see if this pattern works for you is to try it. Here's the Claude Code prompt I use to scaffold the whole structure in an empty directory. No scripts, no deps, just markdown and conventions.

You are setting up a new LLM Wiki following Andrej Karpathy's pattern
(https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f),
adapted for AWS consulting / platform engineering work.

The wiki has three layers:
- `raw/` — immutable source material (meeting notes, clipped articles, bills, screenshots)
- `wiki/` — LLM-maintained markdown synthesized from raw + conversation
- `CLAUDE.md` at the root — the schema document that tells you how to operate on the wiki

Create the following structure in the current directory. For every file below,
create it with the frontmatter and seed content described. Do not skip any
file. Do not invent additional files.

## Directory tree

./
├── CLAUDE.md
├── index.md
├── log.md
├── raw/
│   ├── assets/.gitkeep
│   └── README.md
├── templates/
│   ├── project-status.md
│   ├── page.md
│   └── workflow.md
└── wiki/
    ├── projects/
    │   └── _example-client/
    │       ├── _status.md
    │       ├── _example-client-overview.md
    │       ├── decisions/.gitkeep
    │       ├── workflows/.gitkeep
    │       ├── gotchas/.gitkeep
    │       └── diagrams/.gitkeep
    ├── sa/.gitkeep
    ├── aws/.gitkeep
    └── standards/.gitkeep

## CLAUDE.md (the schema document)

Write a root CLAUDE.md that defines:
- Purpose: personal AWS knowledge base following Karpathy's LLM Wiki pattern.
- The three layers: raw/ (immutable), wiki/ (LLM-generated), CLAUDE.md (schema).
- What belongs in the wiki: durable knowledge (gotchas, decisions, patterns,
  strategy, workflows, status dashboards). What does NOT belong: raw doc
  summaries, git state, ephemeral task context.
- Page format — every wiki page must have YAML frontmatter with fields:
  title, type (pattern | gotcha | decision | concept | process | status |
  workflow), tags, sources, created, updated.
- File naming — kebab-case. Overview files: <project>-overview.md. Status
  files: _status.md (underscore prefix sorts to top).
- Cross-references — [[filename]] Obsidian-style wiki links.
- Every page ends with a ## Related section.
- Workflows (document all four):
  1. Quick context recovery at session start — read
     wiki/projects/<project>/_status.md first.
  2. Update _status.md at session end — refresh Last/Next session lines,
     append one row to Session History (keep last 5), update Recent Decisions
     and Open Questions, set updated: to today.
  3. Ingest a raw source — read thoroughly, write/update pages in the right
     wiki/ subdirectory, cross-link, update index.md, append to log.md.
  4. Lint — find orphan pages, stale content, missing back-links.
- Common tags taxonomy — starter list for AWS, SA, meta tags.
- Persistence layer rules — wiki is the single source of truth for durable
  knowledge.

## index.md
A one-page catalog. Headers for each top-level wiki directory (## Projects,
## Solutions Architecture, ## AWS, ## Standards), each with "No pages yet."

## log.md
Append-only activity log. Seed with today's date and "Initialized wiki
following Karpathy LLM Wiki pattern."

## templates/project-status.md
Template for _status.md files. type: status. Sections: Phase, Last session,
Next session, Current State, Recent Decisions, Open Questions, Session
History (Date | Summary table), Quick Links.

## templates/page.md
Generic page template. Frontmatter + ## Key Points / ## Details / ## Related
/ ## Sources.

## templates/workflow.md
Automation-ready procedure template. type: workflow. Sections: Goal,
Prerequisites, Steps (numbered, imperative), Verification, Rollback (if
applicable), Related.

## wiki/projects/_example-client/_status.md
Realistic example status dashboard. Phase: active. Plausible placeholder
content. Marked as example.

## wiki/projects/_example-client/_example-client-overview.md
Example architecture overview. Frontmatter + 3-sentence overview + Key
Points + Architecture + Recent Decisions + Related.

## raw/README.md
One-page explanation of what goes in raw/ and the immutability rule: never
edit raw files after adding them.

---

After creating everything, print a summary (file count + tree) and next
steps: (1) add your first raw source to raw/, (2) create your first real
project folder under wiki/projects/, (3) commit to git.

Do not add files beyond what's specified. Do not add a root README.md.
Do not add a LICENSE.

Run it from an empty directory, then git init, then add your first raw source. I had a working LLM Wiki in under two minutes.

The original gist is short and worth reading: Karpathy — LLM Wiki.

If you try it, drop a comment with how you ended up shaping it. I'd genuinely like to compare notes.

DEV Community: Alex

Terraform Modules vs CDK Constructs | What the Extra Layers Change

The problem

Terraform has two layers. CDK has four.

Identity is where the layers bite

What CloudFormation does with that

The same trap has a name in Terraform

Why this compounds with the layer count

The options

Where each one fits

NAT Gateway, VPC Endpoints, or an Egress Proxy: What Each Way Out of Your VPC Costs

The problem

The finding

The options

The NAT gateway on its own

VPC endpoints for AWS-service traffic

A self-managed egress proxy

Where each one fits

Is Multi-AZ Enough for Disaster Recovery? What DORA Actually Asks of Your Application

The problem

The finding

1. What DORA actually asks: objectives, not architecture

2. What the multi-AZ camp actually has

3. What the second-region camp actually has, and the outage that tested both

The fix

Impact

Session Manager removes your public IPs. Is it enough for an audit?

The problem

The finding

1. The minimum instance role

2. The minimum user policy

3. The network path (the "firewall")

When to use it, and when an auditor pushes back

When OS logs need to reach the SIEM

Impact

Give Your Auditor AWS Access — Without Sharing a Single Credential

Why not just create a user?

The pattern: cross-account role + External ID

Option 1: single account

Option 2: the entire AWS Organization

The auditor’s side

Ending the audit

I tried Karpathy's LLM Wiki pattern on my AWS consulting work — here's what changed

Why I tried this on AWS consulting specifically

The three layers, as I actually set them up

Layer 1 — Raw sources (immutable)

Layer 2 — Wiki (LLM-maintained markdown)

Layer 3 — CLAUDE.md (the schema)

The frontmatter schema I landed on

The first skill I wrote that made me a believer

The three rules I had to enforce

What actually changed in my work

The output layer

If you want to try it — the bootstrap prompt

Layer 3 — `CLAUDE.md` (the schema)