Which clouds do you work on?

Mostly AWS. I use Azure or Google Cloud when the project already lives there, or when one provider is not the whole answer.

How do you handle more traffic?

Auto-scaling and a load balancer where the app needs them, plus caching in front of the database. I don't add a service because it's fashionable.

Can you move an existing setup?

Yes. I write down the downtime, the data check, and how we roll back before anything moves.

How do you handle security in the design?

Encryption, IAM, and a network that isn't one flat open space. I name the control an audit will ask for.

What do you do about the bill?

I cut what you're not using, then look at steady load for a savings plan. Tags so the bill has names on it.

Cloud Architecture

I design the AWS layout: accounts, network, and the services the app actually needs.

Back to Services

What I do

More traffic, same app

I design the layout so more traffic means more capacity, not a rewrite.

The bill

I stop paying for capacity the app isn't using.

Close the wide paths

IAM, network boundaries, and the logs. I close the paths that are wider than the job.

What you get

Mostly AWS

I work mostly on AWS. I use Azure or Google Cloud when the account is already there.

Fit to the repo

The diagram starts from the app, not from a catalog of cloud products.

The paths that are too wide

I name the control that's missing. I don't paper over it.

After it ships

After the change I leave monitoring and a note on what still costs more than it should.

How the work goes

The account and the bill

I start with the accounts and the bill, then the app that has to keep running.

A sketch of the layout

I sketch the accounts, the network, and the services the app actually needs.

Small changes

I apply the layout in small changes, so a bad plan is easy to stop.

The diagram and the alarms

I leave the diagram, the alarms, and a list of what to look at next.

Technologies I Use

These are the tools I use when they fit the job.

AWS

Azure

Google Cloud

Kubernetes

Docker

Terraform

Ansible

Jenkins

AWS

Azure

Google Cloud

Kubernetes

Docker

Terraform

Ansible

Jenkins

Situations I get called in for

Before the first real deploy

The app works on a laptop or a single server, and it's about to go on AWS for real. I draw the layout first, so the first build isn't the one you live with by accident.

A new product or a new region

You're adding a second product, a second region, or a customer with its own data rules. I decide where it lives and how it connects before anyone creates resources.

A setup nobody can draw

The account grew one console click at a time. I map what exists, then design what it should look like and the order of changes to get there.

One piece takes everything down

One instance, one Availability Zone, one NAT gateway. It works until it doesn't. I find the pieces that take the app down with them and decide which are worth paying to double.

What I check first

The account boundaries

How many AWS accounts, and why. A separate production account is a hard line for IAM and for the bill. I sketch the accounts before the network.

Recovery time and data loss

What RTO and RPO you can live with. That answer decides between backups, a warm standby, or a second region. I ask before I draw anything.

Availability Zones

Which pieces run in more than one zone. A load balancer across two zones doesn't help if the database or the only NAT gateway sits in one.

Where state lives

Sessions and uploads belong outside the app servers, in a database, a cache, or S3. Then an instance can be replaced without losing anything.

Limits that show up later

Service quotas like Lambda concurrency, the IP addresses left in each subnet, and rate limits on the APIs the app calls. They are cheap to plan for and painful to hit.