A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
The two roles get conflated constantly, and the conflation is expensive because they fail in different directions.
A DevOps engineer makes your delivery work: pipelines, infrastructure as code, observability, the day-to-day of running services. A cloud architect decides the shape of the thing underneath — account and subscription structure, network topology, where data lives and why, which managed services you are willing to be tied to, and what the bill looks like at ten times current volume.
The distinction that matters is reversibility. A bad pipeline is annoying and can be rebuilt in a fortnight. A VPC whose address range was sized for the company you were three years ago, or an account structure that cannot express the separation your auditor now wants, is not a fortnight of work. It is a migration with a change-freeze attached.
Hiring a strong DevOps engineer to make architectural calls usually produces something that works and is difficult to change later. That is not a failure of ability. It is a failure of scope.
We screen for judgement about permanence, not for the number of services somebody can name.
Whether they distinguish decisions that bind you for years from decisions that can be changed on a Tuesday. The core of the role.
Address planning, segmentation, and multi-account structure — including having lived with the consequences of getting one of them wrong.
Egress, cross-zone transfer and storage class economics understood at design time rather than discovered on an invoice.
Choosing managed services deliberately, with the cost of leaving written down rather than assumed to be zero.
Willingness to tell a business that multi-region, or a service mesh, or a cluster, is not worth what it will cost them.
A live conversation in English, every time. An architect who cannot explain a trade-off to a finance director is only half useful.
Cloud architecture mistakes are rarely outages. They are constraints that arrive years later, attached to a project nobody wanted.
Address space is the purest example. Somebody picks a small private range for the first environment because it looked sufficient. It is fine for years. Then you acquire a company, or need to peer with a partner, and the ranges overlap. Peering will not work. Now you are renumbering a production network, or standing up translation you will maintain forever, to solve a problem created by one line of configuration nobody reviewed.
Cost decisions compound the same way, but faster. Egress and cross-zone data transfer are billed per gigabyte and almost never modelled during design. A chatty service split across availability zones for resilience can spend more moving bytes between zones than it does on compute — and because the charge appears as a data transfer line rather than against the service, it survives several rounds of cost review without anyone connecting it to the architecture that causes it.
Then there is the lock-in nobody priced. A managed service chosen for speed shapes your data model around it. Two years on, moving is not a migration of infrastructure but a rewrite of application logic. Sometimes that trade was correct. The problem is that it usually was not a decision — nobody wrote down what it would cost to leave, so nobody weighed it.
Cloud Engineer (3–5 years). Builds what has been designed. Comfortable with infrastructure as code, networking basics and the common managed services. Not yet making decisions that bind the organisation.
Cloud Architect (5–8 years). Owns network and account design, chooses managed services with the exit cost written down, and models spend before it is committed rather than explaining it afterwards.
Principal Architect (8+ years). Owns the landing zone and multi-account strategy, handles data residency and regulatory constraints, sets the standards other teams build inside, and can tell an executive that a requested capability is not worth what it costs.
Landing zone and account structure. Usually triggered by growth, an audit, or the discovery that everything lives in one account. Foundational and hard to retrofit.
Migration design. Deciding what moves, what gets rebuilt, and what stays. The design is a distinct piece of work from the migration itself.
Cost reduction. Spend that has grown faster than usage. Frequently the fastest measurable return available, and often bounded to a few weeks.
Regulated workloads. Data residency, network isolation and audit requirements that shape the design rather than sit on top of it.
Architecture alongside delivery. Pairing an architect with the team who will build it. See hire DevOps engineers, who typically own the implementation.
Week one. They read the bill before they read the diagrams. A tagged, itemised view of where money goes is the fastest available map of what you actually run, and it usually contradicts the architecture diagram somebody drew last year. Expect questions about account boundaries, address ranges, and which services you would struggle to leave.
Weeks two to four. A written view of the decisions that are difficult to reverse, separated from the ones that are merely untidy. Alongside it, one or two cost changes that can be made without a project — a right-sizing pass, a commitment on steady-state compute, a data transfer path that should not cross a zone boundary.
The warning sign is an architect who starts with a target diagram. A reference architecture produced in week two, before anyone has read the bill or asked what the business is actually constrained by, is a template with your logo on it. Good architects spend the first month establishing what is already load-bearing.
Hiring a DevOps engineer and expecting architecture. The most common version of this mistake, and it produces infrastructure that works today and boxes you in later. If the decisions in front of you are about structure, residency or long-term cost, that is a different hire.
Buying multi-region before you need it. It roughly doubles operational complexity, forces every stateful decision to be made twice, and is genuinely required by a small minority of the teams that ask for it. Most organisations need a tested restore and a credible recovery time, not active traffic in two regions. Be honest about which one your business actually requires.
Treating Kubernetes as the default. It is the right answer for a real set of problems and expensive overhead for everything else. A team of eight running six services does not need a cluster to manage; it needs something that deploys containers and gets out of the way. Ask what the cluster is solving before adopting one.
Designing without a tagging and account strategy. If you cannot attribute spend to a team or a product, every cost conversation becomes speculation. This is trivial to establish at the start and genuinely painful to retrofit across an estate that has been growing untagged for three years.
Rates depend on seniority, cloud platform, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.