Choosing an AWS Consulting Partner in India: An Evidence Checklist Before You Sign

Compare AWS consulting proposals using verifiable credentials, accountable scope, India billing arrangements, recovery evidence and a reusable scorecard.

If you are comparing AWS consulting companies in India, shortlist the team that can explain your workload, name who will deliver the work, and show how you will accept the result. Check its AWS credentials, but make the award decision from the proposed work and its supporting evidence.

This guide is for an engineering leader buying a migration, cloud remediation or architecture engagement. It provides a way to compare proposals before signing. It does not rank vendors, certify a winner or replace procurement, security and finance review. Ampity sells cloud engineering services, so apply the same questions to us as to every other candidate.

Start with the decision you are buying

“We need AWS expertise” is too broad for comparable proposals. One consultancy may quote an assessment, another a migration, and another ongoing support. Their prices will describe different work.

Write a one-page brief containing the workload, business trigger, current constraint, systems in scope, dependencies, intended result, exclusions and who can accept the work. Add the access you can provide and the decisions your own team must make. If you cannot define the implementation yet, buy a bounded assessment with a specific output rather than asking vendors to guess a fixed migration scope.

For example, an illustrative brief could be: “Move this application and database into our AWS accounts, preserve the agreed business transactions, prove recovery inside our stated objectives, and hand over the deployment and operating procedures.” That is a starting point, not an architecture recommendation. The account inventory, database compatibility, cutover window and recovery tolerances still need investigation.

Send every candidate the same brief. Ask them to identify unanswered questions and show which assumptions affect scope. The quality of those questions tells you more than an unsolicited list of services.

Separate three different kinds of AWS credential

AWS Services Partner tiers, service-specific designations and individual certifications answer different questions.

AWS describes its company tiers in AWS Services Partner Tiers. Use the official AWS Partner Solutions Finder to check the named company's record, then confirm the relevant designation with the vendor if its public listing is incomplete. Record the entity, source and check date. A badge is useful shortlist evidence. It does not identify the people assigned to your project, define their availability or guarantee the result.

There is a time-sensitive detail in the AWS Specializations guidance: AWS says Service Delivery and Service Ready specializations will be deprecated on 1 June 2027 and new applications are closed. Treat an older badge as a claim requiring a date and exact status. Ask the vendor how it describes that capability now; do not relabel a Service Delivery designation as an AWS Competency or invent a successor award.

AWS issues verifiable individual certification digital badges. Ask to meet the proposed lead and discuss a relevant design decision. A company can employ certified engineers without assigning those engineers to your work. Conversely, a technically strong named team still needs credible delivery and ownership evidence.

Check who contracts, who pays AWS and who owns the accounts

For an Indian buyer, separate the consulting contract from the AWS billing relationship. Ask whether you are buying engineering services directly, cloud resale, a managed service or a Marketplace offer. A proposal can combine them, but each needs an understandable charge and responsibility boundary.

AWS says a new account with India contact and billing details has an agreement with AWS India and invoices in rupees. Existing arrangements and changes of seller of record can differ. Check your actual account rather than inferring its billing relationship from the vendor's location. See Setting up your India billing.

Ask finance and the vendor to answer these questions in writing:

• Which legal entity signs the consulting agreement and issues its invoice?
• Which entity is the seller of record for AWS usage, and is the proposal changing that relationship?
• Which charges are professional fees, cloud consumption, support, subscriptions or resale charges?
• What currency, applicable taxes and payment assumptions are in the quote, and who verifies them?
• Who controls the accounts, billing visibility, infrastructure source, backups and exit procedure?

Do not assume that a consultant's Indian address makes every charge an AWS India charge or resolves your tax treatment. Ask your finance adviser to review the actual purchasing arrangement. This checklist makes the arrangement visible; it is not a tax determination.

For a direct engineering engagement, ask for work in accounts you control unless there is a documented reason for another model. If a managed-service arrangement requires provider control of some systems, document what you can export, how service continuity works and what happens on termination before awarding the work.

Apply mandatory gates before comparing scores

Do not let a strong presentation compensate for an unacceptable access model or undefined scope. The diagram shows the proposed procurement sequence: resolve mandatory gaps before comparing evidence quality.

*Buyer decision flow. “Pass” means your responsible reviewers have accepted the evidence for the proposed scope. It does not mean AWS has certified the engagement. The written gates below provide the accessible detail.*

First, verify the contracting identity, relevant credentials and proposed scope. Second, have your security and platform owners accept account control, access and exit arrangements. Third, agree acceptance criteria, recovery responsibilities and who operates the result. A material unresolved item stays on hold. If a candidate refuses a requirement you consider essential, record why it is unsuitable rather than hiding the issue in a low score.

