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.
One engineer leads the work from the first call to the handover. The method is the same 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.
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
For an existing estate
When infrastructure already exists, we usually start with EdgeAssess.
Against a live estate the first step is usually EdgeAssess: quoting delivery for an estate nobody has looked at is guesswork you would pay for. Some teams read the assessment and do the work themselves — a good outcome, and the report is written to allow it. For investors the equivalent is EdgeSignal: same evidence discipline, different reader.
The EdgeAssess 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.
Twenty minutes, nothing to prepare. You tell us where you are starting from, we show you what the work produces, and we work out whether there is something worth doing — with us or not.
Who you deal with: The engineer who would do the work. No account manager, and nobody whose job is to sell.
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 defined as code, 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.
On AWS, discovery uses a scoped cross-account IAM role that InfraEdge assumes with temporary credentials and a unique external ID. Azure and GCP follow the same pattern: a scoped identity over the subscriptions or projects you name. Access is configuration read only. Greenfield projects can start before there is anything to inspect.
Who you deal with: The same engineer, working with your technical owner to agree which accounts are in scope before the role is created.
- 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 EdgeAssess or EdgeSignal report is the last link in a chain that starts with an artefact you can open. The specimens alongside show that evidence-to-change shape — worked illustrations in the report’s own idiom, not customer records.
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.
Who you deal with: The engineer who did the assessment, on a call with your team: what each finding risks, the evidence, and what we would do first. You set the order.
Deterministic checks run first and are recorded before any further analysis, so no finding can be quietly dropped.
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.
These figures are a worked specimen showing the shape of the coverage summary, not an average across engagements. Real coverage depends on what a particular estate exposes to a read-only role.
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.
No fixed end date: one named production problem, a full baseline, or a programme that runs for quarters. The route never changes. A commit produces a plan — a Terraform plan, a CloudFormation change set, a Pulumi preview — the plan passes the policy gate, and then it stops. The gate is drawn as a valve because it behaves like one — normally closed, opened by hand.
Who you deal with: The engineer writes each change and answers your reviewer on the pull request. Your named approver decides whether it ships.
Git is the intended change-control plane, not a claim that nothing happens outside it. When the pipeline itself is broken you need a way in, so we build a governed break-glass path: time-bound access, logged use, a review afterwards, and anything lasting folded back into code. An emergency that leaves no trace in the repository is next quarter's drift.
Your approval binds to a plan, not to a conversation.
Here an approval means a named person approved one specific plan, saved and identified by its hash, and the apply runs that saved file — not a fresh plan generated a moment later. Change a resource after approval and the approval is void. Destructive changes to protected resources are never 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.
Who you deal with: The engineer hands over to whoever will run it: the runbooks, the decision record and the backlog, with pairing agreed in the scope.
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.
Request a 20-minute triage call
Twenty minutes, no charge, with the engineer who would do the work. 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.