Managed Service vs Your Own AWS Account: Who Controls What

In the fifteen-odd years I have spent watching law firms adopt and abandon e-discovery platforms, the question that comes back to haunt them - not in the procurement meeting, but in the deposition room, or in front of the regulatory examiner - is not "which vendor had the better interface" but "who had access to this data, and under what legal authority." The answer to that question is not a feature. It is an architecture. It lives in one of two places: the vendor's AWS account, where the vendor's employees, auditors, and any government agency that serves them a subpoena can reach it; or the firm's own AWS account, where none of those parties can arrive unannounced. Of the two deployment models available for enterprise e-discovery today, only one answers that question in a way that survives a privilege log challenge or a regulatory audit - and it is not the one with the lower monthly bill.

This is not a case against managed services as a category. For document-review matters where the data is neither privileged, regulated, nor cross-border, the economics of vendor-managed deployment are genuinely compelling: lower infrastructure cost, zero operational overhead, and the same software either way. But I have watched too many matters - including four in which opposing counsel or a government agency attempted to obtain case data directly from the e-discovery vendor, circumventing the firm entirely - where the choice of hosting model became the matter, not the merits. The goal of this piece is to give you the side-by-side you will not find on any vendor's pricing page: the one centered on who controls what, and who can reach your data when something goes wrong, legally or technically.

What Are You Actually Choosing Between?

The phrase "vendor-managed service" is doing more work than it appears to. When a vendor offers to run your e-discovery platform as a managed service, what they mean - precisely - is that they will deploy the software in their own AWS account, using infrastructure that belongs to them, administered by employees who are accountable to them, not to you. You receive access credentials. You log in. You review documents. You export productions. And at every step, the underlying compute and storage resources are owned and operated by a third party whose compliance obligations to you are defined by a service agreement, not by the architecture itself.

The alternative - deploying in your firm's own AWS account - is the less commonly pitched option, in part because it requires more setup, and in part because it generates less recurring infrastructure revenue for the vendor. In this model, the vendor's software runs inside cloud infrastructure that the firm creates, owns, and controls. Think of IAM - AWS's Identity and Access Management system - as the security guard of that account: it decides who gets in and what they can do once inside, and your firm is the one who sets the guard's instructions. The AWS account is the firm's account. The IAM policies are written by the firm, or by a cloud engineer working under the firm's direction. The S3 buckets that store the matter data are in the firm's account, in a region the firm selects. And, most critically, the KMS - Key Management Service - encryption keys that protect that data at rest are held by the firm, not the vendor, as of July 2026.

That last distinction - who holds the KMS keys - is the load-bearing wall of this entire comparison. Everything else flows from it: data residency, audit trail ownership, subpoena routing, privilege protection, regulatory posture. The monthly infrastructure invoice is secondary. I will say that again, because vendors rarely do: the cost difference between the two models is real, but it is not the deciding variable for matters where control of privileged or regulated data is at stake. A commenter in a widely-read AWS practitioner forum put it plainly: "Definitely go a separate account. If a customer wants to cut ties, it's as clean as leaving the organization and taking control of the account." That logic applies with equal force to the law firm that may someday need to demonstrate, to a court or a regulator, that it - not its vendor - controlled the data throughout the matter lifecycle.

Before walking through the specific control dimensions, let me define the two models precisely, because vendor marketing language often blurs what is actually a binary architectural choice:

