01
Greenfield
Starting clean
Little or no existing infrastructure. We design the foundations before production complexity arrives, without over-engineering what the workload does not need yet.
How we work
A short call. Read-only access. Evidence you can open. Changes you approve.
The same motion whether you are designing a first AWS foundation, launching a new workload inside an existing organisation, bridging to a hire, or sorting out production that grew faster than its platform practices.
Start from where you are
New platform or inherited estate — the method adapts.
Some engagements begin with a production estate that grew organically; others with a blank AWS account and a product that has not launched. We work from the actual starting point.
02
New workload
Building within an existing estate
A new workload has to fit the accounts, security and networking already around it, rather than becoming a parallel island.
03
Brownfield
Improving what already exists
Production needs to be understood, secured or standardised. We map the current state, agree what good looks like, and engineer the route between them.
Shared end state
Design & buildIntegrate & extendDiscover & improve
→ Understood, reproducible, secure infrastructure the owning team can operate
We do not prescribe a starting point. We define an end state: infrastructure that is understood, reproducible, secure and operable by the team that owns it.
For an existing estate
When infrastructure already exists, we usually start with EdgeReady.
Against a live estate the first thing is usually EdgeReady: quoting delivery against an estate nobody has looked at is guesswork you would be paying for. Some teams read the assessment, decide the work is within reach of their own engineers and do it themselves — a good outcome, and the report is written so it is possible. For an investor looking at a company rather than a company looking at itself, the equivalent is EdgeSignal: same evidence discipline, different reader.
The EdgeReady fee is credited against anything you book within 30 days, so finding out what needs doing costs nothing if you go on to do it.
Step one
01 / 5
Twenty minutes, and an answer either way.
Not a sales call with a different name, and nothing to prepare. We show you what the work produces, you tell us where you are starting from, and we work out whether there is something worth doing — sometimes with us, sometimes not.
01
We show you what this looks like
The sample report, a real evidence chain, and the pipeline a change travels through. Twenty minutes of that decides more than an hour of description.
02
You tell us where the platform actually is
How many accounts exist, who looks after infrastructure, what is already in Terraform, and how a change reaches production. Not an audit — just enough that we are talking about the same estate.
03
We say what we would do, including nothing
Sometimes the honest answer is that your own engineers could do this from a written list, or that you need a hire rather than a firm. We would rather say so on the call than sell around it.
Nothing is quoted live. If there is work worth doing, a written scope and a price reach you within 24 hours. If we are not the right people, we will say who is better placed.
Delivery clock starts here
02 / 5
Access stays on your side of the boundary.
Existing-estate discovery normally uses a scoped cross-account IAM role in the AWS accounts included in the engagement, which InfraEdge assumes using temporary credentials and a unique external ID. Azure and GCP work the same way in their own terms — a scoped app registration or managed identity over the subscriptions you name, a scoped service account over the projects you name. In each case the access grants only the configuration read required for discovery. Greenfield projects may begin before there is meaningful infrastructure to inspect.
- No shared keys
- Temporary STS credentials
- Read-only
- Named accounts
InfraEdge
AssumeRole
Your AWS environment
Scoped InfraEdge IAM role
- Custom read-only discovery policy
- Named accounts only
- Configuration metadata
AWS resource configuration
- Customer controlledYou create the role.
The role exists in your AWS account and remains under your control.
- Temporary credentialsNo long-lived AWS keys.
InfraEdge uses AWS STS AssumeRole sessions rather than shared IAM user credentials.
- Scoped accessNamed accounts only.
You deploy the role only in the AWS accounts included in the engagement.
- Read-onlyNo production changes.
The discovery role cannot create, modify or delete AWS resources.
Customer controlled. Disable or remove the role at any time to prevent new InfraEdge sessions. Existing temporary STS sessions expire automatically according to their configured session duration.
Configuration plane
What InfraEdge can inspect
- AWS resource configuration and metadata
- IAM roles, policies and trust relationships
- CloudTrail, logging and security configuration
- Backup policies and recovery configuration
- Infrastructure-as-Code and CI/CD configuration when separately scoped
Used to establish what exists, how it is configured and where engineering risk sits.
No production authority
What InfraEdge cannot do
- Create, modify or delete AWS resources
- Deploy applications or infrastructure
- Access accounts where you have not deployed the role
- Read application database contents
- Call Secrets Manager GetSecretValue or SSM GetParameter APIs
The discovery policy does not grant Secrets Manager secret-value or SSM secure-value retrieval APIs.
Repository and CI/CD access is separately scoped and authorised where required. The AWS role does not grant GitHub, GitLab or Azure DevOps access.
View technical access model
Authentication
- AWS STS AssumeRole
- Unique External ID per engagement
- No shared long-lived AWS access keys
Scope
- Customer-owned IAM role
- Accounts you choose to include in the engagement
- Custom InfraEdge discovery policy
Session lifecycle
- Temporary STS session
- Customer can disable or remove the role
- No new sessions after access is removed
- Existing sessions expire at configured duration
Policy philosophy
- Configuration and control-plane discovery only
- Explicit API allow-list where practical
- Explicit deny on secret-value retrieval
- No write APIs
Step three
03 / 5
How a claim becomes an approved change.
Every sentence in an EdgeReady or EdgeSignal report is the last link in a chain that starts with an artefact you can open. The specimens alongside are closed findings in that shape — anonymised, not hypothetical.
Each artefact carries a path, a SHA-256 and a timestamp. If we cannot point at the artefact behind a claim, the claim does not go in the report — not softened, not caveated, out.
- Evidence — configuration and logs collected through the read-only role, hashed and timed.
- Finding — what that evidence shows, with a severity you can agree or record against.
- Remediation — the change as code in your repository, bound to the finding it closes.
- Approval — a named person signs one plan hash; alter the plan and the approval is void.
Deterministic checks run first and their findings are recorded before any analysis stage sees the evidence, so nothing later in the pipeline can quietly drop one.
Existing estate assessment
We tell you what we could not verify.
An unanswered check is not a pass. Every domain records whether evidence was collected, partially available or unavailable, and explains why.
No silent gaps. No false confidence.
Assessment coverage
8 domains assessed
- 7 Complete
- 1 Partial
- 0 Not assessed
- Complete — required evidence collected; the assessment ran
- Partial — some evidence missing; affected checks and reason recorded
- Not assessed — the domain could not be meaningfully evaluated
Coverage tells you whether we had enough evidence to assess the domain — not whether the domain is healthy.
Security & access
- Identity Complete IAM roles, trust policies, MFA and credential posture
- Public exposure Complete S3, security groups, load balancers, public AMIs
- Logging Complete CloudTrail across regions, retention, log archive
Resilience
- Backup and restore Complete Backup policies present — and whether a restore was attempted
Engineering
- Infrastructure as code Complete Coverage, drift, module hygiene
- CI/CD Complete GitHub Actions OIDC, pinned actions, environment gates
Operations
- Cost baseline Complete Cost and usage report, top services, obvious waste
Coverage exception
Identity — deep
Partial6 checks could not be evaluated
Reason
iam:GenerateCredentialReport was not permitted for this account.
The discovery role was not permitted to generate the IAM credential report, so those checks were excluded rather than treated as passes.
Impact
The main identity assessment still ran, but password-age and access-key rotation checks that depend on the credential report could not be verified.
Those checks are marked unavailable and excluded from the healthy score.
InfraEdge
Missing evidence → Partial → reason attached
Bad assessment behaviour
Missing evidence → empty result → falsely healthy
Partial coverage usually means a permission or evidence source was unavailable. Sometimes that is intentional. Either way, the report names the affected checks and explains what could not be verified. Fix the access and rerun — or leave it partial with the limitation recorded.
Step four
04 / 5
Then EdgeResolve — for as long as there is work worth doing.
The part with no fixed end date: one named production problem, a full baseline, or a programme that runs for quarters. What does not change is the route. A commit produces a Terraform plan, the plan passes the policy gate, and then it stops. The gate is drawn as a valve because that is how it behaves — normally closed, opened by hand.
Git is the intended change-control plane, not a claim that nothing ever happens outside it. Every estate needs a way in when the pipeline itself is what is broken, so what we build includes a governed break-glass path: time-bound access, logged use, a review afterwards, and anything lasting folded back into the code. An emergency that leaves no trace in the repository becomes next quarter's drift.
Your approval binds to a plan, not to a conversation.
An approval usually means somebody said yes in a thread. Here it means a named person approved one specific plan, saved and identified by its hash, and the apply runs that saved file rather than a fresh plan generated a moment later. Change a resource after approval and the approval is void — not overridden, void. Destructive changes to protected resources are not part of an ordinary apply: replacing a database is its own scoped change, with its own window and approver.
01 Plan
Terraform plan runsb71e04c8…
02 Approve
Approval binds to that hashnamed approver · 72h expiry
03 Apply
Apply re-checks the hashmismatch → halt
Step five
05 / 5
What you keep when we stop.
No managed service to keep paying for, and nothing important in a tool only we can log into. You should be able to reconstruct the engagement from your Git history and the evidence references, and hand the lot to a new engineer on their first morning.
your-org/infra
main · yours
- infra/ Your repository. Ours is not in the loop.
- terraform/ Every account described in modules you can read
- accounts/ management · identity · log-archive · staging · prod
- modules/ Written to be changed by your team, not admired
- .github/workflows/ plan on pull request, apply behind an approval
- docs/ Runbooks and decision records, versioned with the code
- runbooks/ Written for whoever holds the pager at 03:00
- decisions/ Why, not only what — one file per decision
- inventory/ Every account, workload and owner, regenerated on demand
- BACKLOG.md What we did not do, ranked, with the reasoning
History of the engagement
5 of 61 commits
- a7f21c4 docs: add the restore runbook, with the timing we measured
- 3f9ac21 feat: separate staging and production accounts
- 91be0d7 fix: scope the deploy role trust policy (IAM-014)
- 5c40a18 feat: org trail into a log archive account
- 0e8d33b chore: import the estate into Terraform state
Every change we made is a commit with a message, a plan hash and a named approver. You can reconstruct the whole engagement from git log without calling us — which is the point.
Not just code in Git — identity, recovery and automation that keep running in your accounts after we leave.
Permission-set policies
Scoped to the roles you actually have
- PlatformReadRead-only across the estate
- PlatformDeployCI through OIDC — no stored keys
- PlatformBreakGlassTime-boxed, alerts when used
- PlatformAuditAuditor view, no shared login
Backup and DR plan
RPO and RTO per tier, rehearsed
- DatabasesPoint-in-time restore, timed
- Object storageVersioned, deletion-protected
- Backup isolationOff the workload credential path
- Infrastructure stateTerraform state locked
Repeatable jobs and schedulers
Running in your accounts, not ours
- nightly-planDrift caught before it is a finding
- dev-schedulerNon-prod off outside hours
- restore-drillRestore proof on a schedule
- expiry-watchCerts and secrets before expiry
A working, tested process in your cloud — not a PDF and a login to somebody's portal. Everything above is a file in the repository beside it, not a separate system you have to trust us to keep running.
Runbooks are written for the person holding the pager, who will not be us. The backlog lists what we did not do and why we ranked it below what we did — usually the most useful page in the pack.
Longer engagements often end with a platform engineer we helped scope, sift and interview, arriving to a documented estate rather than an archaeology project — how that works is on the home page.
Book a 20-minute triage call
Twenty minutes, no charge. We work out what would actually help — which is sometimes us and sometimes not. Nothing is priced on the call; if there is work worth doing, a written scope and a price reach you within 24 hours.