# Tenant, Not Landlord: Configuring a Program Inside a Government Shared Cloud

> Onboarding to Cloud One, cArmy, a JWCC task order or cloud.gov is an engineering job with a compliance deliverable at the end. Here is how platform selection, intake, tenant configuration inside the guardrails, and a control-by-control inheritance workbook fit together.

- Source: https://avalontechservices.com/news/tenant-not-landlord-configuring-a-program-inside-a-government-shared-cloud
- Published: 2026-10-28
- Author: [Brandon Ireland](https://avalontechservices.com/author/brandon-ireland)
- Category: Cloud & IT Infrastructure Services
- Topic: Cloud & IT Infrastructure Services
- Publisher: Avalon Technology Services

## Key Takeaways

- A shared cloud hands programs a foundation, but a tenant configured around the platform's guardrails instead of within them breaks at the next platform update.
- Choose the destination on evidence: impact-level support, inheritable controls, cost model, onboarding lead time, and exit terms, with a written decision record.
- Platform intake is a critical path; a rejected form usually goes back to the end of the queue, so track every step with an owner and dates.
- The tenant landing zone covers accounts, connectivity, identity, segmentation, logging, and tagging before any workload lands.
- The Control Inheritance Workbook records each control's position, basis, tenant implementation, evidence, and owner in rows that move straight into the SSP.

A government shared cloud hands a program office a finished foundation: accounts, networking, identity services, logging, and an authorization. The program's job is to become a well-behaved tenant. That is still engineering work, and most of the failure modes are specific to living inside someone else's guardrails. A tenant configured around the platform instead of within it breaks at the next platform update.

The scope here is unclassified: DoD IL2 and IL4 tenants and civilian FedRAMP Moderate destinations. IL5 adds cleared-staff and connectivity work, and IL6 is a separate problem entirely.

## Selection Comes Before Configuration

[The destination decides the control baseline](https://avalontechservices.com/capabilities/digital-transformation/cloud-and-it-infrastructure-services/gov-shared-cloud-services), the connectivity pattern, the identity path, and what the program can inherit. It should be chosen on evidence, not familiarity. The fit assessment starts with a workload and data inventory (CUI, PII, PHI, classification level). It then scores each candidate environment on five criteria:

| Criterion | What gets checked |
| --- | --- |
| Impact-level support | The platform's DISA provisional authorization level for DoD, or its FedRAMP class for civilian |
| Inheritable controls | What the platform's customer responsibility matrix actually hands the tenant |
| Cost model | Tenant service fees, chargeback mechanics, and how consumption is billed |
| Onboarding lead time | Intake steps, funding-document mechanics, and realistic queue time |
| Exit terms | Portability of configuration and data at the platform's next recompete |

The candidates depend on the agency. DoD programs weigh the Air Force's Cloud One, the Army's cArmy, Navy environments, DISA Stratus, and commercial capacity through JWCC task orders. JWCC alone passed [$3.9 billion in task orders by late 2025, with the Air Force onboarding](https://www.meritalk.com/articles/disa-reports-growth-in-jwcc-cloud-orders/). Civilian programs weigh agency enterprise clouds, GSA's cloud.gov, and FedRAMP shared offerings.

On the civilian side, FedRAMP now labels qualifying offerings ["FedRAMP Certified," with assurance classes A through D](https://www.fedramp.gov/2026/definitions/). The class tells the program the baseline, not the tenant's own posture.

The output is a recommendation with a written decision record. When no platform fits the impact level or mission, the record says so, and the program needs its own architecture.

## Intake Is a Critical Path, Not Paperwork

Platform intake is where schedules die quietly. A typical DoD sequence runs like this:

1. Identify the mission-owner sponsor and funding point of contact.
2. Execute the funding document (a MIPR, or an interagency agreement for cross-department buys).
3. Submit account and enclave requests with the impact-level determination.
4. Select the cloud provider region (AWS GovCloud, Azure Government, Google Cloud Assured Workloads, or Oracle government regions, depending on the platform).
5. Complete the platform's security and connectivity intake forms.

A rejected form usually sends the program back to the end of the queue. The engineering discipline that matters here is completeness: every artifact submitted correctly the first time, and every step the agency or platform owns written into the SOW with a date. Queue time is the one variable nobody on the program controls, so it has to be visible rather than absorbed. A simple tracker helps: each intake step, its owner, the date submitted, the date the platform acknowledged it, and the next action. It turns "we're waiting on the platform" into a specific ticket with a specific age.

## The Tenant Landing Zone

Inside the platform's guardrails, the tenant needs six things configured before any workload lands.

**Account and subscription structure.** Separate accounts or subscriptions for production, test, and development, following the platform's naming and hierarchy. The platform owns the organization root and its service control policies. The tenant owns what sits beneath them.

**Connectivity.** DoD tenants connect through Cloud Access Points and the Secure Cloud Computing Architecture components the platform provides, so the network path is approved by construction. Civilian tenants align connectivity to the applicable [CISA TIC 3.0 use case](https://www.cisa.gov/resources-tools/programs/trusted-internet-connections-tic). Both paths need the program's network point of contact engaged in week one, because change windows are fixed.

**Identity.** CAC or PIV-based federation through the agency ICAM service or an authorized identity provider, consistent with OMB M-19-17. Roles map to real job functions: program administrators, developers, auditors, and read-only reviewers. Break-glass accounts are documented, and every one has an owner.

**Segmentation.** Network segmentation inside the mission enclave separates the program from other tenants and separates tiers within the program. Ingress follows the platform's allowed patterns.

**Logging.** Tenant logs route to the platform's collection service or the agency SOC from day one. This matters for detection and for evidence: AU-family controls are usually shared, and the tenant's half is proving its logs actually arrive.

**Tagging.** A tag dictionary covering program, environment, owner, funding line, and data sensitivity, enforced at creation. Without it, consumption billed through the platform cannot be attributed, and [cloud spend nobody can see becomes spend nobody can defend](https://avalontechservices.com/news/the-hidden-tax-on-your-federal-cloud-budget).

## Guardrails Catch the Classic Misconfigurations

Shared platforms enforce baseline policy at the organization level. The tenant's configuration should assume those policies exist and add program-specific ones rather than fighting them. The misconfigurations that still reach tenants tend to be the same four:

- **Wildcard IAM permissions** granted to get a pipeline working. Scope roles to the resources and actions the job needs, and review them at handoff.
- **Permissive storage buckets** created for a data exchange. Keep the account-level public-access block on and use the platform's approved sharing pattern.
- **Unencrypted EBS volumes** or managed disks from an old template. Enforce encryption by default with keys managed under the program's key policy.
- **Security groups open to 0.0.0.0/0** on management ports. Management access goes through the platform's bastion or session-manager pattern, never a public port.

## Infrastructure-as-Code the Program Can Maintain

Where the platform permits customer-managed code, the tenant baseline is written in Terraform or OpenTofu using DoD Cloud IaC baselines or the platform's own modules. Two rules apply. First, build on platform modules rather than replicating them, so platform updates flow through instead of colliding. Second, write for the program's own staff: plain module structure, documented variables, and a working-session handoff. Code nobody on the program can change becomes a liability the day the engagement ends.

## The Control Inheritance Workbook

The platform's customer responsibility matrix says, in general terms, which controls the platform provides and which fall to tenants. The workbook applies that to one mission system. For every control in the system's NIST SP 800-53 baseline, it records five things:

1. **Position:** inherited, shared, or program-owned.
2. **Basis:** the platform authorization and CRM line that supports the position.
3. **Tenant implementation:** for shared and program-owned controls, what the program configured and where.
4. **Evidence:** configuration exports, screenshots, logs, or procedures an assessor can check.
5. **Owner:** the person on the program responsible for the control going forward.

Typical positions look like this for an IaaS tenant. PE-3 physical access is inherited. AC-2 account management, AU-6 audit review, IA-2 authentication, and SC-7 boundary protection are shared. SI-2 flaw remediation for the program's own systems and CA-2 control assessment are program-owned.

The workbook is structured so rows move straight into the System Security Plan. That feeds the RMF steps the program still owns, which an [RMF roadmap of who owns each step](https://avalontechservices.com/news/who-owns-what-in-ongoing-authorization-an-rmf-roadmap-for-program-offices) lays out in full.

The workbook also carries a zero trust map. It shows which activities the platform delivers and which the tenant must implement before DoD's [target-level zero trust deadline at the end of FY2027](https://defensescoop.com/2025/12/09/dod-zero-trust-strategy-2-0-expected-early-2026/).

## Where Tenant Configurations Go Wrong

Most tenant problems trace to one of four choices made under schedule pressure.

- **Working around a guardrail instead of requesting an exception.** A custom route table or an unapproved identity provider may pass today and fail the next platform baseline update. When the pattern genuinely does not fit, the answer is a documented exception request through the platform office, not a quiet workaround.
- **Absorbing the program's older rogue accounts.** Accounts the program opened before onboarding carry their own configuration drift and data. Bringing them into the tenant is a separate remediation, scoped and priced on its own, with its own discovery.
- **Treating the platform's defaults as the program's decisions.** Default log retention, session timeouts, and key rotation periods are the platform's settings. The program still has to decide its own values and record them.
- **Skipping exit notes.** Shared platforms are recompeted. A tenant with no record of its dependencies on platform-specific services will find that out during the next transition, when it is most expensive.

## Handoff and Acceptance

The engagement ends at a tenant-ready state, measured against a written checklist:

- Accounts provisioned
- Identity federated
- Connectivity approved
- Logging verified
- Tags enforced
- Workbook delivered and reviewed with the ISSO

Handoff adds a service-request runbook for the platform, a roles and permissions model, a chargeback model, and exit and portability notes. It closes with a recorded working session. Moving the applications is the next engagement, not this one.

Avalon's Gov-Shared Cloud Services engagement delivers this sequence as a fixed-fee sprint of four to ten weeks. It covers platform scoring, intake, tenant configuration inside the guardrails, and the Control Inheritance Workbook. The first technical deliverable is the scored platform comparison and decision record that fixes your baseline, your connectivity path, and what your program can inherit.