現行構成とサービス一覧

AWS runtime の管理境界、環境分離、主要サービスの責務を公開仕様として整理します。 前提となる公開境界と、個別デプロイの承認記録・内部運用証跡など扱わない範囲は AWS runtime 境界 を参照してください。

Terraform root ごとの管理境界

AWS runtime は Terraform の root ごとに責務を分けて管理します。 root ごとの管理対象と所有しない範囲の正本は Terraform > Root ownership です。要約は次のとおりです。

• infra/terraform/app：target application runtime（CloudFront + frontend、API、DynamoDB、queue / SFN / ECS / S3、observability）。ECR repository や image publication は所有せず、digest 固定の prover image URI を消費する
• infra/terraform/foundation：app 実行の前提リソース（ECR、ECR retention controller、manifest storage、secret / config container、prover networking）。app runtime resource は作らない
• infra/terraform/bootstrap：Terraform state backend と deployment-control lane、report-only controls、暗号化された authority storage。runtime workload resource は所有しない
• infra/terraform/legacy：retained historical context。現行 runtime の authority ではない

環境分離

develop と main は source branch / account alias / deployment environment / state scope を分けて扱います。 現在の live target app lane は stark-dev/develop/app です。 stark-prod/main/app は protected production contract の repository evidence として render されます。 これは非変更 evidence であり、live production deployment はまだ承認しません。 Target は target-aws-async profile による production STARK 証明を前提にします。Local 実行意図の authority は semantic RUNTIME_PROFILE（local-demo、static-mock-e2e、local-proof-development、local-proof-production）であり、置き換え済みの RISC0_DEV_MODE / USE_MOCK_ZKVM selector は拒否します。

環境別に分かれるものは次のとおりです。

• app runtime state、proof artifact storage
• DynamoDB と選択された recovery pair
• queue / worker、Step Functions、ECS task definition
• runtime SSM refs
• CloudWatch logs / metrics / alarms / ledger
• develop operator gate の trust resources

ECR repository や manifest storage など、app 実行の前提になるリソースは foundation root の責務として扱います。

全体構成図

図: STARK Ballot Simulator の AWS 全体構成（クリックで拡大）。

サービス一覧

この runtime が使う主要な AWS サービスと役割です。

App runtime

サービス表の補足は次のとおりです。

• Observability：telemetry は verification verdict を変更せず、自動 remediation も起動しません。Verification invariant の直接通知と、隔離された ops-actionable 経路の routing 対象（damped alarm と exact owned-pipeline failure）は 可観測性設計 > 通知の境界 が正本です。その他の調査用 alarm は passive です。
• Artifact 境界：public の分類、bundle.zip の除外 artifact、verification.json の capability 保護配信は 公開境界 の定義に従います。
• DynamoDB recovery：4 phase の定義と quiesce を含む切替契約は Terraform を参照してください。
• Develop operator gate：追跡対象の keyset manifest を authority とし、KMS の private signing material を Terraform state、pipeline artifact、runtime role に渡しません。KMS から導出した public key だけを CloudFront trust group に登録し、署名権限は target runtime の責務外に保ちます。

Foundation resources

Prover image metadata、promotion evidence、release record / accepted pointer は proof artifact bucket ではなく image build / signing と runtime wiring の境界に属し、旧構成の SSM current pointer は候補 metadata lookup にとどまります（target topology の release authority ではありません）。 Image build、digest 固定、署名ステータス確認、Image ID との関係は イメージ署名 に集約します。 ECR retention は count / age ベースの native lifecycle expiry ではなく、Foundation-owned の reference-aware retention controller が担います（保護対象と動作の正本は Terraform > Retention authority）。

Deployment control

Report-only drift は accepted Terraform baseline と exact historical source を使って refresh-enabled plan を実行し、redacted report だけを保存します。Rollback / recovery readiness も同じ隔離された App planning 境界を使います。どちらも Apply、state / pointer write、remediation、rollback / recovery exercise を起動せず、その結果は saved plan や mutation の authority になりません。

