AWS Transform enters FedRAMP Class C scope in Ohio

AWS Transform is now in scope for FedRAMP Class C, formerly the Moderate baseline, in the US East (Ohio) Region. AWS says customers can use the agentic migration and modernization service for applications and workloads subject to Class C requirements.

For public-sector teams and contractors, the release can move AWS Transform from “service not in the required boundary” to “candidate for architecture review.” It does not authorize the customer's source systems, connected services, generated code, destination environment, or operating process. This article explains where the new evidence stops and what to examine next.

What exactly entered the certification boundary?

AWS announced the change on August 28. The named scope is specific: AWS Transform, FedRAMP Class C, and US East (Ohio).

AWS's live services-in-scope table lists transform with a check under the Class C East/West column and no check under Class D. AWS defines that check as a service that is FedRAMP certified and included in the current certification boundary.

That is stronger evidence than general product availability. A procurement or security review can now cite the announcement and current scope row instead of inferring status from another AWS service. Preserve the retrieval date with the evidence because assurance pages and service features change.

Do not widen the statement beyond its source. The announcement names Ohio, not every commercial Region, and it does not claim Class D coverage or GovCloud availability for this use. A design that requires another Region still needs evidence for that exact location.

Why doesn't service scope authorize the modernization workload?

AWS's scope page states the shared-responsibility boundary directly. Customers must determine the nature of their data, whether a service processes or stores it, and how the service affects the compliance of the customer environment.

AWS Transform is not a single isolated code conversion. The product page describes a collaborative workbench for infrastructure migration, application modernization, and continuing technical-debt reduction. Named targets include VMware, bare metal, hybrid environments, mainframes, Windows applications, custom code, storage, and AI workloads.

Each use case connects the in-scope service to customer-controlled systems and potentially to other cloud services. Assessment data has to enter. Users and roles operate shared workspaces. Agents analyze assets or code. Generated plans, code, configuration, and documentation leave the workbench. Tests and deployment occur somewhere. Logs and retained artifacts need owners.

The Transform listing establishes a provider service boundary. It does not say every connected source or destination shares that boundary, that every generated artifact is correct, or that an agency authorizing official has accepted the configured system.

Which architecture facts belong beside the scope row?

Start with the exact Transform capability under consideration. A VMware infrastructure migration, mainframe code transformation, Windows modernization, and continuing repository remediation do not have the same inputs, outputs, tools, or acceptance tests.

Then identify where the work actually runs and where each dependency resides. Record the Transform Region, source-system locations, storage paths, identity provider, connected AWS services, external tools, output repositories, build systems, deployment destination, and evidence stores. If one dependency has an unclear status or data path, the Transform scope row cannot fill that gap.

Data classification makes the inventory operational. State what discovery metadata, source code, binaries, configuration, credentials, logs, and generated artifacts may enter each step. “Modernization data” is too broad to support access, retention, or transfer decisions.

Finally, name the customer controls that remain authoritative: identity and least privilege, encryption and key ownership, network paths, logging, retention, change review, test acceptance, deployment approval, incident response, and rollback. These are not features proved by the AWS scope listing; they are conditions the complete workload must satisfy.

What changes for procurement and security review?

The release resolves one threshold question: AWS now places Transform inside the current Class C certification boundary for the announced Region. Teams that had rejected the service solely because that provider evidence was absent can update the product record.

The next review should not ask the same question again in broader words. Instead of “Is AWS Transform FedRAMP?” ask whether the proposed feature and Region match the scope evidence, which other services enter the architecture, what data each one handles, and which customer controls complete the system boundary.

Keep vendor, customer, and authorizing evidence separate. The AWS announcement and scope table support the vendor-status claim. Architecture diagrams, service configurations, access tests, logs, migration test results, and approvals support claims about the customer's implementation. The applicable authorization process determines whether those facts are sufficient for the workload.

This separation also prevents a common procurement overreach: copying a check mark from a provider table into a statement that the full modernization program is compliant. The check mark is valuable precisely because its meaning is bounded.

Which first use case can produce useful evidence?

Choose one nonproduction modernization candidate whose source, expected output, and acceptance tests are already understood. Avoid starting with the largest estate or a workflow that can deploy directly into an official environment.

A suitable first case might assess a bounded application and produce a modernization plan or proposed code change for human review. The team can then inspect the data sent to Transform, identities used, generated artifacts, connected services, Region evidence, logs, test results, and final disposition without letting an agent's output become an approved release by default.

Migration quality needs its own proof. A generated application can compile and still fail deployment or preserve the wrong behavior. Our review of ScarfBench's Java migration evidence explains why compile, deploy, and behavior are separate checks. Those checks evaluate the modernization result; FedRAMP scope answers a different question about the provider boundary.

For a migration that spans many repositories, preserve the distinction between one successful candidate and permission to scale. The multi-repository migration guide covers rollout stops and code-owner routing. Neither a clean pilot nor a certification listing proves that the next application has the same dependencies.

What evidence should remain after the review?

Retain the exact AWS announcement, the current Transform row from the services-in-scope page with retrieval date, the selected feature, and US East (Ohio) as the evaluated Region. Add the architecture's source and destination services, data classes, identities, network paths, storage and retention locations, and customer-control owners.

For the modernization run itself, keep the source baseline, generated artifacts, compile or infrastructure validation, deployment test where applicable, behavioral acceptance results, human reviewer, approved disposition, and rollback path. Mark observed test evidence separately from AWS product descriptions.

A decision to proceed should therefore read narrowly: the service and Region match the required provider scope; the connected architecture has been reviewed; the customer controls are configured; and the modernization output passed the acceptance tests required for that candidate. If any part remains unknown, the correct state is pending evidence—not “covered because AWS Transform is in scope.”

AWS Transform's new status matters because a regulated modernization option has crossed a real eligibility threshold. Use that threshold to begin the right review, not to skip it.

BaristaLabs helps teams connect AI service claims to workload architecture and operating evidence through AI consulting. If AWS Transform is entering a regulated modernization shortlist, bring one candidate to a focused service-scope and architecture review.

Sources

• AWS What's New: AWS Transform now in scope for FedRAMP Class C
• AWS: Services in Scope by Compliance Program—FedRAMP
• AWS Transform product overview