Some gaps can be resolved during discovery. State whether the uncertainty blocks the whole award, only implementation or only a particular change. A small assessment may proceed with read-only access while production access remains unapproved.

Use an evidence scorecard, not a vendor league table

Use the following rubric to make proposal gaps visible. These numbers are a buyer's organizing convention, not an industry benchmark or predicted success rate.

Score each applicable row: 0 means no evidence or a contradicted claim; 1 means a specific answer but supporting evidence is missing; 2 means you checked relevant evidence and recorded its limits. Mark an irrelevant row N/A with a reason. Record the source, date, reviewer and unresolved question next to every score. Do not award points for document volume.

A coverage fraction, earned points divided by twice the number of applicable rows, can help spot missing evidence. It does not decide the award. Never average away a failed mandatory gate. The decision record should explain critical weaknesses and why the selected team fits the workload.

Copy this record for each material proposal claim. A blank observation is still unknown, even if the vendor supplied a document.

Candidate and contracting entity:
Scope and claim being checked:
Evidence source and check date:
Responsible reviewer:
Observed result and limitations:
Score (0 / 1 / 2 / N/A with reason):
Mandatory gate (pass / hold / unsuitable):
Unresolved question, owner and next check:

Consider two illustrative proposals. Vendor A has extensive credentials and polished references but will not identify the cutover owner or provide an access-revocation plan. Vendor B has fewer relevant credentials but proposes a named lead and reviewable access and recovery procedures. Hold A for the missing mandatory evidence. Continue evaluating B if your reviewers accept its gates. That is a defensible action without declaring B universally better.

Ask security questions before production access

Ask the candidate to sketch how its engineers will obtain access, what they can change, who approves elevation and how access ends. AWS recommends temporary credentials, MFA where appropriate and least-privilege permissions in its IAM security best practices.

Turn those principles into an engagement-specific discussion. Request the proposed roles and trust relationships, separate discovery access from deployment access, identify logging and alert ownership, and review third-party or subcontractor access. Ask how a departed engineer's access will be removed and how emergency access will be attributed.

An unexplained request for shared administrator credentials is a reason to pause. A badge or certification does not authorize a vendor to bypass your access controls. Equally, your security team must provide a usable approved path; responsibility for delays should not disappear into an undefined “client dependency.”

Make recovery and cost proposals testable

Specify acceptable downtime and data loss for the business journey. AWS's disaster recovery guidance connects recovery time and recovery point objectives to business needs. Ask how the proposal will demonstrate those objectives under a realistic failure, not merely configure a backup.

For a migration, identify the last reversible step. After new writes reach the destination, switching traffic back may not restore consistent data. Ask who decides to stop, what reconciliation is required and which tests prove the recovery procedure. Your application's behavior determines the answer; a generic migration diagram cannot settle it.

For cost, ask for stated demand, region, storage, data-transfer, support and commitment assumptions. Request a baseline and a comparison under the same workload. Separate recurring consumption from one-time migration costs and temporary parallel environments. Discuss what happens if traffic, retention or recovery requirements change. A savings percentage without a baseline and exclusions is not sufficient evidence.

Decide when local presence matters

An India-based team can offer useful IST collaboration, but a nearby address does not establish available engineers or onsite support. Define what you need: remote architecture sessions, access to a physical dependency, an onsite cutover meeting or staffed operational coverage.

Ask for the named location, available people, travel assumptions and escalation arrangements when onsite work matters. For remote work, agree overlap hours, response expectations, written decisions and coverage during changes. Buying project delivery and buying ongoing incident response are different scopes. Do not infer round-the-clock support from a general consulting offer.

Choose a city only when it changes the working arrangement. The AWS workload's region, dependencies and recovery plan remain separate technical decisions.

Close with a short award record

Write down the selected scope, passed gates, evidence checked, remaining risks, assigned team, acceptance authority and agreed client inputs. If any uncertainty remains, give it an owner and state which activity it blocks. Retain rejected alternatives and the reason for the decision.

Your next step is to send the same one-page brief and scorecard to the shortlisted teams, then hold a working session with their proposed delivery leads. Ask each team to explain one difficult trade-off in your workload. Select the proposal you can understand, verify and govern.

For the broader working session, use the engineering partner evaluation playbook. For workload preparation, use the AWS Well-Architected review checklist. After award, the cloud deployment acceptance pack develops the release evidence introduced here. If you are evaluating Ampity, apply this checklist to our AWS consulting and migration scope and request evidence for the specific engagement.