Forem: Lee Wynne

The Secret to Near 100% AWS Tagging Compliance? People Shouldn't Know You're Doing It.

Lee Wynne — Tue, 31 Mar 2026 14:24:31 +0000

Every enterprise with more than a handful of AWS accounts eventually has the same reckoning. Someone in finance asks which team owns the spend in AWS account 846241037459. Someone in security wants to know whether the resources in a particular VPC are production or development. Someone in operations needs to route an incident to the right application owner at 2am. And in every case, the answer depends on tags.... tags tags tags, never ending tags - tags that probably do not exist, may or may not be accurate, and almost certainly aren't consistent across business divisions.

This is the tagging problem, and most organisations try to solve it the wrong way. They write a tagging policy. They distribute it in a wiki that nobody bookmarks. They ask teams to please tag their resources correctly. And then they act surprised when compliance sits at sub 20% and the data is useless for any meaningful reporting or incident management.

The Provider > Consumer model solves this differently. Instead of asking consumers to tag their resources, the Provider delivers mandatory tags as part of the account vending pipeline (before the consumer ever touches the environment). The tags arrive with the account. The resources inherit them. The consumer can't remove them, can't modify them, and in most cases doesn't even realise they provided the data that populated them!

This isn't a tagging strategy. It's a tagging system. And the distinction matters more than most platform teams appreciate.

Why Voluntary Tagging Always Fails at Scale

Let's be honest about this. Voluntary tagging policies have a 100% failure rate in large enterprises. Not because people are negligent, but because the model is fundamentally broken.

A developer provisioning an EC2 instance is thinking about their application. They're thinking about instance types, security groups, and whether their deployment fettling works. They are not thinking about which cost centre code maps to their division's financial reporting hierarchy. They don't know that finance needs a specific format for the Cost Code tag (they certainly don't know that the value needs to match an entry in SAP that they've never seen and don't have access to).

So what happens? They leave the tag blank. Or they guess. Or TBD/D goes in. Or they put in something that looks right but doesn't match the source of truth. And now you have a resource in production with a cost code that doesn't resolve to anything in the financial system, which means it falls into an "unallocated" bucket, which means someone in FinOps spends three hours every month trying to reconcile it.

Multiply this across thousands of resources, dozens of teams, and many business divisions, and you have a tagging estate that's technically present but functionally useless. You've achieved the appearance of governance without any of the substance.

The root cause isn't laziness. It's that you've placed the burden of organisational metadata on the people least equipped to provide it.

A developer shouldn't need to understand the enterprise financial hierarchy to deploy a Lambda function. That's not their job. It's yours (as a Provider).

Mandatory Tags Are a Platform Concern, Not a Consumer Concern

This is the shift in thinking that makes the Provider > Consumer model work for tagging. Mandatory tags, the tags that drive financial reporting, security ownership, compliance classification, and business criticallity, are platform-level concerns. They exist to serve the organisation, not the individual workload. And because they serve the organisation, the organisation (through the Provider) should own them end to end.

In the Provider > Consumer model, mandatory tags are opinionated.

The platform team decides which tags exist, what their keys are called, what format the values must take, and where the source of truth lives. These aren't suggestions. They're not configurable. They're the platform's DNA, and they flow through every account, every VPC, and every resource that gets provisioned and this works because there is workload segregation at the account level.

The Provider owns the tag taxonomy. The Provider owns the enforcement mechanism. The Provider owns the pipeline that applies them. The consumer benefits from the data they generate, through cost reports, ownership dashboards, and incident routing (without ever having to maintain the tags themselves).

This is what opinionated platform design looks like when applied to metadata. You don't ask consumers what tags they want. You tell them what tags they'll get. And you make those tags so deeply embedded in the provisioning process that removing them would require dismantling the pipeline itself.

Pre-Account Vending: Where the Data Actually Comes From

Here's where it gets elegant. The data that populates mandatory tags doesn't come from a tagging form. It comes from the account request process, typically a well-designed ServiceNow form that the consumer fills out when they request a new AWS account pattern.

Think about what a consumer provides when they request an account. They specify which business division they belong to. They identify the application or workload the account is for. They nominate a technical owner and a security contact. They provide (or their request is enriched with) a cost centre code from the enterprise financial system. They indicate whether this is a production or non-production workload.

Every single one of those data points maps directly to a mandatory tag. Business Division becomes the Business Division tag. The application name maps to Application Name tag. The cost centre maps to Cost Code. The technical contact maps to Technical Owner. The consumer isn't filling out a tagging form. They're filling out an account request form. But the platform team has designed that form so that every field either directly populates a tag or feeds a lookup that resolves to a tag value.

The consumer doesn't know they're providing mandatory tagging data. They think they're answering reasonable questions about their workload. And they are, but those questions just happen to be the exact inputs the tagging pipeline needs.

This is deliberate. The best tagging strategies are invisible to the people being tagged. If your consumers are aware they're doing tagging, you've already introduced friction. And friction is where compliance goes to die.

The Vending Pipeline: Tags as Infrastructure

Once the account request is approved and the required data is captured, the Provider's account vending pipeline takes over. This is where tags stop being metadata and start being infrastructure.

The vending pipeline, whether it's built on AWS Control Tower Account Factory, Terraform, or a custom solution, provisions the account with mandatory tags already applied. The tags are written at the account level as part of the same automation that creates the account, configures the security baseline, deploys the VPC, and wires up connectivity.

There's no separate tagging step. There's no "apply tags after provisioning" task that someone might forget or defer. The tags are part of the account's identity from the moment it exists. By the time the consumer gets access to their new environment, the mandatory tags are already there, applied, validated, and from their perspective, immutable.