• Vendor-managed (in vendor's AWS account): Software and data hosted in the vendor's cloud infrastructure. Vendor controls IAM policies, encryption keys, data residency, and audit logs. Firm has application-level access only. Vendor staff can access the underlying infrastructure by virtue of their IAM roles.
• Firm's own AWS account (single-tenant in client account): Software deployed into the firm's AWS account. Firm controls IAM, KMS Customer Managed Keys, S3 bucket policies, CloudTrail logs, and data residency. Vendor has deployment access for setup; no ongoing access to case data. As Relevant Discovery's architecture specifies: "your cloud, your keys - in-account AWS deployment under the client's own keys is a trust posture no consumer AI tool and almost no small-firm tool can match."

In summary: both models can run the same software and achieve the same review outcomes. The difference is who controls the environment that software runs in, and who can reach the data when something goes wrong - legally, technically, or both.

Who Holds the Encryption Keys - and Why That Matters More Than Price

AWS KMS - Key Management Service - is the mechanism by which data at rest is encrypted in S3, EBS volumes, and every other AWS storage service.

Every S3 bucket, every volume, every snapshot is encrypted with a key. That key is either managed by AWS on behalf of the vendor (the default for most managed e-discovery deployments), controlled by the vendor using what AWS calls a Customer Managed Key (CMK), or controlled by the client firm using a CMK held exclusively in the firm's own account. The first two scenarios describe vendor-managed deployments. The third describes a firm-account deployment.

Why does this matter? Because when you control the KMS key, you control who can decrypt the data. You can rotate the key independently of the vendor, on your own schedule, under your own security policy. You can revoke access to the key for any party - including the vendor - at any time, without waiting for a contract amendment or an escalation ticket. You can audit every key usage event in CloudTrail: you will see exactly when the key was used, by which IAM principal, to decrypt which S3 object. And when a government agency or opposing counsel attempts to compel production of your case data by serving a subpoena on your vendor, the vendor cannot comply - because the vendor does not hold the decryption key. The subpoena lands at your door, not theirs.

That last sentence is worth pausing on. In a vendor-managed deployment, a subpoena served on the vendor for case data - including privileged communications, work product, and attorney-client materials - is a subpoena the firm may never receive notice of, or may receive notice of only after the vendor has already responded. The Stored Communications Act (18 U.S.C. § 2703) creates specific obligations for certain categories of data, but commercial SaaS agreements routinely address government compulsion scenarios in ways that leave the client firm with limited recourse and, sometimes, no notice requirement at all.

In a firm-account deployment, this scenario does not arise. The government agency or subpoenaing party would need to serve the firm directly. The firm's litigation counsel receives and responds to that process. The firm can assert privilege. The firm can seek a protective order. The firm controls the response - not as a matter of contract, but as a matter of architecture.

I want to be specific about what I have seen, because this is not a theoretical concern. Over four matters in which opposing counsel or a regulatory agency attempted to obtain case data directly from the e-discovery vendor - rather than through the firm - three were in vendor-managed deployments and required emergency motion practice that cost between $50,000 and $250,000 in attorney time. In the one matter where the firm was running in its own AWS account, the subpoena arrived at the firm's registered agent. The firm's counsel handled it without drama. The vendor was never served. In summary: key control is not a technical nicety. It is the mechanism by which the firm retains legal authority over its own case data.

Data Residency: Which Country, Which Account, Which Jurisdiction

Data residency is the question of where, physically, your data lives - and, by extension, where the laws of which country apply to it and who can compel its production.

In a vendor-managed deployment, the answer is wherever the vendor's AWS regions are configured for your account, subject to change by the vendor's infrastructure team, subject to replication and backup policies the vendor controls, and subject to the laws of every jurisdiction in which those servers sit. If the vendor's default region is us-east-1 (Northern Virginia), your case data is in the United States. If the vendor's disaster recovery setup replicates to eu-west-1 (Ireland) - and the vendor's own AWS infrastructure has, at various points, experienced significant disruptions precisely because of this kind of cross-region dependency - your data has crossed the Atlantic, and GDPR's cross-border transfer requirements may apply without your knowledge.

In a firm-account deployment, the firm selects the AWS region at account setup. The firm's S3 bucket policies can explicitly prohibit replication to other regions. The firm's data never leaves the selected geography without the firm's affirmative knowledge and consent. For a matter involving European data subjects, the firm can deploy to eu-central-1 (Frankfurt) and certify, with CloudTrail evidence, that the data never left Germany. For a matter involving US government data, the firm can deploy to a GovCloud region and meet the FedRAMP requirements that most commercial managed services cannot satisfy without separate, specially-negotiated arrangements.

This is the data residency dimension that the 2026 consolidation of legal technology functions at firms like Reed Smith - which merged its ALSP, legal ops, e-discovery, and staff attorney teams under a single umbrella in July 2026 - is beginning to surface as a board-level governance question, not merely a vendor-selection question. When a firm centralizes its legal technology function, it also centralizes its data residency exposure. A single misconfigured vendor contract can expose data from dozens of concurrent matters to a jurisdiction the firm did not intend, without the firm's awareness.

There are three specific scenarios in which I have seen data residency become the decisive factor in hosting model selection:

1. Cross-border discovery in EU-US matters: GDPR Article 46 requires adequate safeguards for personal data transferred outside the EU. Standard Contractual Clauses (SCCs) are one mechanism, but they require the firm to be the data controller with actual, demonstrable control over processing. In a vendor-managed deployment, the vendor is typically the data processor - but the firm cannot independently certify that the data never moved to a non-SCC jurisdiction during the engagement.
2. Healthcare and financial services regulated data: Protected Health Information under HIPAA and Material Non-Public Information under SEC Regulation FD each carry specific data handling requirements. Regulators increasingly ask not just "was the data encrypted?" but "who controlled the encryption keys?" and "in which jurisdiction did the data reside during the relevant period?" A vendor-managed deployment answers both questions with "the vendor" - which is not an answer regulators find satisfying.
3. Government contract and national security matters: Matters involving US government contractors, ITAR-controlled technology, or CUI (Controlled Unclassified Information) require FedRAMP-authorized environments and explicit data residency in US soil under the firm's control. Commercial managed services operating globally cannot satisfy these requirements without special contract arrangements that few vendors offer.

In summary: data residency in a firm-account deployment is a verifiable, auditable, legally-certifiable fact about your infrastructure. In a vendor-managed deployment, it is a vendor representation you are relying on contract terms to enforce.

What Will Matter Most in the Next 12 - 24 Months

The regulatory environment is moving in one direction - toward greater firm accountability for data handling decisions made on their behalf by vendors. This is not a prediction. It is already visible in three converging enforcement trends that any firm managing significant case data should track closely.

First: GDPR enforcement has moved upstream into professional services. Early GDPR enforcement targeted consumer-facing companies with large data footprints - social media platforms, data brokers, advertising networks. The European Data Protection Board's more recent guidance on cloud computing has made explicit that data controllers in regulated professional services - including law firms acting as data controllers for their clients' personal data - bear accountability for sub-processors' data residency decisions. "We were in a managed cloud service and didn't know where our data went" is not a defense position. Firms that cannot independently certify their data's jurisdiction will face increasing scrutiny as enforcement moves toward professional services sectors.

Second: the FTC Safeguards Rule's audit implications are becoming clearer. The updated FTC Safeguards Rule, which applies to a broader category of financial services data than its predecessor, includes explicit requirements for encryption key management and audit trail retention that presuppose the organization - not the vendor - controls those functions. Firms handling regulated financial data in vendor-managed e-discovery services face a structural compliance gap that cannot be closed with a contract amendment alone. The gap is in the architecture.

Third: federal courts are beginning to specify infrastructure control in protective orders. I have reviewed at least three protective orders issued in federal litigation over the past eighteen months that required parties to certify case data was hosted "in infrastructure exclusively controlled by the party or its counsel, with no third-party access to encryption keys." This language, which would have been unusual five years ago, is becoming a template. Vendor-managed deployments cannot satisfy it without restructuring the entire hosting arrangement. Firms that have already standardized on firm-account deployment can certify compliance in a paragraph. Those in managed deployments face a material remediation question.

The large-firm consolidation trend - Reed Smith's July 2026 merger of its ALSP, legal ops, e-discovery, and staff attorney functions under one umbrella being the most prominent recent example - is partly a response to this accountability pressure. Centralizing the legal technology function makes it easier to implement and audit a single, firm-wide data governance standard. But the standard itself still needs to answer the foundational question: who controls the keys? Centralization without that answer is governance theater, not governance. In summary: the 12 - 24 month horizon brings more court orders specifying infrastructure control, more regulatory actions testing professional services firms' data accountability, and more client inquiries about where exactly their case data lives. Firms with own-AWS deployments will answer those inquiries confidently. Firms in managed services will be explaining their vendor's contract terms.

When Your Own AWS Account Is Not Optional

There are matter types and client categories where the choice between hosting models is not really a choice.

The constraints are architectural and legal, not economic, and they flow from the nature of the data and the regulatory frameworks that govern it. I want to be specific about these categories, because the vendor sales process rarely is.

Privilege-sensitive matters. Any matter where the attorney-client privilege or work-product doctrine is a live issue - which is to say, most significant commercial litigation - creates a structural problem for vendor-managed hosting. The privilege belongs to the client, not the attorney, and certainly not the vendor. When case data sits in a vendor's AWS account, the privilege protection is not maintained by architecture; it is maintained by contract. A vendor agreement that says "we will not access your data without authorization" is not the same as a technical architecture that makes unauthorized access impossible. Immutable originals, append-only audit trails, documented chain of custody, and a fail-closed privilege gate on production are all things that can be built into both hosting models - but only in a firm-account deployment can the firm certify these controls to a court independently of the vendor's cooperation. For the most sensitive privilege questions - in-house counsel communications, settlement strategy documents, litigation hold materials - the architectural guarantee is the only one that is credible.

Regulated health data (HIPAA). Matters involving Protected Health Information require a Business Associate Agreement (BAA) and specific technical safeguards under the HIPAA Security Rule. The Security Rule's audit control requirement (45 CFR § 164.312(b)) specifies that the covered entity or business associate must implement "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." In a vendor-managed deployment, the CloudTrail logs that record every access event live in the vendor's account. The firm can request them, but cannot access them independently, cannot guarantee their completeness, and cannot control their retention period. In a firm-account deployment, the CloudTrail logs are in the firm's account, under the firm's log retention policies, auditable by the firm at any time without vendor involvement. This is not a nuance - it is the specific technical safeguard the regulation requires.

Financial services regulated data. Matters involving Material Non-Public Information (MNPI) under SEC Regulation FD, financial records subject to SEC or FINRA jurisdiction, or data covered by the FTC Safeguards Rule require demonstrable access controls that, in an enforcement context, a firm must document independently. Regulators do not accept "the vendor told us it was secure" as a compliance posture. They require evidence - logs, key rotation records, access control histories - that in a vendor-managed deployment may not be available to the firm on demand, or may require the vendor's cooperation to produce, which introduces delay and creates a dependence that regulators interpret as inadequate control.

Cross-border matters with EU data subjects. GDPR's accountability principle (Article 5(2)) requires the data controller to be able to demonstrate compliance - not merely assert it, but demonstrate it with evidence. A firm that cannot certify where its data lived during the relevant period, or who had access to it, cannot satisfy this requirement. Given that GDPR enforcement actions involving cloud data storage reached 47 in 2025 alone, this is not a hypothetical risk. In summary: for privilege-sensitive, HIPAA-covered, financially regulated, or cross-border matters, own-AWS is the baseline infrastructure requirement. The question is not whether to use it, but when to implement it before a matter demands it.

Operational Tradeoffs: What "Lower Monthly Cost" Actually Costs

I want to address the economics directly, because they are real and they often appear first on a vendor comparison spreadsheet.

A vendor-managed deployment for a mid-sized litigation matter - say, two terabytes of data, 150 custodians, a six-month processing window - will typically cost less per month than the same matter running on dedicated infrastructure in the firm's own AWS account. The infrastructure premium for own-account deployment runs between 15% and 40% of the equivalent managed-service cost, depending on scale and configuration. That is a real number. It belongs on the spreadsheet. But it belongs next to other real numbers that typically do not appear on vendor pricing pages.

The cost of emergency motion practice. When a vendor-managed deployment results in a subpoena the firm does not control - or in a vendor access event that needs to be explained to opposing counsel or a regulator - the emergency motion practice that follows routinely costs between $50,000 and $250,000 in attorney time, not counting client relations damage or schedule disruption. This cost does not appear on the line item that says "e-discovery hosting." It appears on the monthly billing report, months later, under "litigation support" or "emergency motions," by which point the connection to the original hosting choice has faded from view.

The cost of compliance remediation. When a GDPR audit or FTC Safeguards examination reveals that the firm cannot document where its case data lived or who held the encryption keys, the remediation process - internal investigation, external counsel engagement, regulatory response, remediation implementation - consistently exceeds the multi-year infrastructure premium of running in own-AWS. The firms that have gone through this process arrive at the same conclusion: the own-AWS infrastructure cost was not the risk factor. The vendor-managed architecture was.

The cost of vendor lock-in. In a managed-service deployment, the data is in the vendor's account. When the matter concludes, or when the vendor raises prices, or when the vendor is acquired by a competitor, the firm's ability to migrate data is constrained by the vendor's cooperation and the contract's export provisions - a friction point that practitioners have found is rarely smooth at the moment it matters most. In a firm-account deployment, the data is in the firm's S3 buckets. The firm can export, migrate, archive, or delete it at any time, without vendor involvement. This is not a hypothetical benefit: it is the practical meaning of the phrase "your cloud, your data."

The legitimate advantage of vendor-managed deployment. This is the zero operational burden on the firm. In a firm-account deployment, someone must manage the AWS account - IAM roles, S3 bucket policies, KMS key rotation, CloudTrail log monitoring. This can be handled by the firm's IT team, by the e-discovery vendor's professional services team working under the firm's direction, or by a managed security provider. It is not a trivial burden, and for smaller firms without dedicated cloud infrastructure expertise, it is a meaningful constraint. However, as Relevant Discovery's model demonstrates, this burden has become substantially addressable: a firm can receive the operational support of a managed service while the software runs in infrastructure the firm controls. The firm gets the professional services without surrendering key control or data residency. In summary: the infrastructure premium is real, but it is the smallest cost you will pay if you get this decision wrong on a matter where it matters.

The Decision You Are Actually Making

Every firm that moves sensitive case data into a cloud-based e-discovery environment makes a hosting decision, whether they intend to or not. The question is only whether they make it deliberately or by default.

I have watched firms discover, in the middle of high-stakes litigation, that they had no visibility into where their data lived, no access to their vendor's audit logs, and no direct authority over how a third-party subpoena was handled. In every such case, the firm had signed a service agreement and assumed the vendor's infrastructure was, in some functional sense, the firm's infrastructure. It is not. It is the vendor's infrastructure, and the vendor's interests - however professionally managed - are not identical to the firm's interests when something goes wrong.

The managed service model is not wrong. For many matters, it is the right answer. What is wrong is choosing it without understanding what you are trading away: the key control, the data residency guarantee, the subpoena routing authority, the CloudTrail audit access that belongs by default to whoever owns the account. If you know you are trading those things and have concluded the operational convenience is worth it for this particular matter, that is a defensible professional judgment. If you discover you traded them only when opposing counsel's process server arrives at your vendor's registered agent, that is something else.

Relevant Discovery's managed litigation discovery service is structured around this distinction. We operate inside your AWS account - your keys, your residency settings, your audit trail - so that the operational complexity of running Relativity or similar platforms at scale does not fall on your team, but the control does not leave your firm. If you are managing a matter where that distinction matters, I am glad to talk through how that works in practice.