Cloud architecture

The cloud grew by accretion, and nobody owns the map

Most cloud environments were built for a smaller business: a smaller application, fewer customers, a handful of engineers. Then new services arrived, accounts multiplied, networks were joined, permissions widened, and the temporary workaround stayed.

A peering connection fixed an urgent integration. Someone created an IAM role so a deploy could finish. A database got a larger instance because it was slow. A production service moved into a new account and nobody revisited the network. Each of those made sense on the day. Together they become hard to explain, expensive to run, and dependent on the few people who remember why.

I help you see the environment you actually have, name the decisions that add cost and risk, and draw a path toward infrastructure that is easier to operate, secure, and grow. I start from what is deployed. Then I work backward from your requirements, your constraints, and the engineering capacity you have.

I get called when a production change needs one specific person to be awake, when nobody can say why two networks are connected, or when the bill keeps rising without a matching rise in customers.

One decision at a time, until nobody can reason about it

Cloud platforms make it easy to create resources, so complexity accumulates without anyone choosing it. Workloads sit across accounts, regions, networks, and deploy systems. Some of it is in infrastructure as code. Some of it was created by hand during an incident or an experiment, and it is still running because nobody knows whether it is safe to delete.

Access got wider to unblock a deploy. Network rules allow more traffic than the applications need. Backups exist and have never been restored. Monitoring says a resource is up without saying whether the business workflow works.

The environment keeps running, which can feel like the architecture is fine. The test is a change. Can the team deploy without undocumented knowledge? Can you say which systems a compromised credential reaches? Can you restore a critical service after a region fails? Can you explain what another thousand customers would cost? If those are hard, the useful next step is a clearer architecture.

What I bring

What is actually running

Before I propose a change, I build a picture from what is deployed: accounts, networks, identity, compute, storage, databases, and the services that connect them. Depending on the platform and the access you can give me, I use the cloud APIs, the command line, the infrastructure-as-code repositories, configuration exports, and the telemetry you already collect.

I mark what is active, what looks unused, what is shared across environments, and what has no owner. I spend the most time on the pieces between systems: route tables, gateways, peering, private endpoints, load balancers, DNS, security groups, and cross-account permissions. Those are what make an environment hard to understand and dangerous to change.

You get a current-state architecture that includes the inconsistencies and the unknowns. If access or evidence is incomplete, I say where the gaps are.

The network, and where trust actually stops

Networks start simple and get complicated one connection at a time. Development needs a shared database. A partner wants a private path. A new application has to reach a legacy service. After a while the relationships are hard to trace and harder to secure.

I trace how traffic moves: virtual networks, subnets, routes, gateways, firewalls, security groups, DNS, private connectivity, ingress and egress, and links outside the account. I say where segmentation is real, where it is only assumed, and where a connection creates a dependency you do not need.

Production should not be reachable from development without a reason you can state. A sensitive workload should not inherit broad network access because it shares infrastructure. A compromised application should not be a path into unrelated services. Permitted paths should be understandable. Prohibited paths should be enforceable.

Accounts and identity

Accounts, projects, and subscriptions isolate access, policy, and responsibility. They also split the bill. When the boundaries are poor, teams share privileges they do not need, environments depend on each other for no operational reason, and a routine admin action carries too much risk.

I look at how you separate production, development, staging, shared services, security, and infrastructure management, and at how identity actually works: role assumption, service identities, privileged access, secrets, and the paths engineers and automation use to touch the cloud. I look for permissions wider than the job, credentials that are hard to rotate, and admin workflows that hang on one person or a procedure nobody wrote down.

Then I propose a structure that makes ownership and access explicit. A small team does not need an enterprise account tree. I add the boundaries that improve security, accountability, and reliability, and I leave out the ones that only add administration.

How far a failure can spread

Every infrastructure change carries some risk. I want to know how far it travels. A bad deploy should not take down unrelated applications. A compromised credential should not open the whole environment. A failure in one region or availability zone should not produce consequences nobody mapped.

I look at failure domains and dependencies: shared infrastructure, single points of failure, tight coupling, privileged paths, and procedures that can hit several workloads at once. I walk common failures: an unavailable database, a broken deploy, an expired certificate, a compromised service account, a network dependency that fails.

Where it earns its place, I recommend better isolation, redundancy, recovery, or a safer deploy. That can mean separating workloads, narrowing permissions, a controlled rollout, a backup you have restored at least once, or removing a dependency that ties otherwise independent systems together. Multi-region failover is the right answer for some workloads and an expensive hobby for others. I size resilience to the business impact of failure, the cost of prevention, and whether your organization can operate what I propose.

What the bill is telling you

A lot of cloud spend starts as a technical decision. Oversized instances, idle development environments, data transfer, log retention, storage layout, and managed-service pricing can all grow faster than the business.

I read the spend next to the infrastructure that generates it: utilization, billing categories, cost allocation, transfer patterns, storage growth, scaling behavior, and whether spend tracks demand. Some fixes are direct. Resize a resource, shorten retention, delete what was abandoned, schedule non-production workloads. Others are architectural: less cross-region traffic, fewer redundant services, a different deployment model, or a real comparison between a managed service and something you run yourself.