At the AWS account level, these tags propagate through AWS Organisations. Tag policies enforce the expected format and values. Service Control Policies can prevent the creation of resources that don't carry the required tags. And because the Provider controls the Terraform modules that consumers use to provision resources within their accounts, those modules can inject mandatory tags automatically, the consumer's resource inherits the account's mandatory tags without any action on their part.

This is the inheritance model, and it works because of a design decision the Provider made long before any tagging conversation happened, accounts are segregated by environment and by workload. One account per workload per environment. This means the mandatory tags that describe ownership, cost allocation, and classification are consistent for every resource in the account because every resource in the account belongs to the same workload in the same environment. There's no ambiguity. There's no "this EC2 instance belongs to Team A but that RDS instance belongs to Team B." The account boundary is the ownership boundary, and the tags reflect that.

Why Mandatory Tags Must Be Immutable to Consumers

This is where most tagging implementations go sideways.

If consumers can modify mandatory tags, they will. Not maliciously just inevitably. Someone will "fix" a cost code they think is wrong. Someone will update a technical owner field when a team member leaves, using a personal email instead of a distribution list. Someone will delete a tag they don't recognise because it looks like clutter.

Every one of these well-intentioned changes breaks something downstream. The cost code "fix" means the resource no longer maps to a valid entry in the financial system. The email change means the incident routing automation sends alerts to a personal inbox that nobody checks after hours. The deleted tag means a compliance report now has a gap that triggers an audit finding.

Mandatory tags are not the consumer's concern to maintain because they are not the consumer's data. They are organisational data that happens to be attached to the consumer's resources. The Provider maintains them. The Provider updates them. The Provider ensures they stay consistent with their sources of truth.

In practice, this means the tags are applied and managed through the Provider's pipeline, through Terraform state, through AWS Organisations tag policies, through account-level automation that runs on a schedule to detect and remediate drift. If a tag gets changed, the pipeline puts it back. If a tag gets deleted, the pipeline restores it. The consumer's Terraform code doesn't manage these tags. The consumer's IAM permissions don't grant write access to them at the organisational level.

This isn't about trust issues. It's about system design. You don't let application code modify the VPC's route table. You don't let developers reconfigure the transit gateway. And you don't let consumers edit the tags that drive your organisation's financial reporting, security ownership, and compliance posture. These are platform concerns, managed by the platform, enforced by the platform.

What Happens When a Consumer Needs a Tag Changed?

Tags like CostCode or TechnicalOwner do change over time. Teams reorganise. Cost centres get restructured. People move to different roles. The fact that mandatory tags are immutable to consumers doesn't mean they're permanent, instead it means changes flow through the right channels.

When a consumer needs a mandatory tag updated, they raise a request. This might be a ServiceNow ticket, or a conversation with the Platform team. The Provider validates the new value against the source of truth (does this cost code actually exist in SAP? Is this email address a valid distribution list in the directory?), then updates the tag through the pipeline, and the change propagates to the account and its resources.

The process is intentionally deliberate (not slow, deliberate). Mandatory tags affect reporting, billing allocation, security ownership, and compliance classification across the organisation. A change to the 'BusinessDivision' tag on an account ripples through every cost report, every ownership dashboard, and every compliance audit that references that account. That change should be validated, approved, and applied through automation, not made ad hoc in the AWS console by someone who needed to update a spreadsheet.

In practice, mandatory tag change requests are rare. Cost codes don't change monthly. business division structures don't shift weekly. Technical ownership transfers happen, but not frequently enough to create operational burden. The channel exists for when it's needed, but the design assumes stability, because mandatory tags represent organisational facts that are, by definition, slow-moving.

Consumer Tags: Where the Provider Steps Back

Not all tags are mandatory. Consumers obviously have their own tagging needs, operational tags, automation tags, application-specific metadata that the platform team has no opinion about. And that's exactly right. The Provider should have no opinion about them.

A consumer might want to tag resources with deployment version numbers, feature flags, team-specific identifiers, or automation triggers. These tags serve the consumer's operational needs, not the organisation's reporting needs. The Provider doesn't define them, doesn't enforce them, and doesn't manage them.

What the Provider can do, and should do, is provide guidance. A set of recommended operational tags, published as suggestions rather than mandates, helps consumers who aren't sure what to tag or how. Tags like CostCentre (for project-level cost tracking below the mandatory CostCode), ManagedBy (Terraform, CloudFormation, manual), or BackupPolicy (daily, weekly, none) are operationally useful and don't need to be mandated to be valuable.

