Organization and accounts
- Separate accounts or subscriptions for production, staging and shared services
- Organization-level policies that block risky actions
- Billing and tagging rules applied from day one
Cloud Consulting
Cloud consulting services
Your cloud bill, account sprawl or a looming migration needs decisions before more gets built on top. Agnotic Technologies gives you the architecture, landing zone, cost model and migration plan as written outputs your team can act on.
AWS, Azure and Google CloudLanding zone designWell-Architected reviewsCost and FinOps
Trusted by global innovators
What is cloud consulting?
Cloud consulting is advisory and architecture work that decides how your software should run in the cloud before and while it is built: choosing between AWS, Azure and Google Cloud, designing the landing zone, reviewing architecture against the Well-Architected pillars, setting the security baseline and planning migrations and costs. Agnotic Technologies provides it as a services engagement.
It is different from cloud DevOps, which builds and runs the pipelines and infrastructure, and from cloud migration, which moves existing systems. Consulting produces the decisions and designs those teams carry out; the related pages cover both.
You get written outputs you can act on: an architecture decision record, a landing zone design, a cost model and a migration plan, not a slide deck.
What does Agnotic's cloud consulting cover?
Six kinds of work, each with a written output.
Provider selection
A written comparison of AWS, Azure and Google Cloud for your workload, data residency, existing skills and partner credits.
Landing zone design
Accounts or subscriptions, identity, networking, logging and guardrails laid out before the first workload lands.
Well-Architected review
A review of an existing architecture against the six pillars, with a ranked list of changes.
Cost and FinOps
A cost model for the target architecture, tagging and budgets, and the reserved or spot decisions that cut the bill.
Security baseline
Identity, encryption, logging and network controls, mapped to the rules your customers will ask about.
Migration planning
Which systems to rehost, replatform, refactor or retire, in what order, and how to cut over.
Reference design
What does a cloud landing zone include?
The layers we design before any workload is deployed. Each layer is a set of written decisions, infrastructure as code and a named owner.
Identity and access
- Single sign-on for engineers with multi-factor authentication
- Roles with least privilege and no long-lived access keys
- Break-glass access that is logged and reviewed
Network
- Private networks per environment with controlled ingress and egress
- Private connectivity to databases and managed services
- DNS, certificates and a web application firewall
Security baseline and logging
- Central audit logs that workloads cannot edit
- Encryption at rest with customer-managed keys where required
- Vulnerability scanning and configuration checks
Workloads and data
- Compute choice per workload: containers, serverless or managed services
- Managed databases with backups and tested restores
- Environments promoted through the same pipeline
Operations and cost
- Monitoring, alerting and on-call runbooks
- Budgets, alerts and monthly cost reviews
- Infrastructure as code for every layer above
Decision table
Which cloud consulting engagement do you need?
Five fixed-scope engagements. Each one ends with written outputs and a named next step.
| Engagement | You need it when | What you receive | What usually follows |
|---|---|---|---|
| Provider selection | You are starting a new product or renegotiating with a provider | A written comparison and recommendation with cost and residency notes | Landing zone design |
| Landing zone design | Your first workload is about to be deployed, or accounts grew without a plan | Account structure, identity, network and logging design as infrastructure as code | Cloud DevOps to run it |
| Well-Architected review | An existing system has outages, surprise bills or a security questionnaire to answer | A ranked list of findings and changes across the six pillars | A remediation sprint |
| Cost and FinOps review | The bill grew faster than usage | A cost model, tagging rules, budgets and a list of savings with owners | Monthly cost reviews |
| Migration plan | You are leaving a data center or another cloud | An inventory, a strategy per system (the 7 Rs) and a cutover plan | Cloud migration and modernization |
A review often turns into a landing zone redesign when the account structure is the root cause of the findings.
Related services
What happens after the consulting?
Consulting produces the decisions. These services carry them out.
Cloud DevOps services
Pipelines, infrastructure as code, monitoring and on-call for the landing zone we designed.
Cloud migration and modernization
Moving existing systems to the target architecture, one workload at a time.
DevOps services
CI/CD, environments and observability for product teams.
Data engineering services
Warehouses, pipelines and reporting on the cloud data platform.
Failure points
Why do cloud projects overspend or stall?
The patterns we find in most reviews, and the design decision that fixes each.
Challenge
Accounts and permissions grew by hand, so nobody can say who has access to production.
Agnotic approach
A landing zone with single sign-on, least-privilege roles and no long-lived keys, defined as code.
Challenge
The bill grew faster than usage and nobody owns it.
Agnotic approach
Tagging, budgets and a monthly cost review with named owners, plus reserved capacity where usage is steady.
Challenge
A migration started with the hardest system and stalled.
Agnotic approach
An inventory with a strategy per system and a sequence that starts with low-risk workloads.
Challenge
Security questions from a customer could not be answered.
Agnotic approach
A written security baseline mapped to the controls customers ask about, with evidence from logs and configuration.
Challenge
The architecture was lifted from a vendor diagram, not from the workload.
Agnotic approach
A Well-Architected review that starts from your traffic, data and team, and records each decision.
How we work
How does a cloud consulting engagement run?
Four steps from scoping call to handover or build.
1.
Scoping call
We learn the workloads, the team, the current bill and the deadline, and agree which engagement from the table fits.
Scope2.
Discovery
We read the current architecture, accounts, costs and incidents, and interview the engineers who run them.
Discover3.
Design and decisions
We produce the landing zone design, review findings or migration plan as written decisions and infrastructure as code.
Design4.
Handover or build
Your team carries out the plan with our support, or our cloud DevOps and migration teams carry it out with you.
DeliverHealthcare workloads
What changes when the workload holds health data?
For healthcare clients the baseline adds HIPAA engineering decisions. Agnotic claims no certification; these are the controls we design in.
- A business associate agreement with the cloud provider, because a cloud service that maintains ePHI falls inside HIPAA's business associate definition
- Only HIPAA-eligible services from the provider's published list in the account that holds ePHI
- Encryption in transit and at rest with customer-managed keys, and audit logs retained outside the workload accounts
- Network isolation for the ePHI account, with no public database endpoints
- A documented risk analysis and the configuration evidence a health system security review asks for
Scope and cost
What drives cloud consulting cost?
We do not publish prices. These drivers decide the size of an engagement.
Number of workloads
Each system reviewed or migrated adds discovery and design time.
Current state
Accounts built by hand without infrastructure as code take longer to understand and reshape.
Providers
A multi-cloud or hybrid estate needs a design per provider and a shared identity layer.
Compliance
Health, financial or government data adds control mapping and evidence work.
Team involvement
A review for a team that will run the result needs more workshops and documentation than a build we also deliver.
Who we work with
Teams that use cloud consulting
Four situations that bring teams to us.
Startups before the first deployment
A landing zone and cost model before the product has customers.
Engineering leaders with a growing bill
A FinOps review and a Well-Architected review with ranked changes.
Teams leaving a data center
A migration plan with a strategy per system and a cutover sequence.
Healthcare and regulated products
A security baseline that can pass a customer security review.
Frameworks
Frameworks we design against
Each provider's own framework, plus the NIST references that define the terms.
NIST SP 800-145AWS Well-ArchitectedAzure Well-ArchitectedArchitecture FrameworkNIST SP 800-218HIPAA Security Rule
Facts and sources
Facts and sources behind cloud decisions
Definitions and frameworks we design against, each linked to its primary source.
NIST SP 800-145 defines cloud computing through five essential characteristics, three service models and four deployment models.
Source: NIST SP 800-145, The NIST Definition of Cloud ComputingThe AWS Well-Architected Framework is organized into six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.
Source: AWS Well-Architected Framework documentationAWS Prescriptive Guidance names seven migration strategies, the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect.
Source: AWS Prescriptive Guidance, migration strategiesNIST SP 800-218, the Secure Software Development Framework, groups secure development practices into four areas: prepare the organization, protect the software, produce well-secured software and respond to vulnerabilities.
Source: NIST SP 800-218 (SSDF)HIPAA defines a business associate as a vendor that creates, receives, maintains or transmits protected health information for a covered entity, so a cloud service that maintains ePHI falls inside the definition.
Source: 45 CFR 160.103 (eCFR)
Frequently Asked Questions
It depends on the number of workloads and the state of the current accounts. Each engagement in the table above is fixed in scope, and we agree that scope and its schedule on the scoping call.
Usually the one your team already knows, unless data residency, a specific managed service or partner credits point elsewhere. We write the comparison for your workload rather than recommending one provider by default.
No. We work on AWS, Microsoft Azure and Google Cloud. AWS is the most common request, and a Well-Architected review uses the provider's own framework in each case.
Cloud consulting covers the decisions: provider, landing zone, security and cost. Migration consulting is the part that plans a move from a data center or another cloud. We deliver the move itself through the cloud migration and modernization service.
Yes. Discovery starts from your current accounts, infrastructure code, bills and incident history. Most engagements reshape what exists rather than starting again.
Yes. Every engagement in the table is fixed in scope: a provider comparison, a landing zone design, a review or a migration plan, each with written outputs.
Engineers use AI tools to draft infrastructure code, summarize logs and check configurations. Every design decision is reviewed by a named engineer, and every infrastructure change goes through code review and a plan step before it is applied.
If you want that, yes: our cloud DevOps service runs the pipelines, monitoring and on-call. Many clients run it themselves with the documentation and infrastructure code we hand over.