Configuring compute, storage, and transit for a new host

Decide the immutable settings first

Some host properties cannot be changed after provisioning because they appear in attestation records and audit evidence. Changing them means decommissioning the host and provisioning a replacement.

Settle these before you confirm:

• Host name, which appears in attestation and audit records.
• Region, since a host cannot be relocated between facilities.
• Hardware profile, since the profile determines the expected launch measurement.
• Boundary assignment, which determines the control set applying to the host.

Storage profiles

Storage is provisioned as dedicated local media rather than a shared network volume. That has a direct consequence: capacity is fixed at provisioning and cannot be expanded by attaching more of a pooled resource.

Choose a profile by workload characteristic rather than by headline capacity. A profile that gives you the throughput you need at 60% utilization is a better outcome than one that gives you the capacity you need at 95%.

Media sanitization on decommission is part of your inherited baseline and produces MP-6 evidence automatically. You do not need to arrange separate disposal.

Transit and egress

A new host attaches to a segment from your network plan. Segments carry the boundary protection configuration our SC-7 evidence rests on, which is why hosts attach to a planned segment rather than getting an arbitrary address.

Egress is default deny. Outbound destinations are declared, not discovered, which usually surprises teams arriving from a shared public cloud where egress is open by default.

# declare an egress destination for a segment
servlogi net egress add \
  --segment seg-prod-app \
  --destination 203.0.113.0/24 \
  --port 443 \
  --justification "vendor API, ticket INF-2291"

The justification field is not decorative. It is retained and surfaces during assessment when an assessor asks why a given egress path exists.