Fast Path

Use these labels only as defined here — they describe how the mapping was chosen, not whether the AWS architecture is “obvious.”

User-facing vocabulary (chat, MIGRATION_GUIDE, migration-report)

JSON artifacts must keep the confidence string values above. When speaking or writing for end users, lead with plain English — do not use “deterministic,” “inferred,” or “rubric” as the primary label unless the user asks for technical detail.

BigQuery / specialist gate rows still store confidence: "inferred" in JSON; in user-facing text you may say Tailored to your setup and emphasize specialist engagement (no automated AWS analytics target).

Canonical reference: This subsection — other phase files should point here instead of redefining wording.

Common confusion: references/design-refs/index.md lists a typical AWS target per GCP service. That is not automatically the same as deterministic. Confidence is deterministic only when the exact Terraform resource type appears in the Direct Mappings table above and its conditions are met; otherwise confidence is inferred via rubric evaluation.

Add-ons (ALB, NAT, etc.): A row may say “Fargate” while the architecture diagram also includes an ALB or NAT Gateway from other Terraform resources. Confidence is still per resource row — e.g. google_cloud_run_service = inferred; google_compute_forwarding_rule + backend = often inferred (see networking.md).

Direct Mappings use confidence: deterministic (fixed table lookup — no rubric for that resource)

Direct Mappings Table

Cloud SQL PostgreSQL / MySQL — NOT in Direct Mappings

Do not assign google_sql_database_instance (PostgreSQL or MySQL) from this table. Always use Pass 2 + database.md rubric with confidence = inferred.

Q6 (design_constraints.availability) is the only selector for RDS vs Aurora:

Q12 (traffic) and Q13 (I/O) tune sizing and storage within the family Q6 chose — they never upgrade Inconvenient/Significant Issue workloads to Aurora.

Skip Mappings Table

These GCP resources do not require AWS equivalents in v1.0:

Note — App Engine app_version resources are config sources for the EB mapping. google_app_engine_standard_app_version and google_app_engine_flexible_app_version are skipped as standalone resources (above), but their config is read to build the parent’s mapping: runtime, instance_class, env_variables, and scaling live on the version resource, not on the parent google_app_engine_application. Discovery classifies them SECONDARY (configuration); because they link to the parent only by shared project (no ID reference), serves[] may be empty and they may cluster separately, so the App Engine fan-out step in phases/design/design-infra.md locates them by scanning the full inventory and emits one EB environment per App Engine service (grouping multiple versions of a service into one), so a multi-service app does not collapse into a single mapping. On the non-EB paths (Q7b container-orchestration/serverless, compute: "eks" multi-cloud, ambiguous attribution, or no parent) they are simply skipped like any other Skip Mapping — logged to warnings, never sent through the rubric or the unknown-type STOP. See elastic-beanstalk.md → “Where the config comes from (Terraform)”.

Preferred AWS Target Services

For the workload categories below, always steer toward the preferred AWS service. If rubric evaluation or LLM reasoning would select a non-preferred service, substitute the preferred alternative instead.

Enforcement: Check every resource mapping against this table before writing to aws-design.json or aws-design-billing.json. If a mapping would select a non-preferred service, substitute the preferred alternative.

Enforcement exemption (App Engine + explicit compute_model): When the user set compute_model: "container_orchestration" or "serverless" (Q7b = B/C), the App Engine eliminator in compute.md intentionally routes the resource to Fargate/Lambda. Do not apply the PaaS row to re-substitute Elastic Beanstalk in that case — the PaaS row’s condition (compute_model absent or "managed_platform") is already false, so it does not match. This mirrors how Cloud Run is exempt (always Containerized) and Cloud SQL is exempt (Q6 governs RDS-vs-Aurora).

Enforcement exemption (App Engine + compute: "eks" / Q5 = multi-cloud): When compute: "eks" is set (Q5 = multi-cloud), Q7b does not fire and App Engine routes to EKS via the container path (see compute.md App Engine section). Do not apply the PaaS row to re-substitute Elastic Beanstalk in that case — the PaaS row’s condition (compute ≠ "eks") is already false, so it does not match. This is the same top-level portability override that forces GKE to EKS.

Precedence: Match resources to the first applicable row. Cloud Run matches “Containerized workloads” regardless of compute_model. The “PaaS / managed platform” row applies to App Engine resources only when its compute_model condition holds (absent or "managed_platform") and compute ≠ "eks"; an App Engine resource with compute_model: "container_orchestration"/"serverless" — or with compute: "eks" (multi-cloud) — matches no row here and keeps its rubric-selected target (Fargate/Lambda, or EKS under multi-cloud).

Exception: For Cloud SQL PostgreSQL/MySQL, Q6 availability always overrides any implicit Aurora preference. Do not substitute Aurora when availability is single-az or multi-az.

Secondary Behavior Lookups

For resources in the Skip Mappings table but present in inventory:

1. Log as “secondary resource, no AWS equivalent needed”
2. Do not include in aws-design.json
3. Note in aws-design.json warnings array

Workflow:

1. Extract GCP resource type
2. Look up in Direct Mappings table
3. If found and condition met: assign AWS service (confidence = deterministic)
4. If google_sql_database_instance (PostgreSQL/MySQL): skip Direct Mappings → apply database.md rubric (confidence = inferred)
5. If found in Skip Mappings: skip it (confidence = n/a)
6. If not found: use design-refs/index.md to determine category → apply rubric in that category’s file