[Documentation] FedRAMP Moderate networking: record whether a Moderate-specific network pattern was superseded, which regions it supports, and where IL2 lands #195

Description

@JohnHales

Description of Documentation Need

v3.0.0 folded FedRAMP Moderate into the FedRAMP High networking stage — fast/stages-aw/2-networking-a-fedramp-high became fast/stages-aw/2-networking-a-fedramp, and its README is now "FedRAMP High / Moderate Network". The resulting pattern is documented: docs/tdd.md:946 states plainly that the FedRAMP High / Moderate pattern uses a VDSS topology (Landing + DMZ) with Network Virtual Appliances, and reading the stage confirms it — net-vdss.tf creates vdss-dmz-0 (:66) and vdss-landing-0 (:93) unconditionally, and nva.tf creates the NVA cluster and its default-route-nva route (:185) with no regime branch. So a Moderate deployment inherits FedRAMP High's boundary design in full, and the only regime-sensitive input in the stage is kms_protection_level (variables.tf:239), applied to the NVA keyring at nva.tf:203.

What is not recorded anywhere is that a different Moderate pattern was planned, and what became of it. Design material we were working from in June 2026 described a third networking option — 2-networking-c-fedramp-mod, marked "coming soon", covering FedRAMP Moderate and IL2 — with a materially different design: Cloud NGFW endpoints in place of the NVA cluster, a single landing-zone VPC rather than the trust/untrust split, no DMZ VPC, and Cloud NAT in each VPC rather than egress through the appliances. Nothing resembling it exists at any tag we have checked, no .tf in the repository declares a Cloud NGFW firewall endpoint, and a code search for 2-networking-c returns nothing. The diagram from that material:

Image

Side by side with what the stage builds today:

DimensionPlanned Moderate patternShipped FedRAMP High / Moderate stage
PerimeterCloud NGFW endpoints, Enterprise editionNVA cluster on Compute Engine (nva.tf, no regime branch)
VPC designOne landing-zone VPCSeparate trust and untrust — vdss-landing-0, vdss-dmz-0
DMZ VPCNoneAlways created, both regimes
Internet egressCloud NAT per VPCSpoke → NVA → DMZ → Cloud NAT
RegionsUS plus Europe, Asia, South AmericaNo support statement
IL2Paired with ModerateNot mentioned in any networking documentation
Regime leverThe whole topologykms_protection_level only

To be clear: this is not a request to build that design. Folding Moderate into the NVA pattern may well be the right call, and docs/tdd.md describes two supported patterns as settled fact. The request is that the decision be recorded, because as things stand an operator planning a Moderate deployment cannot answer three questions from the repository.

Target Audience

Operators and architects choosing a compliance regime before they deploy — the topology decision drives both cost and the security-boundary story they will have to defend. Security auditors and SSP authors, who must describe the deployed boundary protection accurately per regime. Anyone estimating run cost, since an NVA cluster plus a DMZ VPC prices very differently from managed firewall endpoints.

Proposed Location

A short "Regime coverage" paragraph appended to the existing "FedRAMP High / Moderate Pattern (2-networking-a-fedramp)" block in docs/tdd.md §3.6, which is where the pattern is already described, plus the same statement in fast/stages-aw/2-networking-a-fedramp/README.md for anyone who arrives at the stage directly rather than through the design doc.

Content Outline / Draft

Three statements, none of which exists today:

  1. Was a Moderate-specific network pattern superseded, or is it deferred? One sentence either way settles it. If it is on a roadmap, saying so is just as useful as saying it was dropped.
  2. Which regions are supported for a Moderate deployment of this stage? The org-policy template already treats Moderate differently — gcp.resourceLocations allows in:us-locations for other regimes but only denies in:asia-east2-locations and in:global under FEDRAMP_MODERATE (fast/stages-aw/0-bootstrap/data/custom-org-policies/platform_policy.yaml:151-164), and compute.managed.restrictProtocolForwardingCreationForTypes is skipped under Moderate (:103-111). So policy permits regions the networking stage makes no support statement about, and an operator cannot tell whether the NVA path is expected to work in them.
  3. Where does IL2 land?IL2 is a recognized regime in regime_mapping (fast/stages-aw/0-bootstrap/variables.tf:333), but no networking stage README and no TDD section mentions it, so it is not clear which of the two patterns an IL2 deployment should use.

Compliance Context (if applicable)

FedRAMP Moderate, FedRAMP High and IL2 — the question is precisely which of them this stage covers and on what terms. Control-wise, the topology is the boundary-protection control, so SC-7 and AC-4 are what an SSP describing a Moderate deployment has to get right; SC-12 and SC-13 are where kms_protection_level, the one regime-sensitive input in the stage, applies.

Whatever the answer turns out to be, please record it in a comment here before closing. #101, the platform-level FedRAMP Moderate request, was closed as completed with no comment explaining what shipped — which is a large part of why this question has to be asked from the outside now rather than looked up.

