I design, secure and run production workloads on AWS. Most of the work is one of six things, and most of it starts by reading an account that nobody has looked at closely in a while.
Account and network design, multi-account structure, and the Well-Architected trade-offs behind them — written down, so the reasoning survives the person who made it.
Moving workloads onto AWS, or between accounts and regions, without a weekend of downtime. Usually the hard part is the data and the DNS, not the servers.
Finding the spend that is not buying anything — idle capacity, forgotten environments, storage tiers, egress — and evidencing each saving line by line rather than quoting a percentage.
Least-privilege roles, removing standing admin, closing escalation paths, and making sure the audit trail is on and cannot quietly be turned off.
Monitoring and alerting that pages a human for things that matter and stays quiet otherwise, plus the runbooks that make an incident boring.
Infrastructure as code, deployment pipelines, and the small pieces of glue that remove a recurring manual job from someone's week.
Every engagement starts by looking at what is actually deployed — not at a diagram of what someone believes is deployed. The two are rarely the same.
You get the plan and what it will take before anything is touched, so there is no open-ended meter running.
Changes come with the reasoning written down. If I disappeared, your team should be able to pick up the account and keep going.
Systems engineer since 2007, an MBA, and AWS Certified Solutions Architect. The longer version — the roles, the certifications and how it fits together — is on the about page.
Practical guides and field notes on AWS, cloud teams, and engineering leadership.
If you have an AWS account that needs a look — cost, security, a migration, or just a second opinion on an architecture — a half hour is usually enough to tell whether I can help.