Feature Description
blueprints/ contains four families — fedramp-high, il5, stand-alone and third-party-solutions. There is no fedramp-moderate family, and the tree is identical at v2.13.0 and v3.0.0. Meanwhile the platform itself gained FedRAMP Moderate support in v3.0.0: kms_protection_level is now a variable across 0-bootstrap, 1-resman, 2-networking and 3-security, and the networking stage README is now "FedRAMP High / Moderate Network".
So an operator can now stand up a FedRAMP Moderate landing zone and then has no blueprint written for that regime to deploy a workload into it.
Use Case
FedRAMP Moderate is the larger share of federal and state workloads, and the reason to choose it over High is usually cost and operational burden — Moderate permits SOFTWARE protection level where High typically requires HSM, for example. Today that saving stops at the landing-zone boundary: the moment a team deploys Cloud SQL, App Engine, Cloud Run or Gemini Enterprise, the only blueprints available are the FedRAMP High ones, which carry High's controls and costs.
The practical outcomes are all bad: deploy the High blueprint into a Moderate environment and inherit controls (and spend) the regime does not require; hand-roll a Moderate variant and lose the reusability the repository exists to provide; or fall back to High for the whole deployment and lose the reason for choosing Moderate.
Proposed Solution
Either a blueprints/fedramp-moderate/ family, or — probably better given the overlap — a regime input on the existing blueprints so one blueprint can emit the correct posture per regime, in the same spirit as kms_protection_level in the FAST stages. A statement of intent would help on its own: even a README note saying which blueprints are safe to use unmodified under Moderate, and which are not, would unblock planning.
Compliance & Deployment Context
- Target Deployment Type(s):
- Relevant NIST 800-53r5 Controls: SC-12 / SC-13 (key management and protection level are where High and Moderate visibly diverge today); CM-6 for the baseline the blueprints encode.
Reusability Check
Extending the existing blueprints is exactly what is proposed above — a new parallel tree is the alternative, not the preference. On duplication: #102 is open and covers only the gemini-enterprise blueprint; #101, the platform-level request, is closed as completed. Nothing covers the rest of the blueprint library.
Alternatives Considered
Deploying the FedRAMP High blueprints into a Moderate environment — works, but over-controls and over-spends, and misrepresents the deployed posture in an SSP. Forking a blueprint per customer — loses reusability and drifts from upstream fixes. Widening #102 to cover all blueprints — possible, but its title and body are scoped to Gemini Enterprise, so a separate request tracks better.
Additional Context
Verified against the repository tree at v2.13.0 (8f5b67a6) and v3.0.0 (f64ce6cd): the four blueprint families are unchanged between the two tags.
Feature Description
blueprints/contains four families —fedramp-high,il5,stand-aloneandthird-party-solutions. There is nofedramp-moderatefamily, and the tree is identical atv2.13.0andv3.0.0. Meanwhile the platform itself gained FedRAMP Moderate support inv3.0.0:kms_protection_levelis now a variable across0-bootstrap,1-resman,2-networkingand3-security, and the networking stage README is now "FedRAMP High / Moderate Network".So an operator can now stand up a FedRAMP Moderate landing zone and then has no blueprint written for that regime to deploy a workload into it.
Use Case
FedRAMP Moderate is the larger share of federal and state workloads, and the reason to choose it over High is usually cost and operational burden — Moderate permits
SOFTWAREprotection level where High typically requires HSM, for example. Today that saving stops at the landing-zone boundary: the moment a team deploys Cloud SQL, App Engine, Cloud Run or Gemini Enterprise, the only blueprints available are the FedRAMP High ones, which carry High's controls and costs.The practical outcomes are all bad: deploy the High blueprint into a Moderate environment and inherit controls (and spend) the regime does not require; hand-roll a Moderate variant and lose the reusability the repository exists to provide; or fall back to High for the whole deployment and lose the reason for choosing Moderate.
Proposed Solution
Either a
blueprints/fedramp-moderate/family, or — probably better given the overlap — a regime input on the existing blueprints so one blueprint can emit the correct posture per regime, in the same spirit askms_protection_levelin the FAST stages. A statement of intent would help on its own: even a README note saying which blueprints are safe to use unmodified under Moderate, and which are not, would unblock planning.Compliance & Deployment Context
Reusability Check
Extending the existing blueprints is exactly what is proposed above — a new parallel tree is the alternative, not the preference. On duplication: #102 is open and covers only the
gemini-enterpriseblueprint; #101, the platform-level request, is closed as completed. Nothing covers the rest of the blueprint library.Alternatives Considered
Deploying the FedRAMP High blueprints into a Moderate environment — works, but over-controls and over-spends, and misrepresents the deployed posture in an SSP. Forking a blueprint per customer — loses reusability and drifts from upstream fixes. Widening #102 to cover all blueprints — possible, but its title and body are scoped to Gemini Enterprise, so a separate request tracks better.
Additional Context
Verified against the repository tree at
v2.13.0(8f5b67a6) andv3.0.0(f64ce6cd): the four blueprint families are unchanged between the two tags.