Cloud Infrastructure

Cloud-Native Infrastructure

Portable by Default

I design cloud infrastructure around the workload, not the provider’s feature list. A service should keep working when its current vendor becomes expensive, unavailable, or unsuitable.

I have worked on AWS production infrastructure for over a decade, including five years hosting one of the world’s top 500 websites — a site ranked around 130–140 in the United States.

What I deliver:

• Cloud architecture sized to the workload and its failure budget
• Provider-portable configuration for compute, network, DNS, storage, and secrets
• Multi-host coordination, private networking, and least-privilege access paths
• Cost modeling and rightsizing with the responsible resources named
• Backup, disaster recovery, and restoration testing

You get:

• Capacity that follows real traffic rather than a guessed instance class
• Configuration that can move when the provider or its pricing changes
• A smaller public attack surface with explicit ingress and egress paths
• A cloud bill whose important lines can be traced to a workload

Architecture Before Provisioning

Before creating a resource, the design needs an answer for each part of the system: where the workload runs, what it depends on, what may be exposed, how state is recovered, and what happens when the primary region or provider is unavailable.

That produces a small set of decisions:

1. Workload shape — stateless, stateful, batch, or latency-sensitive; each has a different failure and scaling model.
2. Network boundaries — public ingress, private service paths, administrative access, and egress policy.
3. State and recovery — what must be backed up, how quickly it must return, and where the second copy lives.
4. Identity and secrets — who and what can reach each resource, and how credentials enter the system.
5. Portability — which provider-specific choices are deliberate and which can be replaced.

Providers, Not Lock-In

I build on Oracle Cloud, AWS, DigitalOcean, Hetzner, and others according to the requirements. Provider-specific managed services can be a good fit; they become a problem when the same operation needs a rewrite for every provider.

The goal is not artificial multi-cloud complexity. It is to keep the expensive, high-churn decisions replaceable: compute, DNS, object storage, network boundaries, and deployment automation.

Cost Work That Survives Contact With the Bill

Cloud optimization starts with an inventory: what exists, what each resource serves, and what it actually costs. Idle instances, unattached disks, oversized databases, egress charges, and duplicated logging are common findings.

Each recommendation carries the observed number and the expected change. The result is a prioritized list tied to workload behavior, not a generic list of instance families that happen to be smaller.

Recovery Is Part of the Architecture

A snapshot is not a recovery plan. The backup needs a documented owner, encryption, retention, an off-provider copy where appropriate, and a restore test that proves the bytes return in a usable state.

Recovery time and recovery point are design constraints. If the business cannot tolerate an hour of stale state or a day of data loss, the architecture and its costs have to reflect that.

For service-level monitoring and the alert paths that make cloud failures visible, see Monitoring & Observability. For the deployment and configuration pattern that makes resources reproducible, see DevOps & Automation.