← AWS Retail Store Sample AppExamplesLegal NoticePrivacy

StackToIT Migration Intelligence Workspace

PROPOSAL — generated by StackToIT Assess. Architect review required before any decision.

Partially executable migration package · Proposal only · Not approved.

Technical details: run, versions, digest and evidence freshness

Assessment

Assessment
default (assessment format 0.24.0)
Assessment timestamp
Generated 2026-11-02 12:08 UTC by stacktoit 0.6.0-11562-g1966ddf116 (1966ddf116)
Run
f6267c3f-2848-4aa5-89df-5fee8b15b3b9 · source digest sha256:812c5ae3f6cc8530163abbf5b6fbe305ed3b363c4886ec6b87623db857ea0c70
Source snapshot
partly decided only at plan time · aws not locked; random not locked
STACKIT target profile
Stable network model: the experimental STACKIT VPC resources are not used (STACKIT_STABLE)
STACKIT provider version
0.121.0
Knowledge base version
0.384.0
Evidence freshness
Not assessed — Evidence freshness as one measure is not assessed in this build. Dated evidence is shown where it is used: each STACKIT support option and each assurance row states when it was verified (verified_at, and recheck_after for support), in support_suitability and assurance. The date beside a readiness dimension is the assessment date, not a retrieval date.

Staleness: Not assessed — This build has no change detection, so there has been no re-check since the assessment was made (Generated 2026-11-02 12:08 UTC). The source may have changed since.

Source checks: Built-in source checks passed — OpenTofu validation of the source did not run (LOCK_FILE)

Run status: COMPLETE (report published). Source: partly decided only at plan time. Draft: GENERATED. The report was written whole; this is not a statement that the migration is ready.

Executive lens: the sections are in the order this reader usually wants, and Architecture and Engineering Evidence are put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Architect lens: the sections are in the order this reader usually wants, and Costs is put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Platform lens: the sections are in the order this reader usually wants, and Costs is put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Security lens: the sections are in the order this reader usually wants, and Costs and Migration Plan are put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Application owner lens: the sections are in the order this reader usually wants, and Engineering Evidence is put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Programme lens: the sections are in the order this reader usually wants, and Engineering Evidence is put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

FinOps lens: the sections are in the order this reader usually wants, and Architecture and Engineering Evidence are put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Engineering lens: the sections are in the order this reader usually wants, and Costs is put aside. Nothing is removed from the page: choose All to show every section in the order of the navigation, or follow a link into a section that is put aside.

Decisions, group g05: Availability & Resilience

Group g05 of 8. Work package Availability & Resilience: the full cards of 2 records. The Decisions page holds the records and lists every group.

Previous group (g04) · Next group (g06)

Availability & Resilience

2 records: 2 open input

What the 2 records below share:

What the draft does
The network carries no zone (the subnet's zone is named "not carried" in the Terraform comments). Every server reads the one zone variable (var.availability_zone) in a source of one zone, a zone variable named after the server, without a default, in a source of several zones, or the zone answered for it in target.placement.availability_zone.
Still open
Confirm the availability zone of the subnet: That the source's spread over zones and its failure domains are kept on the target. Owner hold: the record closes only by the explicit acceptance of the availability-zone difference in the decisions file. The knowledge base's closing condition names only the Single-AZ zones eu01-1, eu01-2 and eu01-3; the Metro zone is not among them. Confirm the availability zone of the subnet: The mapping rule for this kind of unit recognises the unit but only passes this setting to a person; it does not decide its value. The availability zone of the subnet. STACKIT networks are regional (stackit_network has no zone field, pinned provider); the zone is chosen per server and volume, and AWS zone names do not map to STACKIT zones. Confirm the availability zone of the subnet: The record closes only by the explicit acceptance of the availability-zone difference in the decisions file; an answered placement alone never closes it.
Ways out
  1. Confirm the availability zone of the subnet: Map each source zone to one STACKIT zone through the servers' placement; needs target.placement.availability_zone answered for each server whose zone the scan shows, with a zone the region's catalogue lists, the draft regenerated with the answers; effect: The servers and volumes of one source subnet land in the STACKIT zone chosen for its source zone; the networks stay regional. The record stays open until a review in the decisions file accepts the difference (accept-the-availability-zone-difference with its acceptance).; risk: Two source zones mapped to one STACKIT zone lose the spread without any error.; the draft is generated again with it
  2. Confirm the availability zone of the subnet: Redesign the resilience on the Metro zone (eu01-m); needs the architect's decision that single-instance failover replaces the spread over zones, target.placement.availability_zone answered eu01-m for the servers concerned, and the draft regenerated; effect: As for the volumes' zone: Metro restarts a failed instance in another zone and does not keep a spread of several instances. The Metro zone is not among the zones the knowledge base's closing condition names (eu01-1, eu01-2 or eu01-3), so on this path too the record closes only by the explicit acceptance of the availability-zone difference.; risk: The source's spread is not kept as a spread, and the Metro zone is not among the zones the closing condition names.; the draft is generated again with it
  3. Confirm the availability zone of the subnet: Accept the availability-zone difference of the placement the draft writes for the servers of the subnet; effect: The servers the subnet places stay, each with its volumes, in the one Single-AZ zone the regenerated draft writes for them; the STACKIT network of the subnet is regional. A Single-AZ server is not restarted in another zone when its zone fails and its volumes are not mirrored to another zone, so a zone outage takes down what sits in that zone. The Metro zone is no spread either: it restarts a single instance in another zone and may place all instances in one zone. The review accepts that difference with the source zone layout, the target placement of each server, the failure-domain difference, the recovery expectation (RTO and RPO) and the verification it requires; the check then closes as an accepted design change bound to the draft that writes those placements, and frees nothing else.
What closes it
Confirm the availability zone of the subnet: A person decides, per source zone, which STACKIT zone (eu01-1, eu01-2 or eu01-3) takes the servers and volumes that sat in it, so that the source's spread and its failure domains are kept. Verification: Confirm the availability zone of the subnet: placement evidence on the target for every server of the subnet; Confirm the availability zone of the subnet: a failure-domain assessment; Confirm the availability zone of the subnet: the recovery expectations and the backup and restore chain that meets them; Confirm the availability zone of the subnet: the architect's documented decision; Confirm the availability zone of the subnet: a validation result of the regenerated draft; Confirm the availability zone of the subnet: the explicit acceptance of the availability-zone difference, recorded in the decisions file with the source and target layout, the failure-domain difference and the recovery expectations.
Review the critical settings of a subnet (Platform Architect) open input

1 unit: module.vpc.module.vpc.aws_subnet.private · owner role Platform Architect · required by phase: not stated · 1 step rests on it

Options and trade-off
1 option across its settings, each with its trade-off under Technical details
Applications touched
none: no applications file was given and no suggested group holds an affected unit
Wave
not stated: none of its units is a member of a wave (a unit that does not exist, exists only when OpenTofu plans, or is refused for a missing input is in none) · steps in foundation
Approval
not approved: no decisions file was given with this run
What the draft does
Confirm the availability zone of the subnet: The draft does not carry the setting on module.vpc.module.vpc.aws_subnet.private; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_subnet.private/availability-zone).
Next action
Confirm the availability zone of the subnet: Confirm the availability zone of the subnet for module.vpc.module.vpc.aws_subnet.private, and record the answer for this record in the decisions file given with --decisions (decisions-template.yaml).
Technical details

Record DEC-OPS-MODULE-VPC-MODULE-VPC-AWS-SUBNET-PRIVATE (open critical semantic) · action: a choice between evidenced paths · decisions.json

Decision
the critical settings of a unit, of the aws.subnet contract
Why it exists
The knowledge base cannot decide 1 critical setting of module.vpc.module.vpc.aws_subnet.private: a person chooses what the STACKIT target does for it, or accepts the difference. The setting is an item of this record with its own reason, members and review state. A review of this record is the architect's answer beside the engine's reading; it closes nothing. 1 of them is on units that exist only if a plan-time input holds: the decision applies in a plan that creates them.
  • the failure-domain difference, named: a Single-AZ server is not restarted in another zone, and its volumes are not mirrored to another zone
  • the recovery expectation (RTO and RPO) the accepted placement has to meet, and the verification that shows it does
  • the source zone layout: which AWS zone each subnet is in and which servers it places there
  • the target placement of the servers of each subnet, as the regenerated draft writes it (target.placement.availability_zone answered); a STACKIT network is regional and has no zone
Affected applications
None named.
Open critical semantics (unit|semantic)
1
Show the 1 open critical semantics
  • alias module.vpc.module.vpc.aws_subnet.private|availability-zone

