AWS DevOps / SRE

This profile represents the infrastructure shape most product teams eventually need: someone who makes AWS boring, reproducible, and affordable so the rest of the team can ship.

Background

Eight years across DevOps and SRE roles, all of it on AWS, most of it for SaaS and fintech companies where uptime and audit trails both matter. The typical arc for this archetype starts with automating deployments nobody else wanted to own, then grows into full responsibility for the infrastructure under a revenue-carrying product. Builds everything as code with Terraform, runs workloads on Kubernetes, and automates the rest with Python. Has been on call for the systems they built, which shows in how they build them.

What the work actually covers

Infrastructure as code. Not just “we use Terraform” but a multi-account AWS setup with separate accounts for production, staging, and tooling, remote state with locking, and modules small enough that a new engineer can read a plan output and understand what will change. Plans run in CI on every pull request, so infrastructure changes get reviewed the way application code does. IAM is scoped per service instead of shared admin keys, which is the difference between passing a fintech audit and failing one.

CI/CD. Pipeline design from commit to production: build once, promote the same artifact through environments, and make rollback a tested one-step action rather than a theory. This archetype has usually lived through a deploy process that took an afternoon and a person, and has strong opinions about never recreating one.

Observability. Metrics, logs, and traces wired up with CloudWatch, Prometheus and Grafana, or a commercial tool like Datadog, depending on what the team already pays for. The senior habit is alerting on user-facing symptoms such as error rate and latency, not on every CPU spike, so on-call pages mean something. Where the team is ready for it, that extends into SLOs and error budgets.

Incident response. Runbooks written before the incident, an on-call rotation that does not burn people out, and postmortems that end with a fixed class of problem instead of a blamed engineer. Someone who has carried a pager for their own architecture designs differently than someone who has not.

Cost. Reads the AWS bill line by line: tagging so spend maps to teams and features, rightsizing instances against actual utilization, savings plans for steady load, spot for stateless workloads, storage lifecycle rules, and the NAT gateway and cross-AZ traffic charges that quietly grow. Cost work is treated as engineering, not procurement.

Seniority signals

The gap between eight years and three in this role is mostly scar tissue. Signals worth probing: they can tell you when Kubernetes is the wrong answer, not just how to run it. They have executed at least one migration with production traffic on the line and can walk you through how they sequenced it. They talk about cost per environment without being asked. They can describe a real outage plainly, including their own mistakes and what changed afterward. Juniors describe tools; seniors describe decisions and trade-offs.

What to look for if you are hiring this archetype

In interviews, ask the candidate to walk through an incident they owned end to end, from page to postmortem. Ask how they would break up a single 5000-line Terraform configuration that three teams edit. Ask what they alert on and why. A strong candidate will also interview you back: deploy frequency, team size, and what already exists, before proposing any tooling. Red flags include reaching for a service mesh or multi-region setup before understanding the product, being unable to explain the current bill, and treating staging environments as optional.

Engagement fit

Best fit is a product team of roughly 5 to 50 engineers where infrastructure is currently owned by whoever touched it last. Common engagement shapes: a fixed-scope infrastructure audit, a migration project with a defined end state, or an embedded platform role inside the product team, full-time or part-time. Less of a fit if what you really need is application feature work, or if you already have a staffed platform team, in which case the Kubernetes platform archetype in this pool is the closer match. Rates for this archetype typically land in the band shown on this card and move with seniority and region.

Typical engagement

Often starts as an infrastructure audit or migration, then continues as an embedded platform engineer for a product team. European hours with afternoon overlap into US Eastern. Available in about two weeks.

This is a representative sample of the vetted pool. Request it and we confirm real, current availability for a developer with this background.