A cloud problem is rarely just the wrong instance size. Risk grows when nobody can show the current architecture, privileged access, recovery evidence, cost ownership or a safe path for change. I review AWS or Azure as the product's operating system—not as a list of services.
Signals the environment needs review
- You are taking a cloud environment over from a vendor or employee and do not know whether every account and secret is controlled.
- Cost grows but cannot be attributed to a product, environment or workload.
- Backups exist but nobody has demonstrated a successful restore.
- Production changes are manual and environments or permissions have drifted.
- Growth, migration or a database change is planned without capacity and rollback evidence.
Tangible outputs
What the cloud review produces
Current architecture map
Environments, networks, instances, serverless components, databases, storage, integrations and critical dependencies.
Access matrix
Accounts, roles, privileged users, service identities, secrets and excessive permissions.
Data and recovery review
Backups, encryption, retention, replication, recovery objectives and evidence of an actual restore.
Operations state
Monitoring, alerts, logs, incident path, deployment, rollback and production ownership.
Cost drivers
Largest cost groups, unused resources, duplicated environments and safe optimization opportunities.
Prioritized plan
Critical risks, quick fixes, architectural work, owners and explicit assumptions for growth or migration.
Working process
Review driven by product risk
- 01
Critical business flows
Identify services, data and availability expectations that directly affect customers, revenue or obligations.
- 02
Configuration and evidence
Inspect actual accounts, permissions, resources, costs, logs and recovery data—not a slide deck alone.
- 03
Failure and growth scenarios
Test assumptions around losing a component, provider, region, key or the ability to deploy.
- 04
Remediation sequence
Close high-impact, easily exploitable gaps before planning longer architectural changes.
Clear responsibility
What I optimize for
AWS and Azure without logo collecting
Services follow workload, team capability and operating cost; multi-cloud is not a goal by itself.
Cost with reliability
The cheapest resource is not an optimization if it increases incident, data-loss or manual-work risk.
Proven recovery
A green backup status is not enough; the team must be able to restore within a business-acceptable period.
Hands-on experience
Production infrastructure—not advisory slides alone
5+ years AWS & AzureBuilding and managing instances, permissions, databases and cloud tooling alongside application architecture and delivery.
View case studyFAQ
Frequently asked questions
Is this an AWS/Azure cost optimization?+
Cost is one part of the review and is evaluated together with capacity, resilience, data risk and operational effort so savings do not reduce reliability.
Can you take over vendor-managed infrastructure?+
Yes. Accounts, domains, access, secrets, data, deployment and third-party dependencies are inventoried before a safe ownership transfer is planned.
Do you review IAM and permissions?+
Yes. Privileged accounts, roles, service identities, inherited permissions, secrets and access lifecycle are reviewed.
Can you implement the remediation?+
Yes. The output separates quick configuration fixes from architectural work that can be delivered incrementally and handed to the team.