AWS Consulting
Most AWS problems aren't exotic. Accounts grow one urgent decision at a time until nobody can say what's safe to change, what anything costs, or why the bill looks the way it does.
We work inside your AWS accounts to make them understandable, automated, and cheaper to run. Sometimes that means designing something new: a landing zone, a migration, the environment for a product that hasn't shipped yet. More often it means improving what's already there. Untangling IAM. Moving hand-built resources into Terraform. Retiring the alarm that pages at 3 a.m. and has never once meant anything.
Every engagement is scoped around a specific outcome, works through your repos and your accounts, and ends with your team able to operate the result without us.
What a finding looks like
Reviews end in a findings table, not a slide deck. Every line names the resource, the risk, the fix, and the effort: specific enough to hand to an engineer the same afternoon.
Illustrative excerpt: the format, not a client's data.
| Sev | Finding | Action | Effort |
|---|---|---|---|
| S1 | Storage bucket with customer exports readable by any authenticated AWS user | Block public access, scope the bucket policy | hours |
| S2 | Production database: no tested restore in 14 months, snapshots unencrypted | Restore drill, enable encryption on copy | days |
| S3 | NAT gateway carrying traffic a VPC endpoint would carry for a fraction of the cost | Add S3 and ECR endpoints | hours |
Who this is for
- Teams running production on AWS without a dedicated infrastructure or platform team
- Companies whose accounts grew organically and now feel risky to change
- Engineering leaders who want an independent read on cost, security posture, or architecture before a big decision
- Teams planning a move to AWS, or consolidating accounts after an acquisition
- Startups that need production-grade foundations without an infrastructure hire yet
AWS work we take on
Architecture & consulting
Designing around your actual constraints: reliability targets, team size, compliance obligations, budget. That covers multi-account structure with AWS Organizations, VPC and network design, and the unglamorous decisions about where state lives and who can touch what.
Infrastructure setup
New environments built as code from the first resource. Terraform or OpenTofu modules, CI-enforced plans, sensible defaults for logging and encryption, and no console-clicked snowflakes to reverse-engineer later.
Migration
Sometimes lift-and-shift is the right answer; sometimes it just moves the mess. We assess what you're running, sequence the move so revenue-critical systems go last, and plan cutovers with tested rollback. Data migration gets its own plan, because it's always the hard part.
Infrastructure review
A structured read of an existing environment: architecture, IAM, cost, backup reality (not backup theory), and single points of failure. You get written findings ranked by risk, not a hundred-page report nobody opens twice.
Security & Well-Architected review
A review against the Well-Architected pillars without the checkbox theater. In practice this surfaces the same culprits: over-broad IAM roles, security groups open to the world, unencrypted storage, missing audit trails. We fix them in order of blast radius.
Cost optimization
Rightsizing, idle resources, storage classes, and commitment coverage, grounded in what your workloads do.
Also offered as a standalone engagement; see Cloud Cost Optimization.
Infrastructure automation
Replacing console changes with reviewed code. Existing resources get imported into Terraform incrementally, drift gets detected instead of discovered, and infrastructure changes start going through the same review culture as application code.
Performance
Measuring before changing. Most AWS performance problems trace to a database that needs attention, a cache that doesn't exist, or a chatty network path, not to instance types. We profile first, then tune what the profile says.
Monitoring & observability
Dashboards someone reads and alerts tied to symptoms users feel. CloudWatch where it's enough, Grafana and OpenTelemetry where it isn't, and fewer, better pages either way.
The course of an engagement
The full engagement modelScoping call
You describe the problem; we confirm whether we're the right people for it, roughly what it takes, and what it costs.
Read-only review
We start with read-only access and map what actually exists, because the diagram in the wiki rarely matches the account.
The work
Pull requests, pairing sessions, and a short written update every week. Changes land through review, not around it.
Handover
Documentation, runbooks, and a walkthrough with your team. The engagement isn't done until you can operate the result without us.
What we typically work with
When the engagement ends
- Everything lives in your repos and your accounts. There is no dependency on us to keep it running.
- Documentation and runbooks are part of the deliverable, not an add-on.
- Some clients keep a small advisory arrangement afterwards; others email us when something comes up. Both are fine.
Questions we get
- What access do you need to our AWS accounts?
- Read-only, to start. You create a cross-account IAM role in your accounts and we assume it: no long-lived credentials, no IAM users, and you can revoke it whenever you like. If build work follows, changes still land as pull requests in your repos, so console write access is rarely needed at all.
- How long does an AWS engagement take?
- It depends on the scope. Reviews and audits are fixed-scope and usually run a few weeks, ending with a written report and a walkthrough. Build work takes longer and is scoped before we start, with a defined end date. We don't do open-ended retainers; when the work is done, the engagement ends and the documentation stays with you.
- Can you review our environment before a migration or a big launch?
- Yes, and pre-migration or pre-launch is a good time for it. Working from read-only access, we look for what breaks under load or mid-cutover: scaling limits, service quotas, backup and rollback paths. You get a prioritized list of fixes, written so your own team can apply them before the date, plus a walkthrough call to argue about the ordering.
- How is AWS work priced?
- Reviews are fixed-price against a defined scope, so you know the cost before we start; build work is billed at a weekly rate. There is no public rate card, but ask and we quote plainly. The full pricing model is on the How we work page.
Pricing shapes and numbers are on Pricing; NDAs, timezones, and offboarding are on How we work.
Problems this maps to
AWS costs growing without clear visibility
A growing company runs several environments across a handful of AWS accounts. Old instances are still up, several are oversized, storage only accumulates, and the bill has doubled in eighteen months. Finance sees one number; engineering sees none of it. Nobody owns the spend.
Deployments that depend on one person
Releases happen every other week, at night, run by the one engineer who knows the order of operations. The checklist lives in a doc that's almost current. Rollback is untested. Every release carries two weeks of changes, so every release is a big deal.
Field notes on this
Talk to us about your AWS accounts.
A short email about your setup and what's not working is the best start. We'll say plainly whether we can help, and what it would take.
hello@farzanfa.com · +91 88918 87223 · Kerala, India · working worldwide · reply within one business day