Cloud.gov: Authority-to-Operate Federal Cloud Platform
There is a particular species of government technology project that begins with an agency engineer staring at a 421-page security control catalog, realizing that perhaps two-thirds of those controls have nothing to do with the application being built and everything to do with the data center it will eventually live in, and concluding, reasonably, that someone else ought to handle the data center. Cloud.gov is the result of that conclusion, formalized. It is a Platform-as-a-Service operated by the General Services Administration's Technology Transformation Services, designed so that federal agencies can deploy web applications without first having to become, accidentally, infrastructure security specialists.
What Cloud.gov Actually Is
Cloud.gov is a hosted application platform — meaning agencies push code, and the platform provides the operating system, runtime, networking, logging, and compliance scaffolding underneath it. The platform itself runs on Amazon Web Services commercial regions, but the agency developer rarely interacts with AWS directly. Instead, they interact with a Cloud Foundry-based interface that abstracts the underlying infrastructure into something closer to a deployment command and a configuration file.
The distinction matters for a reason that is not immediately obvious. When an agency builds directly on raw cloud infrastructure, the agency is responsible for nearly every security control on the federal compliance checklist — patching, network segmentation, audit logging, identity management, encryption at rest, encryption in transit, and a long tail of items with names like SI-4(2) and AC-17(3). When an agency builds on Cloud.gov, the platform handles a substantial portion of those controls on the agency's behalf, and the agency inherits the documentation showing they have been handled.
According to TTS, Cloud.gov holds a FedRAMP Moderate Authorization to Operate, which is the level appropriate for systems handling controlled but non-classified information — most public-facing federal applications and a fair number of internal ones. The platform is operated by Technology Transformation Services within the Federal Acquisition Service of GSA, which is the same organizational neighborhood that produces 18F, Login.gov, and USA.gov. There is a thematic consistency to TTS that becomes visible once you notice it: most of what they build is shared infrastructure that exists so that other agencies do not each have to build their own version, badly.
The Authority-to-Operate Problem
To understand why Cloud.gov exists at all, it helps to understand the Authority-to-Operate, or ATO, which is the federal government's mechanism for deciding whether a piece of software is allowed to run on a federal network with federal data inside it. The ATO is, in form, a signed memo from a senior agency official accepting risk on behalf of the government. In practice, it is the conclusion of a long process involving security plans, control assessments, risk reports, and a great deal of writing about hypothetical adversaries.
The Federal Risk and Authorization Management Program — FedRAMP — was created so that cloud services could be assessed once and reused many times, rather than each agency conducting its own independent review of, say, the same database engine. FedRAMP defines three baselines: Low, Moderate, and High, corresponding roughly to the sensitivity of the information involved. Moderate is the most common, covering systems whose compromise would cause serious but not catastrophic harm.
Cloud.gov, holding a Moderate ATO, allows agencies to inherit the controls the platform itself has documented. TTS describes this inheritance as covering roughly seventy percent of the FedRAMP Moderate control set, leaving the agency to address the remaining controls — generally those specific to the application itself, such as how it authenticates users, what data it stores, and how it handles inputs. The seventy percent figure is approximate and depends on how an agency configures its application, but the order of magnitude is the operative point. An agency starting from a Cloud.gov baseline is starting roughly two-thirds of the way through the compliance work rather than at the beginning of it.
This shortens the ATO timeline meaningfully. ATOs that historically took twelve to eighteen months can, under favorable conditions, complete in a fraction of that time on Cloud.gov, because much of the documentation is pre-written and the security controls are pre-implemented. The agency inherits the platform's authorization package and writes only the portion specific to its own application.
Who Uses It
The visible users of Cloud.gov tend to be public-facing applications where the agency wanted to ship something modest in scale without commissioning a new data center to do it. The FBI's Crime Data Explorer, which presents Uniform Crime Reporting statistics to the public, runs on Cloud.gov. Various components of the U.S. Department of Agriculture host applications there. Smaller agencies and individual program offices within larger agencies make up a substantial portion of the user base, because they are the ones for whom standing up independent infrastructure would be most disproportionate to the size of the application.
There is a pattern here worth observing. Cloud.gov is most useful for projects that are too small to justify an independent compliance program but too sensitive or too official to be hosted on general-purpose commercial infrastructure without one. That middle band — call it the small-but-serious application band — is wider than one might expect. A great deal of federal work consists of websites that present data, forms that collect information, and modest internal tools that coordinate work across offices. None of these individually warrants a dedicated FedRAMP authorization. Collectively, they justify a shared platform.
How the Pricing Works
Cloud.gov operates on what GSA calls cost-recoverable pricing, which is a phrase that means, in essence, that the program is not allowed to make a profit but is also not allowed to lose money. Agencies pay for what they use — measured in application instances, memory allocation, storage, and similar units — and the aggregate revenue is intended to cover the platform's operating costs, including the underlying AWS bills, staff salaries, and the periodic third-party assessments that FedRAMP authorizations require.
This pricing model is consistent with how most TTS services are funded. It is neither subsidized nor commercial; it is a federal cooperative arrangement in which agencies share the cost of running shared infrastructure. The practical implication for an agency considering Cloud.gov is that the cost is generally predictable and competitive with commercial PaaS offerings, with the difference being that the compliance scaffolding is included rather than purchased separately.
Cloud.gov, Cloud.mil, and the Question of Which Cloud
The naming similarity between Cloud.gov and Cloud.mil produces occasional confusion, which is unfortunate because the two are operationally distinct. Cloud.gov is a civilian platform run by GSA for civilian agency use, hosted in commercial AWS regions, and authorized at FedRAMP Moderate. Cloud.mil is a Department of Defense initiative aimed at military use cases, which involve classified information, higher impact levels, and a different authorization regime altogether. They are not interoperable, not interchangeable, and not run by the same people.
A civilian agency building a public-facing web application would use Cloud.gov, or a commercial cloud directly, or another civilian shared service. A defense component handling classified workloads would use Cloud.mil or one of the DoD-specific cloud contracts. The distinction is settled by mission and data sensitivity, not by preference.
The Cloud Foundry Layer
Underneath the agency-facing surface, Cloud.gov runs on Cloud Foundry, an open-source platform-as-a-service framework originally developed at VMware and now maintained by the Cloud Foundry Foundation. The choice is significant because it means the platform's deployment model — git push, essentially — is portable. An application written for Cloud.gov can, with modest effort, be moved to another Cloud Foundry installation, including private commercial ones. This is a deliberate design choice on the part of TTS: the platform is meant to be useful without being a trap, and the open-source foundation is the mechanism that prevents lock-in from becoming permanent.
The agency developer's experience is therefore familiar to anyone who has used Heroku or a similar commercial PaaS. Code is pushed; the platform builds and deploys it; logs are accessible; scaling is a matter of adjusting a number. The federal portions of the experience — the authorization inheritance, the FedRAMP boundary, the audit logging that produces evidence for assessors — happen underneath, mostly invisibly.
Where the Boundary Sits
A subtlety that is occasionally lost in summaries of Cloud.gov: the platform's authorization covers the platform. It does not automatically cover the application running on top of it. An agency deploying to Cloud.gov still must produce a System Security Plan for its own application, address the controls that are not inherited, and obtain its own ATO from its own authorizing official. Cloud.gov accelerates this process; it does not eliminate it.
The controls that remain with the application tend to cluster around identity, data handling, and application logic. If the application authenticates users, the agency must document how. If the application stores personally identifiable information, the agency must describe its handling. If the application accepts uploads or queries, the agency must address input validation and access control at the application layer. These are the things only the application's developers can know, and they are precisely the controls FedRAMP cannot inherit on the agency's behalf.
The Broader TTS Pattern
Cloud.gov sits within a constellation of GSA-operated shared services that follow a similar design philosophy: build the boring, common, compliance-heavy infrastructure once, in a single well-maintained instance, and let agencies focus on the parts of their work that are actually mission-specific. Login.gov handles federal identity for the public. USA.gov handles the front door for federal information. 18F provides digital service consulting. Cloud.gov provides the runtime.
There is an underlying argument embedded in this arrangement, though TTS does not state it in so many words: that a great deal of what each agency was building independently was, in fact, the same thing, and that building it once well is preferable to building it many times poorly. This is, taxonomically, a different argument from the one usually offered for shared services, which tends to emphasize cost. The TTS argument is closer to a quality argument — that compliance and security infrastructure benefit from concentration of expertise, and that asking every agency to maintain its own is asking each of them to do something that almost none of them are properly staffed to do.
Whether this argument is correct is a matter of ongoing observation. Cloud.gov has been operating since 2015 and has accumulated a sufficient number of agency tenants to suggest that the model is at least viable. Whether it scales to handle the larger and more complex agency workloads that currently run on dedicated infrastructure is a different question, and one the platform's roadmap continues to address.