Cloud architecture that fits the workload, not the reference diagram
Cloud architecture is the structural design of your cloud environment — accounts, networks, identity, data flows, and the services that run inside them. Done well, it removes a whole category of problems: surprise bills, tangled permissions, environments nobody can reproduce, and outages that trace back to a design decision made in a hurry.
Willowark designs cloud environments the way we design any engineered system: start from the workload and its failure modes, then choose the simplest structure that meets them. We work across AWS, Azure, and GCP, and we put every decision — network topology, account boundaries, encryption, backup policy — into a written design you can challenge before anything is built.
Cloud & InfrastructureHow the work gets done
The same way every time: scope, build, hand over.
The actual work involves account and subscription strategy, VPC and subnet layout, IAM roles scoped to least privilege, choices between managed services and self-hosted components, and data architecture — where state lives, how it replicates, and what the recovery point actually is. We model costs before deployment, tag resources so spend maps to teams and products, and define the network paths between environments so staging can never quietly talk to production.
In production, good architecture is mostly invisible: deployments land in minutes, an engineer can trace any resource to the code that created it, and the monthly bill has no mysteries. We measure success in concrete terms — recovery time objectives met in a real failover test, audit questions answered from documentation instead of archaeology, and new environments stood up from code in an afternoon.
Scoping usually starts with a short discovery: we read whatever exists — diagrams, Terraform, the console itself — and interview the people who deploy and pay for it. From that we write a design brief listing the workloads, their data sensitivity, the recovery objectives that actually matter, and the constraints nobody wrote down, like a vendor VPN or a data-residency rule. The trade-offs get argued in that document: multi-account isolation versus operational simplicity, managed services versus portability, a single region with tested backups versus active-active across two. We recommend one option and show the cost and complexity of the alternatives, so the decision is yours and informed.
What typically goes wrong is not the initial design but its erosion: a permission widened to unblock a deploy, a database created outside the tagged account, a peering connection added for one integration and never removed. We design against that by making the paved road easier than the shortcut — environments created from code, service control policies that block the risky actions outright, and budgets that alert per account. At handover you get the design document, the code that implements it, and a working session with your engineers on how to extend it. We are available afterwards for reviews, but the architecture should not need us to keep standing.
Scope it in writing
What we agree before work starts
- Written architecture design covering network, identity, data, and failure modes
- Account and environment structure with least-privilege IAM
Build with checkpoints
Working results, not slide decks
- Cost model and tagging strategy tied to teams and products
- Security baseline: encryption, logging, backup, and retention policy
Hand over something you own
Documentation, source, and training
- Reference implementation deployed and handed over as code
- Architecture decision records explaining each major choice and the alternatives considered
Sound familiar?
Where cloud architecture earns its keep.
A SaaS product that grew one console click at a time, where nobody can say what talks to what
A manufacturer moving quality data to the cloud and needing a clean boundary between plant and enterprise networks
A startup that needs an environment good enough to pass its first SOC 2 audit without a rebuild
A monthly cloud bill that doubled and cannot be traced to any specific workload
Ask about Cloud Architecture
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
AI operating software for training operations
Components:
- Schedulers (training ops): The people running the training operation.
- Operating software (AI assistance): The operating software, with AI assistance built in.
- Cloud services (distributed): Distributed cloud services behind the application.
- Training game (learning): The training game the software connects to.
Connections:
- Schedulers to Operating software
- Operating software to Cloud services
- Operating software to Training game
A global automotive manufacturer's training operation · Automotive
AI operating software for training operations
AI operating software for the manufacturer's training schedulers — removing manual scheduling labor and logistics tracking, saving hundreds of hours per year — plus a training video game built to help trainers perform better. Used across the manufacturer's training organization.
Read the case study →Common questions
Asked before every cloud architecture project.
Do you work with AWS, Azure, or GCP?
All three. We pick based on your existing footprint, your team's experience, and the specific managed services your workload needs — not a default preference. If you already have a commitment or credits with one provider, we design around that.
Can you review an architecture we already have?
Yes. An architecture review is often the fastest way to start: we map what exists, flag the risks that matter — single points of failure, over-broad IAM, unbounded costs — and give you a prioritized list of changes. Some findings are afternoon fixes; others become a roadmap.
How do you keep cloud costs under control?
Cost is a design input, not a cleanup task. We size resources from measured load rather than guesswork, use reserved capacity or savings plans where usage is predictable, and set up budgets and anomaly alerts so drift shows up in days, not at invoice time.
How long does a cloud architecture engagement take?
It depends on the scope. A review of an existing environment with a written findings report is usually a matter of a couple of weeks. Designing and standing up a new multi-account environment from scratch typically runs several weeks to a few months, depending on how many workloads it must accommodate and how much existing infrastructure has to be brought into line. We scope it in phases so you see a written design before committing to the build.
Will you lock us into a single cloud provider?
Not deliberately, but we are honest that portability has a price. Managed services like RDS or Cloud SQL are usually the right call for a small team even though they tie you to one provider; abstracting everything behind Kubernetes and open-source components keeps options open but costs operational effort. We document where each design is provider-specific, keep the application layer portable where that is cheap, and let you decide how much lock-in is acceptable.
Where this sits
Cloud Architecture, inside a cloud & infrastructure system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Plant systems reach the cloud over an encrypted tunnel; services run in containers over managed data stores, and monitoring alerts a person before a customer notices.
Components:
- Plant network: OT network, segmented from IT.
- Tunnel (VPN / private link): Encrypted, allow-listed, no inbound ports on the plant side.
- Services (containers): Deployed from CI, rolled back in one command.
- Data stores (DB, objects): Managed database and object storage with backups tested, not assumed.
- Monitoring (logs, metrics): Health, latency, error rate, cost.
- On-call: Someone is paged before a customer emails.
Connections:
- Plant network to Tunnel over VPN
- Tunnel to Services over MQTT
- Services to Data stores over SQL
- Services to Monitoring over events
- Monitoring to On-call over push
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.