Cloud Architecture & Microservices on AWS

A startup's cloud should be boring: cheap when idle, fast to change, and recoverable when it breaks. I design and review AWS platforms that meet that bar, and I help teams get there from whatever they have today.

What it covers

  • Architecture reviews with a written recommendation: what to keep, what to change, and in which order.
  • Serverless and container platforms on AWS: Lambda, API Gateway, ECS and Fargate, Aurora, DynamoDB, S3 and CloudFront, EventBridge and SQS.
  • Event-driven microservices where they pay for themselves, and a well-structured monolith where they do not.
  • Infrastructure as code with AWS CDK, environments, CI/CD with GitHub Actions and OIDC, and no long-lived keys.
  • Observability, alarms, and an on-call that a small team can actually carry.
  • Cost control: tagging, budgets, right-sizing, and a monthly bill split by product.

How I work

LX Software's own products run on this stack: static sites behind CloudFront, Python and TypeScript on Lambda, Aurora and DynamoDB, EventBridge schedules, SES mail, and CDK for all of it, with costs split by product tags and reviewed every month. I apply the same patterns to client systems, scaled to the team that will run them.

A review starts with the account, the infrastructure code, the deployment pipeline, and the last few incidents. The output is a short document the team can act on, not a diagram for a wall.

FAQ

Do you only work on AWS?

AWS is where I am deepest and where most of my own systems run. I review other clouds and will say so when another provider is the better fit for a specific workload.

Should an early-stage startup use microservices?

Usually not yet. A modular monolith with clear boundaries and event hooks gets most teams to product-market fit faster. I help decide when, and which, services to split out.