AWS cloud architecture
Infrastructure you understand, with a cost you can explain.
AWS architecture, continuous deployment, observability and security, sized for your team rather than for a reference diagram.
Who this is for
This engagement helps if you are:
- A team whose cloud bill is growing faster than its traffic
- A product moving from improvised hosting to something sustainable
- A team with no dedicated DevOps profile, deploying by hand
- An organisation that has to document its security for a client or an audit
The warning signs
You recognise at least one of these symptoms:
- Nobody can explain precisely what costs money each month
- Staging and production have drifted apart
- A deployment takes a manual step and a bit of luck
- You hear about incidents from users, not from your alerts
- Access rights and secrets have accumulated without review
- An oversized instance has been running for months, just in case
- You do not know what happens if an availability zone goes down
These are symptoms of unscoped infrastructure. They are fixable, and often faster than people expect.
What I actually do
I start from your real bill and your real diagram, not from a reference architecture.
1. Map what exists
- An inventory of the AWS services actually in use
- A diagram of flows, dependencies and failure points
- A read of the bill, line by line
2. Measure before deciding
- Actual sizing against observed load
- Cost per environment and per service
- Gaps between environments
3. Define the target architecture
- Compute choices: ECS and Fargate containers, or serverless where it earns its place
- Data: RDS, PostgreSQL, Redis caching and a backup strategy
- Networking, isolation and secrets management
- Decisions written down and reviewed with the team
4. Industrialise
- A reproducible deployment pipeline
- Infrastructure described in code rather than clicked in the console
- Environments that match and can be recreated
5. Make the system observable
- Logs, metrics and traces that actually help diagnosis
- Alerts on business symptoms, not just CPU
- A cost dashboard tracked over time
What you get
Documents your team can use, and code where code is what is needed.
Everything is versioned in your repository, in French or English.
The infrastructure diagram
- An overview of services and how they talk to each other
- Network flows and entry points
- Expected behaviour when something fails
The cost analysis
- A breakdown by service and by environment
- Costed quick wins
- Expected effect of sizing changes
The security plan
- A review of access and roles
- Secrets management
- Items to fix, ranked by risk
The roadmap
- Work sequenced by dependency and by risk
- Effort estimates per batch
- What we are not doing, and why
The goal stays the same: the team can carry on without me.
How I work
The simplest cloud that works
Sophisticated infrastructure nobody on the team can operate is a risk, not an asset. I size for the people who will live with it.
Measure before optimising
Intuitions about cost are usually wrong. I start from the actual bill and observed metrics; decisions come after that.
Deployment is part of the architecture
An architecture you cannot redeploy cleanly only half exists. Pipeline and infrastructure-as-code are part of the engagement, not a later phase.
- A reproducible deployment with no manual step
- Environments that can be recreated identically
- A rollback path that has actually been tested
Lock-in by choice, not by accident
Using AWS managed services is often the right economic call. What matters is knowing which ones genuinely tie you in, and what leaving would cost.
What changes
By the end of the engagement:
- You know what you are paying for, and why
- Deploying is routine rather than an event
- Incidents are diagnosed with data, not guesses
- The team can evolve the infrastructure without starting over
And you stay in control: none of it depends on my being there.
Frequently asked questions
Should everything move to serverless?
No. Serverless is excellent for intermittent or event-driven workloads, and expensive or constraining elsewhere. The choice is made workload by workload, not as a principle.
Do you work on clouds other than AWS?
AWS is my main ground; it is what I configure and operate day to day. Architecture, deployment and observability principles carry over, but I will be more useful on AWS.
Can you cut our bill without degrading the service?
Often, yes. The most common wins come from oversizing, environments left running, data stored with no lifecycle policy, and unnecessary transfer. None of that is visible to users.
Do you work alongside an existing DevOps team?
Yes, and that is the most effective setup. I bring an outside read and documented decisions; the team keeps ownership of operations.
Do you write infrastructure as code?
Yes, when the engagement covers it. Describing infrastructure in code is what makes environments reproducible and changes reviewable.
How long does a cloud audit take?
One or two days for the diagnosis and the quick wins. Implementation is then planned around your priorities, often in short batches.
Let’s talk about your infrastructure
- A 30-minute call to understand your context.
- Then a written, costed scoping proposal.