I count the engineering cost of the cheaper option. A managed database can cost more per month than PostgreSQL on a virtual machine and still cost less overall if it cuts maintenance, handles backups, and lowers recovery risk. I judge a saving against reliability, security, engineering time, and what the business needs.

A target your team can run

Once the current environment is clear, I design a target for the risks, constraints, and waste that matter. That can touch account layout, network topology, identity, compute, databases, storage, observability, deployment, and automation.

I favor patterns your engineers already understand, with explicit ownership and clear boundaries. If the team is two people, I will not hand you a design that needs a platform department. If a simpler deployment meets your availability and scale requirements, I will not add an orchestrator because the technology is in fashion. If the business genuinely needs stronger isolation, higher availability, or a more careful deploy, the architecture should account for that before it is an emergency.

I write down the reasoning, including the alternatives and the tradeoffs. The target should have an operational job to do.

A migration that leaves the business running

Cloud work fails when the destination is further than the organization can walk. A network redesign, an account migration, an identity overhaul, and a new deployment platform can each be reasonable. Doing all of them at once is how you manufacture an outage.

I break the move into changes that can be planned, reviewed, implemented, and checked on their own where that is practical. I name the dependencies, say which improvements pay off first, and sequence the work so you are not freezing delivery for months. A step might bring an existing resource under infrastructure as code, move a workload into its own account, narrow network permissions, replace a fragile deploy, or prove a recovery procedure. Each step has an outcome, prerequisites, implementation notes, a way to tell it worked, and a rollback where one exists.

I separate changes you can make during normal operations from the ones that need a window, a coordinated cutover, or extra testing. The plan is sized to the people who will implement it and then live with it.

If it only exists in someone’s head, it is not under control

A maintainable environment needs a way to reproduce configuration, review a change, see a dependency, and recover from a mistake. I look at how infrastructure is provisioned now, including Terraform, OpenTofu, CloudFormation, and the platform-specific tools you already use.

Where it helps, I bring hand-built resources under version control, set consistent module boundaries, improve state handling, and put infrastructure changes through the review and deploy path you already have. Some resources need a careful import. Some procedures should be written down before anyone automates them. I will not rebuild a working system just to say it is in code.

I want a change to be predictable, reviewable, and understandable to the next person. That includes who owns what, how access works, how you recover, and the decisions a future engineer will need. One resignation should not make the environment inoperable.

What I will not recommend

Multi-region deployments, service meshes, Kubernetes, elaborate event-driven systems, and heavy platform automation can all be the right tool. They can also cost a great deal to operate and solve nothing you have.

I will not recommend Kubernetes because the applications happen to run in containers. I will not recommend an account structure so elaborate that the team spends more time managing boundaries than shipping software. I will not recommend replacing a database or a deployment platform that works unless there is a reason you can defend. I will not treat a theoretical scale target as a reason to spend now, when actual usage does not support it.

If a simpler design meets the requirements, I will say so. If what you have is already good enough, I will say that too.

What you leave with

What I hand over depends on the size of the environment. It usually includes:

• A current-state diagram of what is deployed: accounts, regions, connectivity, major workloads, and the dependencies that matter, drawn from the configuration that is running.
• An inventory of the relevant infrastructure, who owns it, which environment it sits in, and what still needs a look.
• A target-state diagram: account structure, network topology, identity boundaries, where workloads live, and the changes that matter.
• A risk and blast-radius assessment: exposures, failure domains, operational dependencies, and weak points, ordered by severity and business impact.
• A cost assessment: spend that is hard to justify, where a saving is real, and what the proposed changes would cost, with the assumptions written down.
• A migration roadmap in small steps: order, dependencies, rough effort, cost, operational risk, and how you will know a step worked.
• An engineering handoff: the decisions, implementation notes, and enough operational context that your team can continue without me.

These are meant to be used. Your team should be able to plan work from them, review an infrastructure change, explain a decision, and keep the environment after I am gone.

Who I do this with

Companies whose cloud grew faster than the documentation and the operating habits. Startups preparing to scale. Businesses sitting on years of accumulated decisions. Teams who inherited an environment they did not design. Organizations heading into a security review, a large integration, a platform migration, a jump in traffic, or a change in who leads engineering.

Sometimes the team is experienced and has not had the time to investigate its own infrastructure. Sometimes a small group is running a cloud that is more complicated than the business requires. Sometimes a business leader wants to know why the bill is rising, why deploys feel risky, or why every incident depends on the same person.

In each case I establish what exists before I recommend a change. I am aiming at an environment your engineers can explain, a bill the business can account for, and an operation that does not depend on someone being heroic: ownership you can point at, costs you can predict, security boundaries that hold, and a known relationship between the systems the business depends on.

Engineers should know where traffic goes, what depends on what, what a deploy can touch, and how to recover. Leadership should know the major costs, which risks are worth spending on, and which investments can wait. I start from the infrastructure you have, and I size the path to the people who will run it.