The Provider can also provide tag validation tooling that consumers can optionally adopt. Linting rules in the CI/CD pipeline that warn (but don't block) when recommended tags are missing. Dashboard views that show tag coverage across a consumer's account. These are nudges, not guardrails, and the distinction really matters.

Mandatory tags get guardrails. Consumer tags get guidance. Conflating the two undermines both.

The ServiceNow Form: Designed for Data, Not for Tagging

This is where the consumer experience either succeeds or fails.

A poorly designed form asks the consumer to provide tagging data. It has fields labelled "Business Division Tag," "Cost Centre Tag," and "Application Name Tag." The consumer sees these and thinks "I don't know what half of these mean" or "I'll come back to this later" (they won't). The form creates friction, and friction creates gaps and gaps create delays in environment vending.

Behind the form, the platform team has mapped every field to a tag key and configured lookups against the sources of truth. The business division dropdown pulls from a source of truth. The cost centre field validates against SAP. The application name resolves against the enterprise architecture tool. The consumer selects from a dropdown and the pipeline writes the value to the account. The consumer types a cost centre and the pipeline validates it exists before writing.

This form is the interface between the consumer's knowledge and the Provider's tagging system. When it's designed well, the consumer knows what information is required well up front and fills it out in five minutes, the pipeline has everything it needs, and mandatory tags arrive fully populated and validated before the account is even created. The consumer never typed a tag key. They never formatted a tag value. They answered questions about their workload, and the platform did the rest.

Resource Inheritance: Why Account Segregation Makes This Work

The inheritance model (where resources automatically carry the mandatory tags of their parent account) only works if accounts are properly segregated. And this is a design decision the Provider must make early, because retrofitting it later is pain - real pain.

The principle is straightforward. One account per workload per environment. The production instance of Application X lives in one account. The development instance lives in another. The staging instance lives in a third. Each account has mandatory tags that describe that specific combination of workload and environment.

When a consumer provisions an ECS/EC2 instance, an RDS database, or an S3 bucket in that account, the resource inherits the account's mandatory tags. The Business Division tag is correct because the account belongs to that division. The Application Name tag is correct because the account hosts that application. The Environment tag is correct because the account is dedicated to that environment. The Cost Code is correct because the cost centre covers all resources in that workload's environment.

There's no need for the consumer to tag each resource individually with organisational metadata. The account is the tagging boundary. Everything inside it inherits. This eliminates the most common source of tagging inconsistency in large estates: resources within the same account tagged differently because different team members provisioned them at different times with different understandings of what the values should be.

Account segregation also eliminates the shared account problem, you know which one I mean.. The scenario where a single account hosts resources from multiple applications owned by different teams with different cost centres. In a shared account, tagging has to happen at the resource level because the account-level tags can't represent multiple owners. This is fragile, error-prone, and impossible to enforce consistently. Proper account segregation makes it unnecessary.

The Tags That Drive Everything

Let's be specific about what mandatory tags actually enable, because the payoff is what justifies the investment in the pipeline.

Financial reporting and cost allocation. When every account carries a validated Business Division, and Cost Code tag, cost allocation becomes automatic. AWS Cost Explorer can slice spend by any of these dimensions without manual intervention. FinOps teams can produce division-level cost reports that match the financial system because the tag values are sourced from the financial system. There's no reconciliation step. There's no "unallocated" bucket growing larger every month. The tags are the reporting layer, and because they're mandatory and immutable, the reports are trustworthy. This paves the way for successful integration of enterprise level FinOps tooling that can deliver incredible insights and value.

Security and compliance ownership. The Security Owner and Technical Owner tags establish clear accountability for every account and every resource within it. When a vulnerability is discovered, the security team doesn't need to dig through wikis or Slack/Teams channels to find who owns the affected resource. The tag tells them. When a compliance audit requires evidence of ownership for production workloads, the tag provides it. Automated incident routing can use these tags to page the right person at 2am without human triage.

Operational efficiency. Tags like Application Name, Application ID, and Environment enable automation that would be impossible without consistent metadata. Automated backup policies keyed to environment type. Monitoring thresholds that differ between production and development. Cost anomaly detection scoped to individual applications rather than entire accounts. Each of these automations depends on tags being present, accurate, and consistent (exactly what mandatory tagging through the Provider pipeline guarantees).

Discovery and migration planning. When an organisation needs to assess its cloud estate (for migration, for rationalisation, for M&A due diligence), mandatory tags provide the map. Every account can be categorised by business division, application, environment, and ownership without manual investigation. A query against AWS Organisations returns a complete inventory, tagged and classified, ready for analysis. Without mandatory tags, this same exercise takes weeks of interviews, spreadsheet reconciliation, and educated guessing.

Governance That Doesn't Feel Like Governance

This is the part that matters most, and it's the part that most tagging strategies miss the mark on.

Good governance is invisible to those being governed. If your consumers feel the weight of your tagging policy, if they're spending time looking up tag values, formatting keys correctly, remembering which tags are mandatory, then your governance is creating friction, and friction erodes compliance over time. People start cutting corners. They copy tags from another resource without checking if they're correct. They leave optional-but-important fields blank because the form is already too long.

Mandatory tagging through the Provider-Consumer model removes all of this. The governance is in the pipeline, not in the consumer's workflow. The consumer's experience is > request an account, answer some questions about your workload, get a fully provisioned environment, start building. The tags are there. They're correct. They'll stay correct. And the consumer never had to think about them.

This is what it means to build for consumability in the context of tagging. You're not building a tagging policy. You're building a tagging system that operates as infrastructure, fully automated, validated, enforced, and invisible to the people it serves. The reporting works because the data is clean. The data is clean because the pipeline ensures it. The pipeline ensures it because the Provider owns it end to end.

Tags aren't a practice. They're plumbing. And like all good plumbing, the best measure of success is that nobody thinks about it until something goes wrong, which, if you've built it right, it won't (famous last words 😉)

Mandatory tags don't ask for compliance. They deliver it. Build the pipeline, own the taxonomy, and let your consumers focus on what they're actually here to do, build and operate!

Build for Consumability, The Provider to Consumer Model That Makes AWS Scale.

Lee Wynne — Thu, 26 Mar 2026 17:09:59 +0000

Most platform teams think their job is to build infrastructure. They're wrong. Their job is to build infrastructure that other teams can consume without thinking about it.

The difference matters more than most organisations realise. A platform team that builds a beautifully architected AWS landing zone but makes it painful to consume has built a bottleneck, not a platform. And in a large enterprise (where dozens of product teams need to ship features against real deadlines) bottlenecks don't just slow you down, they breed shadow IT, workaround architectures, and the kind of ungoverned sprawl that keeps security teams awake at night.

The Provider to Consumer model fixes this. It's a shared responsibility framework that gives the platform team (the Provider) clear ownership of foundational infrastructure, while giving product teams (the Consumers) a fast, governed path to build and deploy. Neither side operates in isolation. Both sides have accountabilities, and the interfaces between them are deliberate, opinionated, and battle-tested.

Here's how it works, and why it's the pattern that separates enterprises that scale confidently from those that scale chaotically.

The Problem With "We'll Build It For You"

In too many enterprises, the cloud platform team operates as a service desk. Product teams raise a ticket > The platform team provisions a VPC > Another ticket > An IAM role gets created > Another ticket > A CI/CD pipeline appears three weeks later.

This model doesn't scale. It can't. Every request becomes a queue item. Every queue item becomes a lead time. Every lead time becomes a frustrated product manager asking why it takes six weeks to get a development environment when they could spin one up on a personal AWS account in twenty minutes.

The instinct to centralise everything and hand it out on request comes from good intentions (governance, security, cost control). But the execution model is fundamentally wrong. You're not providing a platform. You're providing a gatekeeping function that happens to run on AWS.

The Provider to Consumer model inverts this. Instead of building things for consumers, you build things that consumers can use themselves (within boundaries you've already defined).

What the Provider Actually Owns

The Provider is the cloud platform team. Their job is to provision and maintain the foundational layers that every product team needs (and to do it in a way that's repeatable, governed, and fast).

There are four core responsibilities.

Account Provisioning with CIS Baseline. Every new workload gets its own AWS account pattern, provisioned through automation with a CIS security (or other supported frameworks) baseline already applied. The consumer doesn't request a hardened account and wait. The account arrives hardened. Security isn't a follow-up step, it's baked into the provisioning pipeline. AWS Control Tower watches across the entire organisation, enforcing guardrails that the consumer doesn't need to think about because they can't violate them.

VPC Design and Provisioning. The Provider owns the network architecture. Every account receives a VPC built from a repeatable reference architecture, consistent CIDR allocation, subnet tiering, inspection architecture, and connectivity back to shared services. The consumer doesn't design their own network. They don't choose their own CIDR ranges. They don't decide whether they need a NAT gateway. The VPC arrives ready, and it's the same shape every time. This isn't about limiting creativity, it's about eliminating an entire category of networking incidents that happen when teams roll their own.

CI/CD Pipeline and Repository Provisioning. The Provider provisions a GitHub repository with industrialised GitHub Actions workflows already wired in. The PR workflow (plan on pull request, apply on merge) is pre-configured and opinionated. The consumer doesn't build their own pipeline from scratch. They don't decide how Terraform gets executed. They inherit a workflow that's been tested across dozens of teams and hundreds of deployments. It works. Use it.

Infrastructure as Code Modules. The Provider maintains a library of battle-tested Terraform (or Terragrunt/OpenTofu) modules for commodity services (compute, databases, storage, queues, load balancers), the building blocks that every product team needs. These modules encode the organisation's opinions about how things should be built - tagging standards, encryption defaults, logging configuration, IAM boundaries. A consumer deploying an RDS instance through a Provider module gets all of that for free. A consumer building their own from raw Terraform resources gets none of it, and that creates a governance gap that someone will eventually have to close.

What the Consumer Actually Owns

The Consumer is the product team, developers and DevOps engineers building features, services, and applications on top of the platform.

Their accountabilities are different from the Provider's, but they're not lesser. The Consumer owns the application. The Provider owns the platform. The boundary between them is the interface contract, and both sides have obligations to honour it.

Building in a Safe, Governed Zone. The Consumer operates within the account, VPC, and pipeline that the Provider has established. They don't need to understand how the VPC was designed (but they do need to place their resources in the correct subnets). The Provider exposes this through lookups - the Consumer queries for the right subnet by type (public, private, data/backend etc) and gets back the correct placement. The VPC configuration is locked. The lookup is available. This is the right trade-off.

Using the CI/CD Pipeline for All Infra Changes. No ClickOps, no console deployments - every infrastructure change goes through the PR workflow the Provider has established. Plan on pull request > review > approve > apply on merge > promote through environments. The Consumer uses this pipeline, they don't modify it, bypass it, or build an alternative alongside it. The pipeline is the governance boundary, and respecting it is what makes the model work. If there are exceptions where console access is unavoidable, then it's granted on a request/approval basis, it is also temporary.

Consuming Infra IaC Modules for Resource Provisioning. When the Consumer needs infrastructure, they reach for a Provider module first. Need an S3 bucket? There's a module. Need an ECS service? There's a module. Need an Aurora cluster? There's a module. These modules aren't suggestions, they're the supported path. Building outside them is possible but comes with additional review requirements, because you're stepping outside the governed envelope.

The Shared Responsibility in Practice

The diagram that captures this model cleanly shows an AWS account as a shared space with a clear dividing line. On the left: the Provider's contributions. On the right: the Consumer's usage of those contributions. In the middle: the interfaces that connect them.

At the account layer, the Provider provisions the account with the required security frameworks applied. The Consumer sees Control Tower guardrails watching over their environment. They build in a safe zone, not because they chose to be safe, but because the environment won't let them be unsafe.

At the network layer, the Provider delivers a repeatable reference VPC architecture. The Consumer gets lookup access to find the correct subnet for their workload placement. The config is locked. The information is accessible. The Consumer can read the network topology but can't rewrite it.

At the CI/CD layer, the Provider delivers an Infra GitHub Actions workflows. The Consumer uses them to create and promote through their PR-driven deployment workflow. Infrastructure changes flow through the same governed pipeline regardless of which team is making them.

At the IaC layer, the Provider delivers modules. The Consumer uses them. The module encodes the organisation's standards. The Consumer supplies their workload-specific configuration. The result is infrastructure that's both customised to the application and compliant with the organisation's baseline.

This isn't a hierarchy, it's a contract. The Provider promises a fast, secure, consistent foundation. The Consumer promises to build on that foundation rather than around it.

Why "Built for Consumability" Is the Whole Point

Here's the phrase that should be pinned above every platform team's desk: Build for Consumability.

The value of a platform isn't measured by how sophisticated the Provider's architecture is. It's measured by how quickly a Consumer can go from "I need an environment" to "I'm deploying code." If that journey takes six weeks and twelve tickets, the architecture doesn't matter. You've failed.

Fast request through to environment provisioning means a product team can go from approved request to fully provisioned, governed AWS account with VPC, pipeline, and IaC modules, ready to build, in minutes, not weeks (as long as the required information is provided to facilitate the process). This is what automation exists for. Not to make the platform team's life easier (though it does), but to make the Consumer's path frictionless.

Clear separation of accountabilities means nobody is confused about who owns what. The Provider doesn't debug application code. The Consumer doesn't redesign the VPC. When something goes wrong (and it will) the separation makes triage faster because the ownership boundaries are unambiguous.

Governed and opinionated do's and don'ts include fail-safes meaning the platform has opinions, and those opinions are enforced. You can deploy an RDS instance through the module. You can't deploy an unencrypted RDS instance because the module won't let you. You can create a security group. You can't open 0.0.0.0/0 to the internet because the guardrail catches it. These aren't restrictions on productivity, they're the reason the Consumer can move fast.

Industrialised VPC architecture means the network is solved. Every account gets the same proven design, with inspection, segmentation, and connectivity built in. The Consumer never has to become a networking expert to ship a feature.

Industrialised GitHub Actions means the infra deployment pipeline is solved. Every team gets the same PR workflow, the same plan-and-apply pattern, the same promotion gates. The Consumer never has to become an infra CI/CD expert to deploy safely.

Battle-tested IaC modules means the building blocks are solved. Every commodity service has a module that encodes security, tagging, logging, and best practices. The Consumer never has to become a Terraform expert to provision compliant infrastructure.

See the pattern? The Provider solves categories of problems once. The Consumer benefits from those solutions repeatedly. That's consumability.

The Feedback Loop That Makes It Better

The Provider to Consumer model isn't static. The best implementations include a feedback loop where Consumer teams report friction, request new modules, and flag gaps in the platform.

A Consumer team discovers they need a service that doesn't have a module yet? That's a signal to the Provider to build one. A module is too rigid for a legitimate use case? That's a signal to add a configurable parameter. The PR workflow doesn't handle a team's branching strategy well? That's a conversation worth having.

The Provider maintains the platform. The Consumer pressure-tests it. Over time, the platform gets better not because the Provider imagines what teams need, but because teams tell them, through usage patterns, through support requests, and through the occasional frustrated Slack message that starts with "why can't I just..."

Those messages aren't complaints. They're product feedback. And the platform teams that treat them that way build platforms that people actually want to use.

What Happens When You Get This Wrong

If the Provider builds without thinking about consumability, you get a technically excellent platform that nobody uses. Teams route around it. They build their own VPCs in accounts they shouldn't have access to. They set up their own pipelines because the official one is too slow or too rigid. Shadow infrastructure proliferates, and the governance that the platform was supposed to provide evaporates.

If the Consumer ignores the Provider's interfaces and builds from scratch, you get inconsistency. Every team's infrastructure looks different. Tagging standards vary. Encryption policies are applied ad hoc. When audit time comes (and it always comes) you're answering questions about fifty different implementations instead of one.

If neither side respects the boundary, you get the worst of both worlds: a platform team drowning in bespoke requests and product teams waiting in queues that shouldn't exist. This is the state most enterprises find themselves in before they adopt the model. It feels normal because everyone's used to it. It isn't normal. It's just common.

Why This Matters Now

Enterprises are scaling their AWS & general cloud footprints faster than ever. Hundreds if not thousands of accounts. Thousands of developers. Hundreds of 3rd party suppliers. Dozens of product teams with different tech stacks, different timelines, and different risk tolerances.

You cannot govern this with ticket queues and manual provisioning. You cannot secure this by reviewing every pull request centrally. You cannot maintain consistency by writing standards documents that nobody reads.

You can govern it by building a platform that's opinionated by default and consumable by design. You can secure it by encoding security into the modules and guardrails that teams use every day. You can maintain consistency by making the compliant path the easiest path.

The Provider to Consumer model isn't just an operating model. It's a force multiplier. Every investment the Provider makes in a module, a pipeline, or a guardrail pays dividends across every Consumer team that uses it. And when the platform is built for consumability, those Consumer teams don't just tolerate the platform, they depend on it.

Build for consumability. Build the interfaces. Define the boundaries. And then let your product teams build, fast, safe, and at scale.

Your DEV Credentials Shouldn't Be Able to Sink PROD

Lee Wynne — Thu, 26 Mar 2026 10:40:01 +0000

Most engineering teams think environment isolation means having a "dev" and "prod" flag somewhere in their deployment pipeline.

They're wrong.

That approach doesn't isolate anything, it just moves the risk around.

The AWS SDLC Account Pattern with Full Environment Segregation is what serious cloud architecture actually looks like. It's not just a best practice. It's the difference between teams that accidentally push breaking changes to production at 2am and teams that catch those changes before they ever leave a development branch. It's the difference between a breach in your DEV environment that gets contained, blast radius controlled, damage limited - and a breach in DEV that silently walks into PROD, taking customer data with it and sinking the whole ship.

Here's how it works

And here's why every growing engineering team should be building this way.

The Problem With Shared AWS Accounts

If your DEV, STAGING, and PROD workloads live in the same AWS account, you have a blast radius problem.

A misconfigured IAM policy in your development environment can expose production resources. A runaway Lambda function eating through concurrency limits in staging can throttle your live API. A developer testing aggressive auto-scaling rules in dev can hit account-level service quotas that affect production before anyone notices.

But the operational blast radius is only half the story.

The security blast radius from a compromised shared account is where things get truly dangerous.

If an attacker compromises a single access key, an OIDC token, or a CI/CD pipeline role in a shared account, they could inherit access to every environment in that account, including production data, production databases, and production secrets. There is no hard boundary between environments within the same account. One breach, total exposure.

The insider threat picture is equally concerning. In a shared account, an engineer with dev access and enough determination can reach production. You can write IAM policies that try to prevent it, but IAM within a single account is advisory, it can be overly permissive, it can be misconfigured, and it can be escalated.

Account-level segregation makes the boundary physical. A developer credential scoped to DEV simply cannot access PROD without an explicit cross-account IAM role grant, a deliberate architectural decision, not a policy footnote that someone forgot to update.

Shared accounts feel cheaper and simpler at first. But as your team grows and your infrastructure complexity increases, shared accounts become a liability. You can't enforce strict RBAC by environment. You can't audit cost by environment cleanly. And you certainly can't guarantee that a bad deployment in your lowest environment won't propagate upward.

The solution isn't better tagging or smarter guardrails within a shared account. The solution is account-level segregation, and AWS Organisations makes it operationally feasible to implement properly.

Three Accounts, One Purpose Each

The pattern separates workloads into three completely isolated AWS accounts, each serving a single purpose.

The DEV Account is for feature development and integration testing. Engineers deploy more freely here. Branches get their own environments when needed. Nothing here is permanent, nothing here is customer-facing, all private zero-trust. The URL pattern (dev.domain.com) makes it clear that this is development. The cost here is intentionally low, and it should report as such.

The STAGE Account is a production replica. Same resources, same network architecture, same IAM setup as production, just without real customer traffic. This is where UAT happens, where load tests run, and where you validate that what you're about to ship actually behaves like you think it will. Stage sits at stage.domain.com, nothing here is customer-facing, all private zero-trust and it should scare you slightly to deploy there. That fear is useful.

The PROD Account is the one that matters. Blue/green deployments running at domain.com, with traffic switching done deliberately and with rollback paths tested in stage first. Nothing reaches PROD that hasn't passed STAGE. That's not a policy suggestion it's enforced by the pipeline architecture itself.

Account-level segregation means there's no accidental blast radius between these environments. A misconfigured resource in DEV literally cannot affect PROD, they're in different AWS accounts with separate IAM boundaries, separate VPCs, and separate billing.

One Infrastructure Repo, Three Environments

Infrastructure-as-code is non-negotiable at this scale, and the pattern uses a mono-infra approach with Terragrunt to manage it cleanly.

A single Git repository contains the infrastructure for all three accounts, organised into three folder paths: /prod, /stage, and /dev. Each folder contains the Terragrunt configuration for that account, same modules, different variable files and remote state backends.

Why Terragrunt? Because raw Terraform at this scale leads to copy-paste hell. When you need to update your VPC module, you want to change it once and have it propagate through environments in a controlled way, not hunt down three duplicated configurations and hope you got them all. Terragrunt's include blocks and dependency management let you DRY up your infrastructure code the same way you'd DRY up application code.

The mono-repo structure also enforces a natural promotion pattern: infrastructure changes move from dev to stage to prod via pull requests, with review and approval gates at each stage. No environment drifts silently. Every difference between PROD and DEV is intentional and reviewable.

Two PR Workflows, One Direction

The pattern distinguishes between two distinct flows, and most teams conflate them at their peril.

The infra workflow governs changes to the infrastructure itself, the Terraform modules, the VPC configs, the account baselines. These PRs are raised against the infrastructure mono-repo and require review from the people who understand the blast radius of an IAM policy change or a security group modification. Infrastructure changes flow from DEV account config to STAGE account config to PROD account config.

The app workflow governs application deployments, the code that runs inside the infrastructure. A feature branch gets deployed to DEV, a PR merge to main triggers a STAGE deployment and automated test suite, and a deliberate promotion step moves the release to PROD. These workflows live in the application repos, not the infra repo, but they reference the same account structure and environment naming conventions.

Keeping these workflows separate matters because they operate at different risk levels and different cadences. Application code might deploy to production daily, infrastructure changes might go through a full change management process. Mixing them creates confusion about who reviews what and what the rollback options are.

Shared Services, The Fourth Account You Don't Often See

Here's where many AWS multi-account architectures fall short, they model the application environments well but neglect the shared services problem.

Every environment needs to pull container images. Every environment needs identity and access management for users. If you solve that independently per account, you end up with three separate ECR registries, three separate Cognito user pools, and a synchronisation problem that compounds over time.

The SDLC Account Pattern includes a Shared Services Account that sits alongside the three environment accounts.

ECR and Cognito are good examples:

ECR: All three environments pull from the same registry. A single image build, tested and tagged, gets promoted across environments without rebuilding. The image you ran your integration tests on in STAGE is exactly the image that ships to PROD, no surprises, no environment-specific build drift.

Cognito: Rather than duplicating user pools per environment, Shared Services hosts the identity plane. Environment-specific configurations reference the shared pool, with appropriate user segmentation between DEV, UAT, and PROD user groups.

The Shared Services Account uses Zero Trust connectivity to each environment account. explicit, least-privilege cross-account IAM roles with no implicit trust assumptions. A resource in PROD pulling an image from ECR gets exactly the permissions needed for that operation, scoped to that resource, with no ambient access to anything else in the Shared Services Account.

The Provider to Consumer Model

The governance philosophy underpinning this entire pattern is closer to a shared responsibility model than a simple owner/user split and it's worth being precise about what each side is responsible for.

The Provider is the platform team. They own the AWS Landing Zone, manage core transit networking, and maintain the version-controlled VPC configuration that defines how accounts connect and communicate. They vend new AWS accounts on request, applying a security baseline before a single line of application code is ever written, SCPs, GuardDuty, centralised logging, IAM boundaries, the works. When a new team needs an environment, the Provider provisions the account, attaches the consumer's mono repo, and hands over something that's ready to build in.

The Consumer is the workload build team. They inherit a fully baselined, network-connected AWS account with a repo already wired up. Their job is to build product inside the guardrails the Provider has established, not to manage networking, not to configure security tooling, not to think about account structures. That separation is the whole point.

This clean division is what makes the pattern scale. The platform team can iterate on the landing zone and security baseline without touching application code. Application teams can ship fast without becoming AWS infrastructure experts. And when something goes wrong in a consumer account, the Provider's controls mean the blast radius stops at the account boundary.

Why This Matters Now

Multi-account AWS architecture used to be something only large enterprises could afford to implement. AWS Organisations made it accessible to teams of any size. Terragrunt has made it maintainable. And several high-profile production incidents, caused by developers with too much access in too few accounts, have made the case for account-level segregation non negotiable.

The AWS SDLC Account Pattern isn't about adding complexity. It's about moving complexity from the runtime, where a mistake becomes an incident, to the design phase, where a mistake becomes a PR comment.

Build environments that are safe to experiment in. Build a staging environment that earns its name. Build production isolation that actually works.

The principles this pattern encodes are the right ones. Your implementation will vary, but if you're not operating with account-level segregation today, start planning the migration.

The 2am call, the compromised key, the rogue credential, they all get a lot quieter with a bulkhead between them and production.

Help with open graph previews

Lee Wynne — Sat, 03 Dec 2022 16:25:24 +0000

Hey there,

Just a qq if anyone can help. I am looking to build a simple html/css/js one pager and I'd like to embed open graph previews for other sites in it.

Similar to what Forem are doing here - (these cards are dynamic and update if the original meta tags update)

Anyone have any code examples?

Thanks!

How to cross post and import your existing blog into DEV and retain SEO, original source and ranking.

Lee Wynne — Mon, 01 Aug 2022 13:27:00 +0000

There was an article on DEV somewhere that inspired this post, I can't find it though, I'll embed it in as soon as do.

A quick cross-posting lesson — What is it?

Cross-posting is a term for posting something in multiple places at the same time (or having automation that re-posts for you to the same effect).

The term goes way back to the early days of the Internet when newsgroups were popular. When you wrote a message for a newsgroup, it was called a post. You posted your post to the newsgroup that was the most relevant, and if your message had relevance to other newsgroups as well, you could post it to multiple at the same time; this was called cross-posting and it was done to reach a broader audience.

Today, cross-posting often refers to the practice of re-posting articles from a personal blog to different outlets. For example, I might have a personal blog with articles about dev and want to share these articles right here on DEV; I could decide to cross-post articles from my blog to this community. And on that note, let's talk about how it's done...

So, how am I going to achieve this with my current blog?

DEV has built-in tooling that allows you to approach this in a couple of ways!

First, we'll discuss how you import an existing post into DEV using an RSS feed.

Importing your blog articles via RSS and cross-posting them to the community

The basic idea is that if you have an existing RSS feed on your blog, you can then subscribe to that feed from your DEV account, import those posts into your user dashboard as drafts, sort out any formatting issues if needed, and post them to the broader community.

Here's how to get it set up!

First, login and click on your profile picture at the top right. Then hit settings (towards the bottom).

Once you are in settings, go to 'Extensions'

Scroll down a little bit and you'll see 'Publishing to DEV Community from RSS'

Drop the URL for the RSS feed from your existing blog into the 'RSS Feed URL' section.

Now, select the 'Mark the RSS source as canonical URL by default' to add this to every imported post, this notifies any search engines that this is the primary version and where the original source is. We'll talk more about why this is important below.

Note: you can also set the 'Replace self-referential links with DEV Community-specific links to replace existing links from your post with DEV specific links. Most people want these links to exit back to their original blog, so feel free to keep this unchecked.

When ready, click Submit Feed Settings and any posts on your personal blog should be imported into your user dashboard as drafts. From here, you can review posts to ensure they imported nicely, correct any formatting changes if needed, and publish them all at once or on whatever schedule you'd like.

Note: you can continue sharing posts on your personal blog and these new posts should import into your user dashboard as drafts whenever published. In other words, if you set up Publishing from RSS, you shouldn't need to manually import new posts each time, but instead they will filter in as drafts automatically. You will need to publish your drafts for these posts to officially go live.

Cross-posting a single article

If you'd rather not import your entire blog or can't because you don't have RSS set up for it, you also have the option to cross-post a single post by copy/pasting it over.

Once you have finished pasting your article into the editor, we recommend heading to the bottom of the post and hitting the little pentagon shape.

From here, you can paste the original link of the post for your blog in the canonical URL field and away you go!

But hang on, aren't I just giving up my content, SEO, and Google rank every time I cross post?

Nope! DEV have accounted for that by providing authors a way to input a canonical URL for any articles that they are crossposting from another source. This way your SEO is unharmed and, in fact, should be helped.

Despite its cryptic name, a canonical URL is simply a way for you to add information to a post on Dev that indicates where the TRUE (or authoritative) original source of that post is.

Why is this important? Because it tells search pages where the primary content is found and that any cross-post is a legitimate copy.

Setting the canonical URL for your blog post means the original source of your post gets credit from Google whenever the cross-posted version of your post is viewed. In turn, this drives traffic to your blog site (or wherever the original post was posted) and helps build your personal brand.

Keep calm and carry on crossposting

That's it! Dev can help you build your brand wherever you are doing it, come as you are to Dev and let's grow together. 🎉

I remember understanding < 5% of the Dev homefeed, now I understand most of what I see. Bravo Dev 👏 Bravo!

Lee Wynne — Sat, 09 Jul 2022 14:41:45 +0000

I love this community, I hope that there are others here that have had the same experience as me. If so, please let me know in the comments 🫠

Can anyone recommend a little toolbox of Ruby goodies?

Lee Wynne — Wed, 15 Jun 2022 14:16:01 +0000

More specifically a secret stash of:

Scripts
Tools
Utilities
Re-usable classes and methods (for repeatable stuff like web scraping, file read and writing)

Server side or client side rendering? Vue | React + Rails API

Lee Wynne — Tue, 07 Sep 2021 19:28:57 +0000

Hey 👋

I am thinking of a side project that will leverage a Rails API backend (because I love it, it makes me happy, no science or general logic involved in that decision).

The front end is likely to be Vue or React depending on which one integrates with crypto wallet sign in the easiest (specifically metamask or nami).

Question: What’s the benefit to doing Vue / React with Rails server side versus client side?

thanks

What do cats, AWS, machine learning, and neural networks have in common?

Lee Wynne — Wed, 19 May 2021 15:27:45 +0000

Learning about machine learning and neural networks can seem daunting. It sounds hugely complex and out of reach of learning for some people, but it doesn't have to be..

For help, look no further than that furry, anti-social, hissing, fish-loving, saber-toothed, 'not so sure if he would kill you if he/she were bigger', head-butting, tinkle-tush wearing (yes that is a real thing, Google it), box pooping, hairball coughing, carboard box loving, butt licking, personal space invading idiot of a feline friend of yours.

So what do Cats have to do with machine learning again? Well, it all begins with a quest to learn more about how machine learning works.

So far, AWS has a done a great job of abstracting some of the most popular models for machine learning and made them available as off-the-shelve services which means that in order to use them, all you need to do is interface with the API for that particular service.

But if you are just beginning your quest to understand machine learning that isn't a great place to start, is it?

YouTube is obviously a great way of picking up the concepts of machine learning and how neural networks learn. Here are some of the best I have seen so far:

It get's way more complex after that first video!

And good ole Lex Fridman from MIT

Here is Lex's Podcast btw, you can listen to him right here on the elastic guru.

But is it all still fairly complicated and it is likely that you'll hit that steep learning curve and maybe give this whole machine learning and neural network thing a miss.

DON'T DO THAT

Machine learning and neural networks (including AI) are going to be big (they are already biiiiiiig) and knowing about it can only pay dividends in the future, trust me, your future self with definitely thank you for it.

Personally, I am a very visual learner. I take lots in when I can see it conceptually and when I can play with it and see the results, with that in mind, the one thing that I enjoyed the most when learning more about machine learning, was a game called while True: learn()

while True: learn() is a puzzle/simulation game about even more puzzling stuff: machine learning, neural networks, big data and AI. But most importantly, it’s about understanding your cat.

In this game, you play as a coder who accidentally found out that their cat is extremely good at coding, but not as good at speaking human language. Now this coder (it’s you!) must learn all there is to know about machine learning and use visual programming to build a cat-to-human speech recognition system.

👆 At least you know now where the cat fits into all this.

Here is a brief demo of the gameplay:

while true: learn() has great reviews on steam and trust me, you don't need to be technical at all to play it.

You can play while true: learn() on PC, iOS, Android, and macOS.

The creation of while true: learn() also has a fantastic back story.

I'll give you one hour with the game before it click, you'll know the basics of machine learning and neural networks without reading a single blog post.

Enjoy!

Why did you get into coding? Did you really want to code?

Lee Wynne — Tue, 11 May 2021 13:43:03 +0000

I ask this question because from my own experience, thinking back to when I started I am beginning to feel like I really wanted in on the developer community (particularly Rails) and the lifestyle (being able to work anywhere).

I wanted friends that were dev’s as they always came across as some of the nicest people on earth.

I also wanted to have readability of code before I actually felt comfortable writing code, I thought that looking at a method and being able to figure out what it’s manipulating, and how, would be really cool.

Is that odd? Wanting to get into code without having a massive urge to write it?

I wasn’t disappointed btw, the friends I have made in the dev community have proved to be some of the kindest, helpful, thoughtful, supportive and deep thinking, principled humans I could have ever wished for.

Being able to read code (as well as write it) has also turned out to be really cool 😎

How’s about you? We’re there things that pulled you into a Dev life that has nothing to do with code, but now your coding?

Are native html reusable templates a thing?

Lee Wynne — Thu, 15 Apr 2021 08:53:04 +0000

Hypothetically speaking, if you are building a web app using just plain html, css and JS (no frameworks) do developers use reusable html components using the tag?

I understand that in Rails there are partials and in JS frameworks there are components etc.

I am just curious to hear what has been used in the past for native html,css & js at scale.

Wordpress blog in a Rails app subfolder 🙈

Lee Wynne — Sun, 11 Apr 2021 19:07:12 +0000

Hello peeps 👋🏼

As anyone in the Dev community successfully added a Wordpress blog to a subfolder in a rails app?

myapp.com (rails)
myapp.com/blog (wordpress)

I have done a few rounds of googling but haven’t yielded any confident results.

I am thinking that page rules within Cloudflare might be the answer but apparently Wordpress likes to be at the root domain or subdomain.

I know I could use Rails as the blog but I can’t be 🍑’sed atm as I can just use the huge Wordpress plugin systems for stuff I need quickly.

Thanks 😊 and in return I can do portraits of anyone that can shed clear informations on said subject.