図: GitHub から CodePipeline deployment lanes を経て app runtime に到達するデプロイ制御フロー（クリックで拡大）。

個別の承認手順、証跡、昇格判断の詳細は公開仕様の範囲外です。

Approval の条件は次のとおりです。

• approval を省略できるのは、normal mode で saved plan に変更がないと機械的に証明された場合だけです。
• Rollback は Terraform plan が空でも approval を必須とします。

Post-apply smoke 後の immutable acceptance evidence 保存と accepted-deployment index の compare-and-swap 更新を含め、詳細は Terraform を参照してください。

Runtime wiring

Runtime の連携は Terraform output、SSM reference、Lambda environment、S3 / SQS / Step Functions locator によって行われます。

flowchart TB
  subgraph FOUNDATION["infra/terraform/foundation"]
    ECR["ECR repositories<br/>prover / toolchain"]
    MANIFEST["Manifest storage<br/>release records / promotion evidence"]
    CONFIG["Secret/config containers<br/>Secrets Manager / SSM"]
    NET["Prover networking inputs"]
    RETENTION["Reference-aware ECR retention"]
  end

  subgraph APP["infra/terraform/app"]
    OUT["Terraform outputs<br/>API / bucket / queue / lambda names"]
    PARAM["SSM refs<br/>runtime config"]
    RUNTIME["Runtime resources<br/>CloudFront / API / DDB / SQS / SFN / ECS"]
    GATE["Develop operator gate<br/>KMS signing keys / CloudFront trust group"]
    DATA["DynamoDB active pair<br/>primary or validated replacement"]
    SEM["Prover semaphore<br/>DDB lock row / janitor"]
    ARTIFACTS["Private proof artifact S3<br/>bundle source / protected report"]
    OBS["Observability<br/>CloudWatch / EventBridge / SNS"]
  end

  subgraph BOOT["infra/terraform/bootstrap"]
    CONTROL["Deployment control lanes"]
    AUTHORITY["Encrypted authority storage<br/>deployables / acceptance / Terraform baseline / reports"]
    REPORT["Report-only controls<br/>drift / readiness"]
  end

  ECR --> RUNTIME
  ECR --> RETENTION
  MANIFEST --> RUNTIME
  MANIFEST --> RETENTION
  CONFIG --> PARAM
  NET --> RUNTIME
  CONTROL --> RUNTIME
  CONTROL --> AUTHORITY
  AUTHORITY --> CONTROL
  AUTHORITY --> RETENTION
  AUTHORITY --> REPORT
  REPORT --> AUTHORITY
  PARAM --> RUNTIME
  GATE --> RUNTIME
  RUNTIME --> DATA
  RUNTIME --> SEM
  SEM --> RUNTIME
  RUNTIME --> ARTIFACTS
  RUNTIME --> OBS
  RUNTIME --> RETENTION
  REPORT -. "refresh-only inspection" .-> RUNTIME
  CONTROL --> OBS
  RUNTIME --> OUT

canonical runtime component name と legacy/historical name の対応は次のとおりです。legacy 名は historical context としてのみ扱います。

現行アーキテクチャの責務分離

現行構成は、一つの hosting/backend lifecycle にすべての責務を集約しません。 短い user-facing Web/API request と数分規模の proof work を分ける理由は 非同期プローバー > 実行リソースと mode 境界、 runtime、前提 resource、deployment control を Terraform root ごとに分ける理由は Terraform > Root ownership が現在の参照先です。

この分離により、proof capacity や image authority の変更を API request lifecycle から切り離し、IaC の plan、権限、review、rollback 判断を change lifecycle ごとに 限定できます。過去の Amplify / AppSync / Next.js 構成や手動 handoff は現行 runtime contract ではありません。

関連する章

• トポロジー：リクエスト経路とコンポーネント間の通信フロー
• 非同期プローバー：SQS → Step Functions → ECS の実行時フロー
• 可観測性設計：CloudWatch / EventBridge / SNS のシグナルと authority 境界
• Terraform：target app/bootstrap state と runtime wiring