Repeated units among them, instance by instance (the member is the unit's, that of its hardest instance):

  • module.vpc.module.vpc.aws_subnet.private: not read instance by instance (unknown_count: the number of instances is not known statically)
Options
None listed.
Settings
1 critical setting of the unit, each with its own reason, state and options:
  1. Confirm the availability zone of the subnet (availability-zone): Open: no decision of the record has been taken. The knowledge base cannot decide "availability-zone" of the aws.subnet contract for 1 unit (left for a person to decide): a person chooses what the STACKIT target does for it, or accepts the difference. A review of this record is the architect's answer beside the engine's reading; it closes nothing. Here its unit exists only if a plan-time input holds (a root variable's default, the workspace; decided when OpenTofu plans): the decision applies only if it does, and the row of each such member in assurance/critical-semantics.json (critical_semantic_resolution.conditional_open, applies_only_if) says which input. Next: Confirm the availability zone of the subnet for module.vpc.module.vpc.aws_subnet.private, and record the answer for this record in the decisions file given with --decisions (decisions-template.yaml).
    • accept-the-availability-zone-difference — Accept the availability-zone difference of the placement the draft writes for the servers of the subnet. The servers the subnet places stay, each with its volumes, in the one Single-AZ zone the regenerated draft writes for them; the STACKIT network of the subnet is regional. A Single-AZ server is not restarted in another zone when its zone fails and its volumes are not mirrored to another zone, so a zone outage takes down what sits in that zone. The Metro zone is no spread either: it restarts a single instance in another zone and may place all instances in one zone. The review accepts that difference with the source zone layout, the target placement of each server, the failure-domain difference, the recovery expectation (RTO and RPO) and the verification it requires; the check then closes as an accepted design change bound to the draft that writes those placements, and frees nothing else.
Recommended option
None.
Status
Open: not decided yet.
Review the critical settings of a subnet (Platform Architect) open input

1 unit: module.vpc.module.vpc.aws_subnet.public · owner role Platform Architect · required by phase: not stated · 1 step rests on it

Options and trade-off
1 option across its settings, each with its trade-off under Technical details
Applications touched
none: no applications file was given and no suggested group holds an affected unit
Wave
not stated: none of its units is a member of a wave (a unit that does not exist, exists only when OpenTofu plans, or is refused for a missing input is in none) · steps in foundation
Approval
not approved: no decisions file was given with this run
What the draft does
Confirm the availability zone of the subnet: The draft does not carry the setting on module.vpc.module.vpc.aws_subnet.public; a manual step stands for it (MAN/semantic/module.vpc.module.vpc.aws_subnet.public/availability-zone).
Next action
Confirm the availability zone of the subnet: Confirm the availability zone of the subnet for module.vpc.module.vpc.aws_subnet.public, and record the answer for this record in the decisions file given with --decisions (decisions-template.yaml).
Technical details

Record DEC-OPS-MODULE-VPC-MODULE-VPC-AWS-SUBNET-PUBLIC (open critical semantic) · action: a choice between evidenced paths · decisions.json

Decision
the critical settings of a unit, of the aws.subnet contract
Why it exists
The knowledge base cannot decide 1 critical setting of module.vpc.module.vpc.aws_subnet.public: a person chooses what the STACKIT target does for it, or accepts the difference. The setting is an item of this record with its own reason, members and review state. A review of this record is the architect's answer beside the engine's reading; it closes nothing. 1 of them is on units that exist only if a plan-time input holds: the decision applies in a plan that creates them.
  • the failure-domain difference, named: a Single-AZ server is not restarted in another zone, and its volumes are not mirrored to another zone
  • the recovery expectation (RTO and RPO) the accepted placement has to meet, and the verification that shows it does
  • the source zone layout: which AWS zone each subnet is in and which servers it places there
  • the target placement of the servers of each subnet, as the regenerated draft writes it (target.placement.availability_zone answered); a STACKIT network is regional and has no zone
Affected applications
None named.
Open critical semantics (unit|semantic)
1
Show the 1 open critical semantics
  • alias module.vpc.module.vpc.aws_subnet.public|availability-zone

Repeated units among them, instance by instance (the member is the unit's, that of its hardest instance):

  • module.vpc.module.vpc.aws_subnet.public: not read instance by instance (unknown_count: the number of instances is not known statically)
Options
None listed.
Settings
1 critical setting of the unit, each with its own reason, state and options:
  1. Confirm the availability zone of the subnet (availability-zone): Open: no decision of the record has been taken. The knowledge base cannot decide "availability-zone" of the aws.subnet contract for 1 unit (left for a person to decide): a person chooses what the STACKIT target does for it, or accepts the difference. A review of this record is the architect's answer beside the engine's reading; it closes nothing. Here its unit exists only if a plan-time input holds (a root variable's default, the workspace; decided when OpenTofu plans): the decision applies only if it does, and the row of each such member in assurance/critical-semantics.json (critical_semantic_resolution.conditional_open, applies_only_if) says which input. Next: Confirm the availability zone of the subnet for module.vpc.module.vpc.aws_subnet.public, and record the answer for this record in the decisions file given with --decisions (decisions-template.yaml).
    • accept-the-availability-zone-difference — Accept the availability-zone difference of the placement the draft writes for the servers of the subnet. The servers the subnet places stay, each with its volumes, in the one Single-AZ zone the regenerated draft writes for them; the STACKIT network of the subnet is regional. A Single-AZ server is not restarted in another zone when its zone fails and its volumes are not mirrored to another zone, so a zone outage takes down what sits in that zone. The Metro zone is no spread either: it restarts a single instance in another zone and may place all instances in one zone. The review accepts that difference with the source zone layout, the target placement of each server, the failure-domain difference, the recovery expectation (RTO and RPO) and the verification it requires; the check then closes as an accepted design change bound to the draft that writes those placements, and frees nothing else.
Recommended option
None.
Status
Open: not decided yet.