AWS Cloud

Accounts, networking, compute, and the managed services around them.

What I do

The accounts and the network

I lay out the accounts, the network, and the services the app actually needs.

The move onto AWS

I move what you already run onto AWS, with a plan for the cutover and the first week after.

The paths that are too wide

I close the IAM and network paths that are wider than the job, and line up the evidence an audit will ask for.

What you get

The account you already have

I work in the AWS account you already have: compute, network, and the managed services around them.

The bill

I cut what you're paying for and not using, then check that the app still holds.

Alerts you can act on

I set up the alarms and the runbook so a failure pages someone before it becomes an outage story.

Only what the app needs

I don't add a service because AWS has it. It has to earn a place in the diagram.

How the work goes

What runs, what it costs

I look at the account you have: what runs, what it costs, and what fails.

A diagram you can read

You get a diagram of accounts, network, and the services the app needs.

A plan, then the change

I apply the change in the account, with a plan you can read first.

Alarms and the bill

I leave alarms, a short patch list, and notes on the cost. I don't staff a night desk.

Tools I use

These show up when they fit the job.

Amazon EC2 logoAmazon EC2
Amazon S3 logoAmazon S3
Amazon RDS logoAmazon RDS
Amazon Lambda logoAmazon Lambda
Amazon VPC logoAmazon VPC
Amazon CloudFront logoAmazon CloudFront
AWS IAM logoAWS IAM
Amazon ECS logoAmazon ECS
Amazon EKS logoAmazon EKS
AWS CloudFormation logoAWS CloudFormation
Amazon CloudWatch logoAmazon CloudWatch
Amazon EC2 logoAmazon EC2
Amazon S3 logoAmazon S3
Amazon RDS logoAmazon RDS
Amazon Lambda logoAmazon Lambda
Amazon VPC logoAmazon VPC
Amazon CloudFront logoAmazon CloudFront
AWS IAM logoAWS IAM
Amazon ECS logoAmazon ECS
Amazon EKS logoAmazon EKS
AWS CloudFormation logoAWS CloudFormation
Amazon CloudWatch logoAmazon CloudWatch

Situations I get called in for

Everything lives in one account

Production, staging, and someone's test bucket share one AWS account and one set of keys. I split them into separate accounts under AWS Organizations, so a mistake in staging can't reach production.

The NAT gateway line on the bill

The bill has a large NAT gateway charge and nobody knows why. Often it's private subnets pulling from S3 through the NAT, when a gateway endpoint would carry that traffic at no charge.

A server nobody wants to reboot

The app runs on one EC2 instance that someone set up by hand. Nobody knows how to build it again. I move it to something you can rebuild, like a launch template or a container on ECS.

A database the internet can reach

The RDS instance is marked publicly accessible, or a security group allows 0.0.0.0/0 on the database port. I move it into private subnets and let only the app's security group in.

What I check first

The root user and old keys

Whether the root user has MFA and no access keys. Then which IAM users still hold long-lived keys that should be roles or IAM Identity Center logins.

CloudTrail

That CloudTrail is on in every region and writes to a bucket the app can't delete from. Without it, nobody can say who changed what.

Subnets and route tables

Which subnets route to an internet gateway and what sits in them. I also check that the VPC CIDR leaves room to peer with another network later.

Security groups open to everyone

Rules that allow 0.0.0.0/0 on SSH, RDP, or a database port. Then whether SSH is needed at all, since Session Manager can replace it.

Cost Explorer by usage type

Unattached EBS volumes, old snapshots, idle load balancers, and instances sized for traffic that never came.

If the AWS account is expensive or fragile, start there.

Questions people ask