Services

Cloud Infrastructure

Cloud infrastructure work covers the architecture and provisioning underneath everything else on AWS: networking, compute, storage, and the Infrastructure-as-Code that defines it. Done properly, Git reproduces an environment entirely, replacing undocumented configuration.

I use Terraform to define infrastructure, Ansible for configuration management, and Packer for reproducible machine images. These tools ensure changes are version-controlled and reviewable, rather than made by hand and forgotten.

The network layer does not always belong to a cloud provider. I also work with VyOS for routing and firewalls, WireGuard for site-to-site and remote access, and OSPF when a self-managed network fits the job.

Problems this usually starts from

These issues usually prompt a conversation:

  • Infrastructure changes happen by hand in the console and get forgotten.
  • No single source of truth exists for what runs versus what is documented.
  • Scaling under load relies on guessing rather than planned capacity.
  • Environments drift apart, leaving staging looking nothing like production.
  • Machine images are built and patched manually instead of reproducibly.
  • Nobody feels confident they could rebuild a full environment from scratch.
  • Costs creep up without clarity on which resources remain in use.

What an engagement looks like

I start by understanding what runs on AWS today, and how far it has drifted from documentation or version control. From there, I define infrastructure with Terraform, manage configuration with Ansible, and build machine images with Packer so changes go through review instead of manual clicks.

Scope is either a fixed piece of work (bringing one environment under Infrastructure-as-Code, an architecture review) or an ongoing placement. The deliverables are concrete: version-controlled, reviewable infrastructure that could be rebuilt from Git.

Typical work includes Terraform modules structured to keep environments identical instead of quietly diverging, Packer-built images that require no hand-patching after launch, and Ansible playbooks that replace manual SSH fixes with repeatable, reviewed code.

Scope can start small and grow once the working relationship fits. You can buy work a piece at a time or as a block of days each month. Both are fractional DevOps. The engagement and pricing page details how I agree on and price work.

Questions

Remote or on-site?

Either — depends on the engagement. Comfortable with a regular on-site day where required.

Long contracts only, or shorter work too?

Both. That includes urgent, one-off issues — infrastructure that’s failed or misconfigured, a scaling problem under load — not just fixed-scope projects or longer placements. No running contract required to get started on something like that.

What if infrastructure is already partly on Terraform?

Fine — the usual starting point is finishing what’s already underway rather than starting over.

Which AWS services do you work with most?

Whatever the workload needs — commonly EC2, ECS/EKS, RDS, and S3, along with the networking layer underneath (VPC, ALB, Route 53) — defined through Terraform rather than clicked together by hand.

Do you help with cost as well as architecture?

It usually comes up as part of the same work — infrastructure that’s properly defined and right-sized tends to cost less than infrastructure nobody’s audited in a while.

Do you work multi-cloud, or AWS only?

AWS is where most of the day-to-day experience is, but the same Infrastructure-as-Code approach — Terraform, Ansible, Packer — applies regardless of which provider it’s pointed at.

Get in touch

Also