Related: #191 reports a separate accuracy problem in the same stage's documentation, and #192 covers the workload-side half of this gap — the platform supports Moderate but no blueprint family targets it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Level of Effort - MediumModerate task requiring thought and testing; typically takes a couple of days to a weekPriority - MediumStandard features and non-blocking bugs; important for the current milestone but not urgentdocumentationImprovements or additions to documentation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
       blocks
      (function() {
      function addCopyButtons() {
      document.querySelectorAll('pre code').forEach(function(codeBlock) {
      if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
      codeBlock.parentElement.setAttribute('data-copy-added', 'true');
      var btn = document.createElement('button');
      btn.textContent = 'Copy';
      btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
      btn.onmouseover = function() { this.style.opacity = '1'; };
      btn.onmouseout = function() { this.style.opacity = '0.7'; };
      btn.onclick = function() {
      navigator.clipboard.writeText(codeBlock.textContent).then(function() {
      btn.textContent = 'Copied!';
      setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
      });
      };
      codeBlock.parentElement.style.position = 'relative';
      codeBlock.parentElement.appendChild(btn);
      });
      }
      addCopyButtons();
      // Re-run on dynamic content
      var observer = new MutationObserver(addCopyButtons);
      observer.observe(document.body, { childList: true, subtree: true });
      })();
      }
      } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
      })();
      (function(){
      try {
      var __m = "github.com";
      var __re = new RegExp('^' + "github\\.com" + '
      
      Skip to content

      [Documentation] FedRAMP Moderate networking: record whether a Moderate-specific network pattern was superseded, which regions it supports, and where IL2 lands #195

      Description

      @JohnHales

      Description of Documentation Need

      v3.0.0 folded FedRAMP Moderate into the FedRAMP High networking stage — fast/stages-aw/2-networking-a-fedramp-high became fast/stages-aw/2-networking-a-fedramp, and its README is now "FedRAMP High / Moderate Network". The resulting pattern is documented: docs/tdd.md:946 states plainly that the FedRAMP High / Moderate pattern uses a VDSS topology (Landing + DMZ) with Network Virtual Appliances, and reading the stage confirms it — net-vdss.tf creates vdss-dmz-0 (:66) and vdss-landing-0 (:93) unconditionally, and nva.tf creates the NVA cluster and its default-route-nva route (:185) with no regime branch. So a Moderate deployment inherits FedRAMP High's boundary design in full, and the only regime-sensitive input in the stage is kms_protection_level (variables.tf:239), applied to the NVA keyring at nva.tf:203.

      What is not recorded anywhere is that a different Moderate pattern was planned, and what became of it. Design material we were working from in June 2026 described a third networking option — 2-networking-c-fedramp-mod, marked "coming soon", covering FedRAMP Moderate and IL2 — with a materially different design: Cloud NGFW endpoints in place of the NVA cluster, a single landing-zone VPC rather than the trust/untrust split, no DMZ VPC, and Cloud NAT in each VPC rather than egress through the appliances. Nothing resembling it exists at any tag we have checked, no .tf in the repository declares a Cloud NGFW firewall endpoint, and a code search for 2-networking-c returns nothing. The diagram from that material:

      Image

      Side by side with what the stage builds today:

      DimensionPlanned Moderate patternShipped FedRAMP High / Moderate stage
      PerimeterCloud NGFW endpoints, Enterprise editionNVA cluster on Compute Engine (nva.tf, no regime branch)
      VPC designOne landing-zone VPCSeparate trust and untrust — vdss-landing-0, vdss-dmz-0
      DMZ VPCNoneAlways created, both regimes
      Internet egressCloud NAT per VPCSpoke → NVA → DMZ → Cloud NAT
      RegionsUS plus Europe, Asia, South AmericaNo support statement
      IL2Paired with ModerateNot mentioned in any networking documentation
      Regime leverThe whole topologykms_protection_level only

      To be clear: this is not a request to build that design. Folding Moderate into the NVA pattern may well be the right call, and docs/tdd.md describes two supported patterns as settled fact. The request is that the decision be recorded, because as things stand an operator planning a Moderate deployment cannot answer three questions from the repository.

      Target Audience

      Operators and architects choosing a compliance regime before they deploy — the topology decision drives both cost and the security-boundary story they will have to defend. Security auditors and SSP authors, who must describe the deployed boundary protection accurately per regime. Anyone estimating run cost, since an NVA cluster plus a DMZ VPC prices very differently from managed firewall endpoints.

      Proposed Location

      A short "Regime coverage" paragraph appended to the existing "FedRAMP High / Moderate Pattern (2-networking-a-fedramp)" block in docs/tdd.md §3.6, which is where the pattern is already described, plus the same statement in fast/stages-aw/2-networking-a-fedramp/README.md for anyone who arrives at the stage directly rather than through the design doc.

      Content Outline / Draft

      Three statements, none of which exists today:

      1. Was a Moderate-specific network pattern superseded, or is it deferred? One sentence either way settles it. If it is on a roadmap, saying so is just as useful as saying it was dropped.
      2. Which regions are supported for a Moderate deployment of this stage? The org-policy template already treats Moderate differently — gcp.resourceLocations allows in:us-locations for other regimes but only denies in:asia-east2-locations and in:global under FEDRAMP_MODERATE (fast/stages-aw/0-bootstrap/data/custom-org-policies/platform_policy.yaml:151-164), and compute.managed.restrictProtocolForwardingCreationForTypes is skipped under Moderate (:103-111). So policy permits regions the networking stage makes no support statement about, and an operator cannot tell whether the NVA path is expected to work in them.
      3. Where does IL2 land?IL2 is a recognized regime in regime_mapping (fast/stages-aw/0-bootstrap/variables.tf:333), but no networking stage README and no TDD section mentions it, so it is not clear which of the two patterns an IL2 deployment should use.

      Compliance Context (if applicable)

      FedRAMP Moderate, FedRAMP High and IL2 — the question is precisely which of them this stage covers and on what terms. Control-wise, the topology is the boundary-protection control, so SC-7 and AC-4 are what an SSP describing a Moderate deployment has to get right; SC-12 and SC-13 are where kms_protection_level, the one regime-sensitive input in the stage, applies.

      Whatever the answer turns out to be, please record it in a comment here before closing. #101, the platform-level FedRAMP Moderate request, was closed as completed with no comment explaining what shipped — which is a large part of why this question has to be asked from the outside now rather than looked up.

      Related: #191 reports a separate accuracy problem in the same stage's documentation, and #192 covers the workload-side half of this gap — the platform supports Moderate but no blueprint family targets it.

      Metadata

      Metadata

      Assignees

      No one assigned

        Labels

        Level of Effort - MediumModerate task requiring thought and testing; typically takes a couple of days to a weekPriority - MediumStandard features and non-blocking bugs; important for the current milestone but not urgentdocumentationImprovements or additions to documentation

        Type

        No type

        Projects

        No projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
          Skip to content

          [Documentation] FedRAMP Moderate networking: record whether a Moderate-specific network pattern was superseded, which regions it supports, and where IL2 lands #195

          Description

          @JohnHales

          Description of Documentation Need

          v3.0.0 folded FedRAMP Moderate into the FedRAMP High networking stage — fast/stages-aw/2-networking-a-fedramp-high became fast/stages-aw/2-networking-a-fedramp, and its README is now "FedRAMP High / Moderate Network". The resulting pattern is documented: docs/tdd.md:946 states plainly that the FedRAMP High / Moderate pattern uses a VDSS topology (Landing + DMZ) with Network Virtual Appliances, and reading the stage confirms it — net-vdss.tf creates vdss-dmz-0 (:66) and vdss-landing-0 (:93) unconditionally, and nva.tf creates the NVA cluster and its default-route-nva route (:185) with no regime branch. So a Moderate deployment inherits FedRAMP High's boundary design in full, and the only regime-sensitive input in the stage is kms_protection_level (variables.tf:239), applied to the NVA keyring at nva.tf:203.

          What is not recorded anywhere is that a different Moderate pattern was planned, and what became of it. Design material we were working from in June 2026 described a third networking option — 2-networking-c-fedramp-mod, marked "coming soon", covering FedRAMP Moderate and IL2 — with a materially different design: Cloud NGFW endpoints in place of the NVA cluster, a single landing-zone VPC rather than the trust/untrust split, no DMZ VPC, and Cloud NAT in each VPC rather than egress through the appliances. Nothing resembling it exists at any tag we have checked, no .tf in the repository declares a Cloud NGFW firewall endpoint, and a code search for 2-networking-c returns nothing. The diagram from that material:

          Image

          Side by side with what the stage builds today:

          DimensionPlanned Moderate patternShipped FedRAMP High / Moderate stage
          PerimeterCloud NGFW endpoints, Enterprise editionNVA cluster on Compute Engine (nva.tf, no regime branch)
          VPC designOne landing-zone VPCSeparate trust and untrust — vdss-landing-0, vdss-dmz-0
          DMZ VPCNoneAlways created, both regimes
          Internet egressCloud NAT per VPCSpoke → NVA → DMZ → Cloud NAT
          RegionsUS plus Europe, Asia, South AmericaNo support statement
          IL2Paired with ModerateNot mentioned in any networking documentation
          Regime leverThe whole topologykms_protection_level only

          To be clear: this is not a request to build that design. Folding Moderate into the NVA pattern may well be the right call, and docs/tdd.md describes two supported patterns as settled fact. The request is that the decision be recorded, because as things stand an operator planning a Moderate deployment cannot answer three questions from the repository.

          Target Audience

          Operators and architects choosing a compliance regime before they deploy — the topology decision drives both cost and the security-boundary story they will have to defend. Security auditors and SSP authors, who must describe the deployed boundary protection accurately per regime. Anyone estimating run cost, since an NVA cluster plus a DMZ VPC prices very differently from managed firewall endpoints.

          Proposed Location

          A short "Regime coverage" paragraph appended to the existing "FedRAMP High / Moderate Pattern (2-networking-a-fedramp)" block in docs/tdd.md §3.6, which is where the pattern is already described, plus the same statement in fast/stages-aw/2-networking-a-fedramp/README.md for anyone who arrives at the stage directly rather than through the design doc.

          Content Outline / Draft

          Three statements, none of which exists today:

          1. Was a Moderate-specific network pattern superseded, or is it deferred? One sentence either way settles it. If it is on a roadmap, saying so is just as useful as saying it was dropped.
          2. Which regions are supported for a Moderate deployment of this stage? The org-policy template already treats Moderate differently — gcp.resourceLocations allows in:us-locations for other regimes but only denies in:asia-east2-locations and in:global under FEDRAMP_MODERATE (fast/stages-aw/0-bootstrap/data/custom-org-policies/platform_policy.yaml:151-164), and compute.managed.restrictProtocolForwardingCreationForTypes is skipped under Moderate (:103-111). So policy permits regions the networking stage makes no support statement about, and an operator cannot tell whether the NVA path is expected to work in them.
          3. Where does IL2 land?IL2 is a recognized regime in regime_mapping (fast/stages-aw/0-bootstrap/variables.tf:333), but no networking stage README and no TDD section mentions it, so it is not clear which of the two patterns an IL2 deployment should use.

          Compliance Context (if applicable)

          FedRAMP Moderate, FedRAMP High and IL2 — the question is precisely which of them this stage covers and on what terms. Control-wise, the topology is the boundary-protection control, so SC-7 and AC-4 are what an SSP describing a Moderate deployment has to get right; SC-12 and SC-13 are where kms_protection_level, the one regime-sensitive input in the stage, applies.

          Whatever the answer turns out to be, please record it in a comment here before closing. #101, the platform-level FedRAMP Moderate request, was closed as completed with no comment explaining what shipped — which is a large part of why this question has to be asked from the outside now rather than looked up.

          Related: #191 reports a separate accuracy problem in the same stage's documentation, and #192 covers the workload-side half of this gap — the platform supports Moderate but no blueprint family targets it.

          Metadata

          Metadata

          Assignees

          No one assigned

            Labels

            Level of Effort - MediumModerate task requiring thought and testing; typically takes a couple of days to a weekPriority - MediumStandard features and non-blocking bugs; important for the current milestone but not urgentdocumentationImprovements or additions to documentation

            Type

            No type

            Projects

            No projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              [Documentation] FedRAMP Moderate networking: record whether a Moderate-specific network pattern was superseded, which regions it supports, and where IL2 lands #195

              Description

              @JohnHales

              Description of Documentation Need

              v3.0.0 folded FedRAMP Moderate into the FedRAMP High networking stage — fast/stages-aw/2-networking-a-fedramp-high became fast/stages-aw/2-networking-a-fedramp, and its README is now "FedRAMP High / Moderate Network". The resulting pattern is documented: docs/tdd.md:946 states plainly that the FedRAMP High / Moderate pattern uses a VDSS topology (Landing + DMZ) with Network Virtual Appliances, and reading the stage confirms it — net-vdss.tf creates vdss-dmz-0 (:66) and vdss-landing-0 (:93) unconditionally, and nva.tf creates the NVA cluster and its default-route-nva route (:185) with no regime branch. So a Moderate deployment inherits FedRAMP High's boundary design in full, and the only regime-sensitive input in the stage is kms_protection_level (variables.tf:239), applied to the NVA keyring at nva.tf:203.

              What is not recorded anywhere is that a different Moderate pattern was planned, and what became of it. Design material we were working from in June 2026 described a third networking option — 2-networking-c-fedramp-mod, marked "coming soon", covering FedRAMP Moderate and IL2 — with a materially different design: Cloud NGFW endpoints in place of the NVA cluster, a single landing-zone VPC rather than the trust/untrust split, no DMZ VPC, and Cloud NAT in each VPC rather than egress through the appliances. Nothing resembling it exists at any tag we have checked, no .tf in the repository declares a Cloud NGFW firewall endpoint, and a code search for 2-networking-c returns nothing. The diagram from that material:

              Image

              Side by side with what the stage builds today:

              DimensionPlanned Moderate patternShipped FedRAMP High / Moderate stage
              PerimeterCloud NGFW endpoints, Enterprise editionNVA cluster on Compute Engine (nva.tf, no regime branch)
              VPC designOne landing-zone VPCSeparate trust and untrust — vdss-landing-0, vdss-dmz-0
              DMZ VPCNoneAlways created, both regimes
              Internet egressCloud NAT per VPCSpoke → NVA → DMZ → Cloud NAT
              RegionsUS plus Europe, Asia, South AmericaNo support statement
              IL2Paired with ModerateNot mentioned in any networking documentation
              Regime leverThe whole topologykms_protection_level only

              To be clear: this is not a request to build that design. Folding Moderate into the NVA pattern may well be the right call, and docs/tdd.md describes two supported patterns as settled fact. The request is that the decision be recorded, because as things stand an operator planning a Moderate deployment cannot answer three questions from the repository.

              Target Audience

              Operators and architects choosing a compliance regime before they deploy — the topology decision drives both cost and the security-boundary story they will have to defend. Security auditors and SSP authors, who must describe the deployed boundary protection accurately per regime. Anyone estimating run cost, since an NVA cluster plus a DMZ VPC prices very differently from managed firewall endpoints.

              Proposed Location

              A short "Regime coverage" paragraph appended to the existing "FedRAMP High / Moderate Pattern (2-networking-a-fedramp)" block in docs/tdd.md §3.6, which is where the pattern is already described, plus the same statement in fast/stages-aw/2-networking-a-fedramp/README.md for anyone who arrives at the stage directly rather than through the design doc.

              Content Outline / Draft

              Three statements, none of which exists today:

              1. Was a Moderate-specific network pattern superseded, or is it deferred? One sentence either way settles it. If it is on a roadmap, saying so is just as useful as saying it was dropped.
              2. Which regions are supported for a Moderate deployment of this stage? The org-policy template already treats Moderate differently — gcp.resourceLocations allows in:us-locations for other regimes but only denies in:asia-east2-locations and in:global under FEDRAMP_MODERATE (fast/stages-aw/0-bootstrap/data/custom-org-policies/platform_policy.yaml:151-164), and compute.managed.restrictProtocolForwardingCreationForTypes is skipped under Moderate (:103-111). So policy permits regions the networking stage makes no support statement about, and an operator cannot tell whether the NVA path is expected to work in them.
              3. Where does IL2 land?IL2 is a recognized regime in regime_mapping (fast/stages-aw/0-bootstrap/variables.tf:333), but no networking stage README and no TDD section mentions it, so it is not clear which of the two patterns an IL2 deployment should use.

              Compliance Context (if applicable)

              FedRAMP Moderate, FedRAMP High and IL2 — the question is precisely which of them this stage covers and on what terms. Control-wise, the topology is the boundary-protection control, so SC-7 and AC-4 are what an SSP describing a Moderate deployment has to get right; SC-12 and SC-13 are where kms_protection_level, the one regime-sensitive input in the stage, applies.

              Whatever the answer turns out to be, please record it in a comment here before closing. #101, the platform-level FedRAMP Moderate request, was closed as completed with no comment explaining what shipped — which is a large part of why this question has to be asked from the outside now rather than looked up.

              Related: #191 reports a separate accuracy problem in the same stage's documentation, and #192 covers the workload-side half of this gap — the platform supports Moderate but no blueprint family targets it.

              Metadata

              Metadata

              Assignees

              No one assigned

                Labels

                Level of Effort - MediumModerate task requiring thought and testing; typically takes a couple of days to a weekPriority - MediumStandard features and non-blocking bugs; important for the current milestone but not urgentdocumentationImprovements or additions to documentation

                Type

                No type

                Projects

                No projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions

                  , 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
                  Skip to content

                  [Documentation] FedRAMP Moderate networking: record whether a Moderate-specific network pattern was superseded, which regions it supports, and where IL2 lands #195

                  Description

                  @JohnHales

                  Description of Documentation Need

                  v3.0.0 folded FedRAMP Moderate into the FedRAMP High networking stage — fast/stages-aw/2-networking-a-fedramp-high became fast/stages-aw/2-networking-a-fedramp, and its README is now "FedRAMP High / Moderate Network". The resulting pattern is documented: docs/tdd.md:946 states plainly that the FedRAMP High / Moderate pattern uses a VDSS topology (Landing + DMZ) with Network Virtual Appliances, and reading the stage confirms it — net-vdss.tf creates vdss-dmz-0 (:66) and vdss-landing-0 (:93) unconditionally, and nva.tf creates the NVA cluster and its default-route-nva route (:185) with no regime branch. So a Moderate deployment inherits FedRAMP High's boundary design in full, and the only regime-sensitive input in the stage is kms_protection_level (variables.tf:239), applied to the NVA keyring at nva.tf:203.

                  What is not recorded anywhere is that a different Moderate pattern was planned, and what became of it. Design material we were working from in June 2026 described a third networking option — 2-networking-c-fedramp-mod, marked "coming soon", covering FedRAMP Moderate and IL2 — with a materially different design: Cloud NGFW endpoints in place of the NVA cluster, a single landing-zone VPC rather than the trust/untrust split, no DMZ VPC, and Cloud NAT in each VPC rather than egress through the appliances. Nothing resembling it exists at any tag we have checked, no .tf in the repository declares a Cloud NGFW firewall endpoint, and a code search for 2-networking-c returns nothing. The diagram from that material:

                  Image

                  Side by side with what the stage builds today:

                  DimensionPlanned Moderate patternShipped FedRAMP High / Moderate stage
                  PerimeterCloud NGFW endpoints, Enterprise editionNVA cluster on Compute Engine (nva.tf, no regime branch)
                  VPC designOne landing-zone VPCSeparate trust and untrust — vdss-landing-0, vdss-dmz-0
                  DMZ VPCNoneAlways created, both regimes
                  Internet egressCloud NAT per VPCSpoke → NVA → DMZ → Cloud NAT
                  RegionsUS plus Europe, Asia, South AmericaNo support statement
                  IL2Paired with ModerateNot mentioned in any networking documentation
                  Regime leverThe whole topologykms_protection_level only

                  To be clear: this is not a request to build that design. Folding Moderate into the NVA pattern may well be the right call, and docs/tdd.md describes two supported patterns as settled fact. The request is that the decision be recorded, because as things stand an operator planning a Moderate deployment cannot answer three questions from the repository.

                  Target Audience

                  Operators and architects choosing a compliance regime before they deploy — the topology decision drives both cost and the security-boundary story they will have to defend. Security auditors and SSP authors, who must describe the deployed boundary protection accurately per regime. Anyone estimating run cost, since an NVA cluster plus a DMZ VPC prices very differently from managed firewall endpoints.

                  Proposed Location

                  A short "Regime coverage" paragraph appended to the existing "FedRAMP High / Moderate Pattern (2-networking-a-fedramp)" block in docs/tdd.md §3.6, which is where the pattern is already described, plus the same statement in fast/stages-aw/2-networking-a-fedramp/README.md for anyone who arrives at the stage directly rather than through the design doc.

                  Content Outline / Draft

                  Three statements, none of which exists today:

                  1. Was a Moderate-specific network pattern superseded, or is it deferred? One sentence either way settles it. If it is on a roadmap, saying so is just as useful as saying it was dropped.
                  2. Which regions are supported for a Moderate deployment of this stage? The org-policy template already treats Moderate differently — gcp.resourceLocations allows in:us-locations for other regimes but only denies in:asia-east2-locations and in:global under FEDRAMP_MODERATE (fast/stages-aw/0-bootstrap/data/custom-org-policies/platform_policy.yaml:151-164), and compute.managed.restrictProtocolForwardingCreationForTypes is skipped under Moderate (:103-111). So policy permits regions the networking stage makes no support statement about, and an operator cannot tell whether the NVA path is expected to work in them.
                  3. Where does IL2 land?IL2 is a recognized regime in regime_mapping (fast/stages-aw/0-bootstrap/variables.tf:333), but no networking stage README and no TDD section mentions it, so it is not clear which of the two patterns an IL2 deployment should use.

                  Compliance Context (if applicable)

                  FedRAMP Moderate, FedRAMP High and IL2 — the question is precisely which of them this stage covers and on what terms. Control-wise, the topology is the boundary-protection control, so SC-7 and AC-4 are what an SSP describing a Moderate deployment has to get right; SC-12 and SC-13 are where kms_protection_level, the one regime-sensitive input in the stage, applies.

                  Whatever the answer turns out to be, please record it in a comment here before closing. #101, the platform-level FedRAMP Moderate request, was closed as completed with no comment explaining what shipped — which is a large part of why this question has to be asked from the outside now rather than looked up.

                  Related: #191 reports a separate accuracy problem in the same stage's documentation, and #192 covers the workload-side half of this gap — the platform supports Moderate but no blueprint family targets it.

                  Metadata

                  Metadata

                  Assignees

                  No one assigned

                    Labels

                    Level of Effort - MediumModerate task requiring thought and testing; typically takes a couple of days to a weekPriority - MediumStandard features and non-blocking bugs; important for the current milestone but not urgentdocumentationImprovements or additions to documentation

                    Type

                    No type

                    Projects

                    No projects

                      Milestone

                      No milestone

                      Relationships

                      None yet

                      Development

                      No branches or pull requests

                      Issue actions

                      , 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
                      Skip to content

                      [Documentation] FedRAMP Moderate networking: record whether a Moderate-specific network pattern was superseded, which regions it supports, and where IL2 lands #195

                      Description

                      @JohnHales

                      Description of Documentation Need

                      v3.0.0 folded FedRAMP Moderate into the FedRAMP High networking stage — fast/stages-aw/2-networking-a-fedramp-high became fast/stages-aw/2-networking-a-fedramp, and its README is now "FedRAMP High / Moderate Network". The resulting pattern is documented: docs/tdd.md:946 states plainly that the FedRAMP High / Moderate pattern uses a VDSS topology (Landing + DMZ) with Network Virtual Appliances, and reading the stage confirms it — net-vdss.tf creates vdss-dmz-0 (:66) and vdss-landing-0 (:93) unconditionally, and nva.tf creates the NVA cluster and its default-route-nva route (:185) with no regime branch. So a Moderate deployment inherits FedRAMP High's boundary design in full, and the only regime-sensitive input in the stage is kms_protection_level (variables.tf:239), applied to the NVA keyring at nva.tf:203.

                      What is not recorded anywhere is that a different Moderate pattern was planned, and what became of it. Design material we were working from in June 2026 described a third networking option — 2-networking-c-fedramp-mod, marked "coming soon", covering FedRAMP Moderate and IL2 — with a materially different design: Cloud NGFW endpoints in place of the NVA cluster, a single landing-zone VPC rather than the trust/untrust split, no DMZ VPC, and Cloud NAT in each VPC rather than egress through the appliances. Nothing resembling it exists at any tag we have checked, no .tf in the repository declares a Cloud NGFW firewall endpoint, and a code search for 2-networking-c returns nothing. The diagram from that material:

                      Image

                      Side by side with what the stage builds today:

                      DimensionPlanned Moderate patternShipped FedRAMP High / Moderate stage
                      PerimeterCloud NGFW endpoints, Enterprise editionNVA cluster on Compute Engine (nva.tf, no regime branch)
                      VPC designOne landing-zone VPCSeparate trust and untrust — vdss-landing-0, vdss-dmz-0
                      DMZ VPCNoneAlways created, both regimes
                      Internet egressCloud NAT per VPCSpoke → NVA → DMZ → Cloud NAT
                      RegionsUS plus Europe, Asia, South AmericaNo support statement
                      IL2Paired with ModerateNot mentioned in any networking documentation
                      Regime leverThe whole topologykms_protection_level only

                      To be clear: this is not a request to build that design. Folding Moderate into the NVA pattern may well be the right call, and docs/tdd.md describes two supported patterns as settled fact. The request is that the decision be recorded, because as things stand an operator planning a Moderate deployment cannot answer three questions from the repository.

                      Target Audience

                      Operators and architects choosing a compliance regime before they deploy — the topology decision drives both cost and the security-boundary story they will have to defend. Security auditors and SSP authors, who must describe the deployed boundary protection accurately per regime. Anyone estimating run cost, since an NVA cluster plus a DMZ VPC prices very differently from managed firewall endpoints.

                      Proposed Location

                      A short "Regime coverage" paragraph appended to the existing "FedRAMP High / Moderate Pattern (2-networking-a-fedramp)" block in docs/tdd.md §3.6, which is where the pattern is already described, plus the same statement in fast/stages-aw/2-networking-a-fedramp/README.md for anyone who arrives at the stage directly rather than through the design doc.

                      Content Outline / Draft

                      Three statements, none of which exists today:

                      1. Was a Moderate-specific network pattern superseded, or is it deferred? One sentence either way settles it. If it is on a roadmap, saying so is just as useful as saying it was dropped.
                      2. Which regions are supported for a Moderate deployment of this stage? The org-policy template already treats Moderate differently — gcp.resourceLocations allows in:us-locations for other regimes but only denies in:asia-east2-locations and in:global under FEDRAMP_MODERATE (fast/stages-aw/0-bootstrap/data/custom-org-policies/platform_policy.yaml:151-164), and compute.managed.restrictProtocolForwardingCreationForTypes is skipped under Moderate (:103-111). So policy permits regions the networking stage makes no support statement about, and an operator cannot tell whether the NVA path is expected to work in them.
                      3. Where does IL2 land?IL2 is a recognized regime in regime_mapping (fast/stages-aw/0-bootstrap/variables.tf:333), but no networking stage README and no TDD section mentions it, so it is not clear which of the two patterns an IL2 deployment should use.

                      Compliance Context (if applicable)

                      FedRAMP Moderate, FedRAMP High and IL2 — the question is precisely which of them this stage covers and on what terms. Control-wise, the topology is the boundary-protection control, so SC-7 and AC-4 are what an SSP describing a Moderate deployment has to get right; SC-12 and SC-13 are where kms_protection_level, the one regime-sensitive input in the stage, applies.

                      Whatever the answer turns out to be, please record it in a comment here before closing. #101, the platform-level FedRAMP Moderate request, was closed as completed with no comment explaining what shipped — which is a large part of why this question has to be asked from the outside now rather than looked up.

                      Related: #191 reports a separate accuracy problem in the same stage's documentation, and #192 covers the workload-side half of this gap — the platform supports Moderate but no blueprint family targets it.

                      Metadata

                      Metadata

                      Assignees

                      No one assigned

                        Labels

                        Level of Effort - MediumModerate task requiring thought and testing; typically takes a couple of days to a weekPriority - MediumStandard features and non-blocking bugs; important for the current milestone but not urgentdocumentationImprovements or additions to documentation

                        Type

                        No type

                        Projects

                        No projects

                          Milestone

                          No milestone

                          Relationships

                          None yet

                          Development

                          No branches or pull requests

                          Issue actions

                          , 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
                          Skip to content

                          [Documentation] FedRAMP Moderate networking: record whether a Moderate-specific network pattern was superseded, which regions it supports, and where IL2 lands #195

                          Description

                          @JohnHales

                          Description of Documentation Need

                          v3.0.0 folded FedRAMP Moderate into the FedRAMP High networking stage — fast/stages-aw/2-networking-a-fedramp-high became fast/stages-aw/2-networking-a-fedramp, and its README is now "FedRAMP High / Moderate Network". The resulting pattern is documented: docs/tdd.md:946 states plainly that the FedRAMP High / Moderate pattern uses a VDSS topology (Landing + DMZ) with Network Virtual Appliances, and reading the stage confirms it — net-vdss.tf creates vdss-dmz-0 (:66) and vdss-landing-0 (:93) unconditionally, and nva.tf creates the NVA cluster and its default-route-nva route (:185) with no regime branch. So a Moderate deployment inherits FedRAMP High's boundary design in full, and the only regime-sensitive input in the stage is kms_protection_level (variables.tf:239), applied to the NVA keyring at nva.tf:203.

                          What is not recorded anywhere is that a different Moderate pattern was planned, and what became of it. Design material we were working from in June 2026 described a third networking option — 2-networking-c-fedramp-mod, marked "coming soon", covering FedRAMP Moderate and IL2 — with a materially different design: Cloud NGFW endpoints in place of the NVA cluster, a single landing-zone VPC rather than the trust/untrust split, no DMZ VPC, and Cloud NAT in each VPC rather than egress through the appliances. Nothing resembling it exists at any tag we have checked, no .tf in the repository declares a Cloud NGFW firewall endpoint, and a code search for 2-networking-c returns nothing. The diagram from that material:

                          Image

                          Side by side with what the stage builds today:

                          DimensionPlanned Moderate patternShipped FedRAMP High / Moderate stage
                          PerimeterCloud NGFW endpoints, Enterprise editionNVA cluster on Compute Engine (nva.tf, no regime branch)
                          VPC designOne landing-zone VPCSeparate trust and untrust — vdss-landing-0, vdss-dmz-0
                          DMZ VPCNoneAlways created, both regimes
                          Internet egressCloud NAT per VPCSpoke → NVA → DMZ → Cloud NAT
                          RegionsUS plus Europe, Asia, South AmericaNo support statement
                          IL2Paired with ModerateNot mentioned in any networking documentation
                          Regime leverThe whole topologykms_protection_level only

                          To be clear: this is not a request to build that design. Folding Moderate into the NVA pattern may well be the right call, and docs/tdd.md describes two supported patterns as settled fact. The request is that the decision be recorded, because as things stand an operator planning a Moderate deployment cannot answer three questions from the repository.

                          Target Audience

                          Operators and architects choosing a compliance regime before they deploy — the topology decision drives both cost and the security-boundary story they will have to defend. Security auditors and SSP authors, who must describe the deployed boundary protection accurately per regime. Anyone estimating run cost, since an NVA cluster plus a DMZ VPC prices very differently from managed firewall endpoints.

                          Proposed Location

                          A short "Regime coverage" paragraph appended to the existing "FedRAMP High / Moderate Pattern (2-networking-a-fedramp)" block in docs/tdd.md §3.6, which is where the pattern is already described, plus the same statement in fast/stages-aw/2-networking-a-fedramp/README.md for anyone who arrives at the stage directly rather than through the design doc.

                          Content Outline / Draft

                          Three statements, none of which exists today:

                          1. Was a Moderate-specific network pattern superseded, or is it deferred? One sentence either way settles it. If it is on a roadmap, saying so is just as useful as saying it was dropped.
                          2. Which regions are supported for a Moderate deployment of this stage? The org-policy template already treats Moderate differently — gcp.resourceLocations allows in:us-locations for other regimes but only denies in:asia-east2-locations and in:global under FEDRAMP_MODERATE (fast/stages-aw/0-bootstrap/data/custom-org-policies/platform_policy.yaml:151-164), and compute.managed.restrictProtocolForwardingCreationForTypes is skipped under Moderate (:103-111). So policy permits regions the networking stage makes no support statement about, and an operator cannot tell whether the NVA path is expected to work in them.
                          3. Where does IL2 land?IL2 is a recognized regime in regime_mapping (fast/stages-aw/0-bootstrap/variables.tf:333), but no networking stage README and no TDD section mentions it, so it is not clear which of the two patterns an IL2 deployment should use.

                          Compliance Context (if applicable)

                          FedRAMP Moderate, FedRAMP High and IL2 — the question is precisely which of them this stage covers and on what terms. Control-wise, the topology is the boundary-protection control, so SC-7 and AC-4 are what an SSP describing a Moderate deployment has to get right; SC-12 and SC-13 are where kms_protection_level, the one regime-sensitive input in the stage, applies.

                          Whatever the answer turns out to be, please record it in a comment here before closing. #101, the platform-level FedRAMP Moderate request, was closed as completed with no comment explaining what shipped — which is a large part of why this question has to be asked from the outside now rather than looked up.

                          Related: #191 reports a separate accuracy problem in the same stage's documentation, and #192 covers the workload-side half of this gap — the platform supports Moderate but no blueprint family targets it.

                          Metadata

                          Metadata

                          Assignees

                          No one assigned

                            Labels

                            Level of Effort - MediumModerate task requiring thought and testing; typically takes a couple of days to a weekPriority - MediumStandard features and non-blocking bugs; important for the current milestone but not urgentdocumentationImprovements or additions to documentation

                            Type

                            No type

                            Projects

                            No projects

                              Milestone

                              No milestone

                              Relationships

                              None yet

                              Development

                              No branches or pull requests

                              Issue actions

                              , 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                              Skip to content

                              [Documentation] FedRAMP Moderate networking: record whether a Moderate-specific network pattern was superseded, which regions it supports, and where IL2 lands #195

                              Description

                              @JohnHales

                              Description of Documentation Need

                              v3.0.0 folded FedRAMP Moderate into the FedRAMP High networking stage — fast/stages-aw/2-networking-a-fedramp-high became fast/stages-aw/2-networking-a-fedramp, and its README is now "FedRAMP High / Moderate Network". The resulting pattern is documented: docs/tdd.md:946 states plainly that the FedRAMP High / Moderate pattern uses a VDSS topology (Landing + DMZ) with Network Virtual Appliances, and reading the stage confirms it — net-vdss.tf creates vdss-dmz-0 (:66) and vdss-landing-0 (:93) unconditionally, and nva.tf creates the NVA cluster and its default-route-nva route (:185) with no regime branch. So a Moderate deployment inherits FedRAMP High's boundary design in full, and the only regime-sensitive input in the stage is kms_protection_level (variables.tf:239), applied to the NVA keyring at nva.tf:203.

                              What is not recorded anywhere is that a different Moderate pattern was planned, and what became of it. Design material we were working from in June 2026 described a third networking option — 2-networking-c-fedramp-mod, marked "coming soon", covering FedRAMP Moderate and IL2 — with a materially different design: Cloud NGFW endpoints in place of the NVA cluster, a single landing-zone VPC rather than the trust/untrust split, no DMZ VPC, and Cloud NAT in each VPC rather than egress through the appliances. Nothing resembling it exists at any tag we have checked, no .tf in the repository declares a Cloud NGFW firewall endpoint, and a code search for 2-networking-c returns nothing. The diagram from that material:

                              Image

                              Side by side with what the stage builds today:

                              DimensionPlanned Moderate patternShipped FedRAMP High / Moderate stage
                              PerimeterCloud NGFW endpoints, Enterprise editionNVA cluster on Compute Engine (nva.tf, no regime branch)
                              VPC designOne landing-zone VPCSeparate trust and untrust — vdss-landing-0, vdss-dmz-0
                              DMZ VPCNoneAlways created, both regimes
                              Internet egressCloud NAT per VPCSpoke → NVA → DMZ → Cloud NAT
                              RegionsUS plus Europe, Asia, South AmericaNo support statement
                              IL2Paired with ModerateNot mentioned in any networking documentation
                              Regime leverThe whole topologykms_protection_level only

                              To be clear: this is not a request to build that design. Folding Moderate into the NVA pattern may well be the right call, and docs/tdd.md describes two supported patterns as settled fact. The request is that the decision be recorded, because as things stand an operator planning a Moderate deployment cannot answer three questions from the repository.

                              Target Audience

                              Operators and architects choosing a compliance regime before they deploy — the topology decision drives both cost and the security-boundary story they will have to defend. Security auditors and SSP authors, who must describe the deployed boundary protection accurately per regime. Anyone estimating run cost, since an NVA cluster plus a DMZ VPC prices very differently from managed firewall endpoints.

                              Proposed Location

                              A short "Regime coverage" paragraph appended to the existing "FedRAMP High / Moderate Pattern (2-networking-a-fedramp)" block in docs/tdd.md §3.6, which is where the pattern is already described, plus the same statement in fast/stages-aw/2-networking-a-fedramp/README.md for anyone who arrives at the stage directly rather than through the design doc.

                              Content Outline / Draft

                              Three statements, none of which exists today:

                              1. Was a Moderate-specific network pattern superseded, or is it deferred? One sentence either way settles it. If it is on a roadmap, saying so is just as useful as saying it was dropped.
                              2. Which regions are supported for a Moderate deployment of this stage? The org-policy template already treats Moderate differently — gcp.resourceLocations allows in:us-locations for other regimes but only denies in:asia-east2-locations and in:global under FEDRAMP_MODERATE (fast/stages-aw/0-bootstrap/data/custom-org-policies/platform_policy.yaml:151-164), and compute.managed.restrictProtocolForwardingCreationForTypes is skipped under Moderate (:103-111). So policy permits regions the networking stage makes no support statement about, and an operator cannot tell whether the NVA path is expected to work in them.
                              3. Where does IL2 land?IL2 is a recognized regime in regime_mapping (fast/stages-aw/0-bootstrap/variables.tf:333), but no networking stage README and no TDD section mentions it, so it is not clear which of the two patterns an IL2 deployment should use.

                              Compliance Context (if applicable)

                              FedRAMP Moderate, FedRAMP High and IL2 — the question is precisely which of them this stage covers and on what terms. Control-wise, the topology is the boundary-protection control, so SC-7 and AC-4 are what an SSP describing a Moderate deployment has to get right; SC-12 and SC-13 are where kms_protection_level, the one regime-sensitive input in the stage, applies.

                              Whatever the answer turns out to be, please record it in a comment here before closing. #101, the platform-level FedRAMP Moderate request, was closed as completed with no comment explaining what shipped — which is a large part of why this question has to be asked from the outside now rather than looked up.

                              Related: #191 reports a separate accuracy problem in the same stage's documentation, and #192 covers the workload-side half of this gap — the platform supports Moderate but no blueprint family targets it.

                              Metadata

                              Metadata

                              Assignees

                              No one assigned

                                Labels

                                Level of Effort - MediumModerate task requiring thought and testing; typically takes a couple of days to a weekPriority - MediumStandard features and non-blocking bugs; important for the current milestone but not urgentdocumentationImprovements or additions to documentation

                                Type

                                No type

                                Projects

                                No projects

                                  Milestone

                                  No milestone

                                  Relationships

                                  None yet

                                  Development

                                  No branches or pull requests

                                  Issue actions