30 / 33AWS Consulting

AWS consulting, starting with the bill nobody has read

Canadian AWS consulting from a CCIE-led team, covering the account structure and the monthly bill.

Talk to an architectSee what's covered
  • CCIE-led architecture practice
  • Control Tower and multi-account design
  • Canadian data residency
THE WORK

AWS consulting, three pillars, one operator.

One Canadian team structures the accounts, reads the bill, and runs what's left. AWS migration, AWS managed services and AWS cost optimization are three different purchases, and most estates need them in that order.

  1. 1

    Accounts and landing zone

    A structure with separate blast radius, guardrails and centralised logging, built on what AWS recommends now: Control Tower as the foundation, with Landing Zone Accelerator where regulated controls demand it.

  2. 2

    The bill, line by line

    Every service, region and orphaned resource mapped to an owner and a reason, with the findings costed and ranked before any work is proposed.

  3. 3

    The run, handed over or held

    Patching, guardrail drift and cost review on a cadence, either transferred to your team with the runbooks or operated by ours.

THE PROOF

Built to last. Evidence over promises.

AWS Landing Zone isn't what you build now. Control Tower plus the accelerator is, and the difference shows up in what a proposal quotes by name.

IN PRODUCTION

A bill a Canadian finance team could audit.

Everything ran in one account and the invoice was a single number nobody could break down. We took read-only access and came back with a list. Forty percent of it was storage snapshots from a project that ended in 2024, still replicating to a second region. Nobody had been wrong. Nobody had been looking.

SMEnode · Engineering principle
  • CCIE Data Center
  • CCIE Security
  • CCDE Design
  • Canadian data residency
THE DEEP DIVE

AWS consulting in Canada, made real.

Two things go wrong on AWS, and they aren't the ones people expect. The account structure, and the invoice.

The account structure everything else inherits.

Start with the structure, because everything else inherits it. Most estates we see grew inside a single account: one blast radius, one set of credentials, no separation between production and the thing somebody built to test an idea in 2023. A landing zone fixes that by giving each workload its own account with guardrails, centralised logging and a security account that can see everything and change nothing. What AWS recommends here changed, and a lot of proposals haven't caught up. The current pattern is Control Tower as the foundation, with Landing Zone Accelerator layered on for the controls a regulated estate needs.

Reading the invoice against reality.

Then read the invoice properly, which almost nobody does. The risk sits in two places. Resources nobody owns, because the person who created them left and the tag was never mandatory. And commitments bought against a shape the estate no longer has, so you're discounted on the wrong thing. Both are found by reading the bill against reality rather than against last month's bill. Landing Zone Accelerator itself carries no licence charge, which is worth knowing, and it still isn't free to run.

Residency, procurement and the Canadian angle.

The Canadian angle is residency and procurement. AWS runs Canadian regions, so keeping regulated data in the country is a configuration decision rather than an obstacle, and it's one a guardrail can enforce rather than a policy document requesting it. What needs watching is cross-region replication switched on by a default somebody accepted, and billing in US dollars against a Canadian budget. We don't resell AWS, or the other two hyperscalers, so we're free to tell you when a workload suits a different platform, or belongs on hardware you own instead of in public cloud at all.
CA
Multi-cloud mesh
THE METHOD

How our AWS landing zone and cost optimization work runs.

Four steps, and step 01 needs nothing from you but read-only access. We'd rather look before proposing, because an AWS estate is unusually knowable from the outside: the billing data and the resource inventory tell you most of what a discovery workshop would, and they don't flatter anybody. About half of what we find in that first pass is fixable without a project.

  1. Step 01

    Read the estate

    Read-only access across accounts, the full billing export, resource inventory and tag coverage. Findings costed and ranked before anything is proposed, so you can see the size of the problem before you commit to fixing it.

  2. Step 02

    Design the structure

    Organisational units, account separation, guardrails and centralised logging, built on Control Tower with Landing Zone Accelerator where the controls demand it.

  3. Step 03

    Fix the bill

    Orphaned resources retired, storage tiers corrected, commitments matched to the shape the estate actually has rather than the one it had when somebody signed.

  4. Step 04

    Hand it over or hold it

    Runbooks, guardrail drift checks and a cost review cadence, either transferred to your team with training or operated by ours. The account stays yours either way.

QUESTIONS

AWS consulting questions, answered straight.

Answers first, including the one where the fix needs no project. An architect takes the call.

Control Tower is how you build a landing zone now, so it isn't a choice between two things. AWS's guidance is Control Tower as the foundation, with Landing Zone Accelerator layered on when you need controls it doesn't cover natively, which usually means a regulated estate. The older standalone solution has been superseded. If a proposal quotes it by name as the thing being built, that proposal is out of date.

Usually, and the first pass rarely needs a project. Read-only access plus the billing export finds the same three things in most estates: resources nobody owns, storage sitting in the wrong tier, and commitments bought against a shape the estate has since outgrown. We cost and rank the findings before proposing work, and some clients take the list and fix it themselves. That's a fine outcome.

We run reviews with the AWS Well-Architected Tool, which is free and open to anyone, and we report against its pillars. What we don't claim is the badged partner-programme review and its associated funding, because that requires a designation and implying otherwise would be dishonest. If the funding is what you're after, ask us and we'll tell you who holds it.

No. We don't resell AWS capacity and we take no margin on your consumption, so the account, the billing relationship and the console access stay yours. We're paid for the engineering work, which is why we can tell you to turn something off, keep a workload where it is, or put it on a platform we'd earn nothing from.

No, and existing estates are the more common engagement. A first-time move has a clean slate and a plan. An estate that grew over four years has accumulated accounts nobody structured, resources nobody owns and guardrails nobody enforced, which is harder to unpick and usually cheaper to fix. The read in step 01 works either way, and it tells you which of the two you actually are.

When you run one small workload and a single engineer understands it, since a structure built for scale you don't have is overhead. When the real problem is one unowned resource, which the first pass finds and you can delete yourself. And when the platform decision hasn't been made yet, because that's an architecture conversation and this isn't it. We'd rather do the read and hand you the list.

LET'S CONNECT

Ready to build a stronger,
smarter network?

Explore our servicesBook a free consultation

A senior engineer replies within an hour, 24/7.