AWSArmenia has become a serious place to source cloud engineering: strong engineers, a time zone that works with both Europe and the US East Coast, and a growing number of companies offering AWS services. That also means more choice, and more claims to check.
This is the checklist we would use if we were on the other side of the table. We are an AWS Select Tier Services partner ourselves, and we think every point here is fair to ask of us too.
1. Verify the partnership on AWS, not on the website
Anyone can put a badge on a website. AWS keeps the authoritative list in the AWS Partner Solutions Finder, where you can search for a company and see its tier and validated offerings.
- Registered means a company has joined the partner network.
- Select, Advanced and Premier tiers in the services path require AWS to validate customer engagements, certified staff and other criteria. The higher the tier, the more AWS has checked.
If a company's claimed tier does not match the Partner Solutions Finder, that tells you something before the first call.
2. Ask where the code will live
The answer should be: in your repositories, from the first day. Infrastructure as code, pipelines, runbooks and documentation belong to you. If the work lives in the consultancy's own accounts or tools, you are buying a dependency, not a platform.
3. Ask how they will access your accounts
Good answers sound like this:
- Access through your single sign-on, with roles scoped to the work.
- Short-lived credentials, no shared users, no long-lived access keys.
- Everything they do is visible in your audit logs.
- Access is removed the day the engagement ends.
If the first request is for a root password or an administrator key sent by email, stop there.
4. Ask for evidence, not adjectives
"Scalable", "secure" and "cost-effective" describe every proposal. Ask instead for:
- Case studies with real architectures: which services, which constraints, which trade-offs, and what they would do differently.
- Numbers, with an honest note on how they were measured.
- Certifications you can verify, since AWS certifications come with digital badges that can be checked online.
- A conversation with an engineer who will actually do the work, not only with sales.
5. Ask what happens when the project ends
The best outcome of a consulting project is a team that can run what was built without the consultant. Ask what the handover contains, such as documentation, runbooks and training sessions, and whether ongoing support is optional or assumed.
6. Match the engagement model to the problem
- Team extension: engineers who join your team monthly. Good for a backlog, a hiring gap, or a single person holding all the knowledge.
- Project delivery: fixed scope and milestones. Good for a migration, a platform build or an audit deadline.
- Managed operations: a retainer for someone to own production. Good when nobody does today.
- Assessment: a short review before you commit budget. Good when you need a second opinion.
A partner that proposes the same model for every problem is optimising for its own business, not yours.
7. Check the working hours
Armenia is on UTC+4 all year. That overlaps most of the European working day and the US East Coast morning. Agree in writing which hours are covered, how incidents outside them are handled, and what that costs.
8. Put the boring parts in the contract
- Who owns the code and documentation (you).
- How access is granted and removed.
- A non-disclosure agreement, signed before the first technical conversation if you prefer.
- How either side can end the engagement, and what is handed over when it ends.
The short version
Verify the partner tier on AWS, keep the code in your repositories, insist on least-privilege access, ask for architectures and numbers rather than adjectives, and plan the handover from the first week. A good partner will be glad you asked.
If you are comparing partners, here is how BrainScale works as an AWS partner in Armenia.