When teams evaluate a technology partner for a cloud project, the conversation usually collapses into rates and timelines. Those matter. But they are also the parts of the decision that are easiest to compare, which is exactly why they end up dominating the conversation and crowding out the things that actually determine whether a project survives its second year in production.

Reimagine is an AWS Select Tier Services Partner. On its own, that fact says little to someone deciding who to work with. What does say something is what it changes in practice: who reviews the architecture before it gets built, and what channels exist when something is genuinely broken. And there is one thing it deliberately does not change, which we get to below, because it is the part most often misread: who is responsible for operating the environment once it is running.

Cloud projects rarely fail at the technical level

The failures we see are almost never “the cloud broke.” AWS availability is not usually the problem. The problems are decisions:

  • A database sized for the demo, not for the third month of real traffic.
  • Credentials that were convenient during development and became permanent.
  • No idea what “normal” looks like, so nobody can tell when things stop being normal.
  • An architecture that one person understands, and that person is on vacation.

Every one of those is a decision made early, under time pressure, by someone with incomplete information. They are not caught by better code review. They are caught by having someone experienced look at the design before it hardens — and by the discipline to revisit it.

That is the real value of the partner relationship: it changes who is in the room when those decisions get made.

What the relationship actually provides

A channel into AWS, and someone who already knows the system

When something breaks in production at an inconvenient hour, the difference between a resolution in one hour and one in eight is rarely diagnostic skill. It is access, plus familiarity: whoever picks it up is not meeting your architecture for the first time.

What the partner relationship contributes is the channel into AWS on our side. What it does not contribute is an automatic right for your incident to travel down that channel. Your entitlement to AWS technical support comes from the AWS Support plan on your accounts, or from a partner-led support arrangement where you buy AWS through a partner — not from anyone’s partner tier. Which of those applies to you is a contractual question, covered further down.

Architecture review before you are committed

AWS maintains the Well-Architected Framework, a structured review across reliability, security, cost, performance, operational excellence, and sustainability. It exists precisely because the expensive mistakes are the ones you cannot see from inside your own design.

The valuable part is the timing. A review is cheap before launch and expensive after, when the fix means migrating live data. We run them as part of the design rather than as a reaction to an incident; if you hire a different partner, it is worth asking at what point they run theirs.

People whose certifications are audited, not claimed

Partner tiers require a partner to maintain certified staff and to submit verifiable customer references. That requirement is renewed, not granted once. It is a modest guarantee, but it is a guarantee about something that is otherwise entirely unverifiable from the outside: whether the people assigned to your project have demonstrated competence on the platform they are recommending.

Visibility into what is coming

Service roadmap awareness sounds abstract until it saves you from building something AWS is about to release, or from adopting something that is about to be superseded. Knowing that a managed service is months away can be the difference between maintaining your own component for years and simply waiting.

Where responsibility actually sits

This is the part that gets misread most often, so it is worth being blunt: partner status does not transfer responsibility for your infrastructure to the partner. A tier is a validation of capability. It is not an operating agreement, and it creates no obligation toward you.

Who is responsible for a running environment is set by the contract, and there are three arrangements that get confused with each other:

  • Project work with a handover. We design and build, your team operates. From the handover date, responsibility for the running system is yours. This is a legitimate arrangement and often the right one — but it means the practices further down have to be adopted by your team, not just recommended by ours.
  • Resale or billing only. If a partner resells AWS to you, they become your point of contact for pricing and billing on those accounts. That is a commercial relationship. It does not, on its own, make anyone responsible for administering your workloads or for what happens inside them.
  • A managed services or support agreement. This is the only one of the three where someone other than you is accountable for keeping the environment healthy, and it works because a document defines it: scope, hours, response windows, escalation, and — just as important — what falls outside.

Mixing these up is how a client ends up believing they have coverage they never bought. If nobody signed an agreement to operate the environment, then whoever administers it is responsible for it, and that is usually the client’s own team.

So when you evaluate any partner, including us, the tier is not the question. The question is what the agreement says happens at three in the morning on a Sunday, and who is obligated to answer.

Why accompaniment is the part that compounds

Any competent team can stand up infrastructure. Provisioning is the easy part, and it has been getting easier every year. The hard part is everything after: the migration nobody wants to schedule, the cost that grows quietly, the dependency that stops receiving security updates, the runbook that was never written.

Accompaniment is what covers that period, and it is worth being precise about the word. It does not mean being available, and it does not come from the badge — it comes from an agreement that says who does what, and by when. Where that agreement exists, someone is accountable and nobody has to be convinced that maintenance is worth doing. Where it does not exist, the work still needs an owner, and that owner is whoever holds the credentials.

The practices that make any of this worthwhile

A partner badge changes nothing on its own. These are the practices that separate infrastructure that ages well from infrastructure that becomes a liability. We apply them to our own systems, including this website.

Replace long-lived credentials with short-lived ones. Static access keys are the single most common serious finding in cloud reviews. They get committed to repositories, shared over chat, and outlive the people who created them. For CI/CD, federated identity — OIDC between your pipeline and AWS — removes the stored secret entirely. There is nothing to leak because nothing is stored. We migrated our own deployment pipelines to OIDC for exactly this reason, and the migration surfaced credentials nobody remembered creating.

Grant the narrowest permission that works. Full-access policies are attached because they are fast, and they are never revisited. The correct scope is the one that breaks if you remove anything, and the only way to find it is to look at what was actually called. Broad permissions on a shared identity mean a mistake in one project reaches every other project in the account.

Define infrastructure as code, and be honest about what is not. Configuration that exists only in the console is configuration nobody can review, audit, or restore. If a snapshot of your setup is documentation rather than something that can be applied, label it as documentation — an inert snapshot that quietly drifts from reality is more dangerous than no snapshot, because people trust it.

Instrument before you need it. Logs, metrics, and alerts added during an incident do not help with that incident. The baseline question — what does normal look like on a Tuesday afternoon — has to be answerable before the anomaly, or the anomaly is invisible.

Test the restore, not the backup. A backup you have never restored is a hypothesis. The number worth knowing is not whether backups exist but how long a full recovery takes, measured rather than estimated.

Tag resources so cost has an owner. Untagged spend is unattributable spend, and unattributable spend never gets optimized. It also never gets turned off, which is how accounts accumulate resources nobody can identify.

Design for the failure of one component, not for its absence. Multi-AZ deployment, health checks, and graceful degradation are not premium features. They are what makes the difference between a slow afternoon and an outage.

The honest summary

The partner status is a signal about process and verified competence, not a guarantee of outcome. What determines whether your project works is the same as it has always been: sound architecture, disciplined operations, and people who are still paying attention six months after launch.

What the relationship changes is the depth of expertise behind the decisions and the channel available when something is genuinely broken. What it does not change is who is responsible for your environment. That comes from the agreement you sign, and if no agreement covers operations, it stays with whoever administers the account. Any partner who lets you assume otherwise is selling you a comfort that does not exist.

If you are planning a migration or would like a second opinion on an architecture already in production, let’s talk. You can also read more about how we approach cloud infrastructure.