Customer-controlled cloud
DESIGN ONLY
The runtime deploys inside the customer's own account, so evidence and keys never leave their boundary.
No customer deployment has been performed.
Deployment & assurance
One assurance runtime. Your environment.
EcoKure is one assurance runtime with one evidence contract. Where it runs is a deployment decision, not a different product. Evidence, signing keys and decision records stay inside the environment you control, which is also the answer to the supplier-concentration and exit questions a regulated buyer has to satisfy.
Discuss a bounded pilot
Open the buyer handoff pack
See the Control Tower demo
See the evidence register
01AI Control TowerThe product people use
02Governed WorkflowThe workflow you apply it to
03Assurance RuntimeWhere it runs
04Control PackYour rules and reviewers
05EvidencePackThe proof produced
Targets, and what state each one is actually in
Listed with a validation state rather than as five equivalent options. Most vendors would show six logos here. Four of these are not built, and saying so is worth more than the logos.
AWS
TARGET EVIDENCE RECORDED
A reference environment defined entirely in Terraform and applied: VPC with public and private subnets, EC2 with IMDSv2 required, RDS PostgreSQL, an asymmetric KMS signing key, Secrets Manager for the database credential, CloudWatch, and a least-privilege instance role with no access key anywhere.
Target-environment evidence is recorded; this is not production customer validation, certification or a Well-Architected review.
Microsoft Azure
NOT BUILT
Target: AKS with Entra ID, Key Vault and Azure Database for PostgreSQL, sharing the same evidence semantics.
No Azure packaging exists.
Google Cloud
NOT BUILT
Target: GKE or customer infrastructure with Cloud KMS and Cloud SQL, sharing the same evidence semantics.
No GCP packaging exists.
On-premises
DESIGN ONLY
Container or Kubernetes package against a customer's own PostgreSQL and key service.
Not packaged or tested as a supported deployment.
Offline / air-gapped
DESIGN ONLY
Disconnected operation with local signing and offline replay. A differentiator for sovereignty, not a fallback.
No air-gapped deployment has been built or accredited.
The build rule: never fork the assurance semantics per
cloud — fork only the deployment adapter. If an identical signed
decision cannot be replayed across every target, portability is not proven,
and we would rather say that than imply it.
One product story: demo now, runtime validation next
The interactive walkthrough shows the operating model with illustrative records. The AWS reference architecture below is the next environment to validate that same control, signing and evidence path. These are deliberately shown as two linked stages, not as two different products.
Control Tower walkthroughREADY TO EXPLORE
Read-only product flow covering decision stream, human review, change impact and evidence.
Illustrative data only. No customer data or external service calls.
Open the demo →AWS assurance runtimeVALIDATION PENDING
Customer-boundary reference architecture for the same evidence contract and replay semantics.
The environment is not presented as production-ready until benchmark, security and operational validation are complete.
See the reference path →The AWS reference architecture
Written as Terraform and applied. This is the environment a Solutions Architect or a customer’s cloud team would review — every component with the reason it is there, because an architecture list without reasons is a parts bin.
Layer
Component
Why it is there
Network
VPC, public and private subnets, route tables
The runtime and the database sit in private subnets. Nothing that holds evidence is publicly routable.
Compute
EC2 with IMDSv2 REQUIRED
IMDSv1 is the path an SSRF turns into stolen instance credentials. Requiring v2 closes it at the instance rather than in application code.
Database
RDS PostgreSQL, private subnet group, parameter group
The evidence chain is transactional. Interruption behaviour, backup and restore are proven against a real PostgreSQL, not against SQLite.
Signing
KMS asymmetric key (ECDSA P-256)
AWS KMS has no Ed25519 key spec, so the runtime carries both algorithms and dispatches on the one recorded with the key. Historical evidence stays byte-identical.
Secrets
Secrets Manager, AWS-managed database password
The credential is never written into Terraform state, which is itself a file somebody could read.
Identity
Least-privilege instance role, no access key
There is no long-lived credential on the instance to steal.
Observability
CloudWatch log group and agent
Structured verification logs and instance metrics, so a benchmark can be attributed to a machine state rather than asserted.
AWS target-representative proof
Measured run 2026-08-27 · ap-southeast-2 · TARGETREP_AWS_20260827
The same assurance path has now been exercised on the AWS reference environment: signed verification, PostgreSQL persistence, controlled recovery and clean teardown.
117,290verifications
0performance errors
14.29 msp50 latency
19.47 msp95 latency
128.1soak verifications/sec
51.5 secrecovery
KMS: ECC_NIST_P256 with independent public-key verification · Store: RDS PostgreSQL · Loss: 0
Open machine-readable result →Boundary: Target-environment evidence, not production customer validation, certification, or a Well-Architected review. Cost signal: US$0.00001515 per modeled assurance transaction, not a production quote.
What remains before production deployment
The AWS run closes the measurement gap. These are the next gates for a customer-controlled production reference, kept visible so a benchmark is not mistaken for operational readiness.
Resilience and recovery
Move from single-AZ reference evidence to customer-approved multi-AZ design, backup/restore objectives and repeated recovery drills.
Operational ownership
Define staging, on-call ownership, alert thresholds, incident response, change approval and release rollback.
Security assurance
Complete threat modelling, dependency/SBOM review, penetration testing and customer IAM/network review.
Customer validation
Run one bounded pilot in the customer boundary, with their controls, data boundary, reviewers and written go/no-go criteria.
The same runtime on Azure and Google Cloud
Only the infrastructure boundary changes. The assurance semantics — the verdict contract, the signed chain, replay — are identical everywhere, or portability is not real.
| Portable layer | AWS | Microsoft Azure | Google Cloud | Customer / offline |
|---|---|---|---|---|
| Runtime artifact | OCI container on EC2, ECS or EKS | AKS or Container Apps | GKE or customer infrastructure | Docker or Kubernetes, disconnected |
| Transactional store | RDS PostgreSQL | Azure Database for PostgreSQL | Cloud SQL for PostgreSQL | Customer PostgreSQL |
| Signing key | KMS asymmetric, or CloudHSM | Key Vault or Managed HSM | Cloud KMS or Cloud HSM | PKCS#11 / local HSM |
| Evidence objects | S3 | Blob Storage | Cloud Storage | Customer object store |
| Identity | IAM + enterprise OIDC | Entra ID | Cloud Identity / OIDC | Customer directory |
| Observability | CloudWatch + OpenTelemetry | Azure Monitor + OpenTelemetry | Cloud Monitoring + OpenTelemetry | Customer SIEM |
| Evidence semantics | Identical. Same signed decision record, same chain construction, same replay. This row is the product. | |||
Build rule: never fork the assurance semantics per cloud
— fork only the deployment adapter. Azure and Google Cloud are mapped
above and not built. Showing four logos as though they were four
products would be this site’s first unevidenced claim.
What a Solutions Architect asks first
Answered here rather than in a meeting, including the answers that are “not yet”.
What is the workload shape?
Short, CPU-bound deterministic checks plus a signing operation and an append to a transactional store. No GPU. No model inference. The runtime carries 11 dependencies.
Where does customer data live?
Inside the customer’s account. The evidence store holds an input digest, not the input, so customer content does not enter it at all.
How is tenancy separated?
Tenant identity is resolved from the authenticated credential and never from a request field. Evidence attribution lives in a private index rather than on the published chain. Tested adversarially.
What is the failure mode?
Fail-closed by default: if the evidence store is unavailable, a strict deployment refuses rather than returning a verdict that looks attested and is not.
What does it cost per transaction?
Measured as a target-environment signal. The recorded modeled cost is US$0.00001515 per assurance transaction, excluding tax, support plans, free-tier credits, reserved pricing and shared-account costs. It is not a production price or customer quote.
Is it production-ready on AWS?
Not yet. The target-representative benchmark has passed, but this does not establish production customer validation, a Well-Architected review, a Foundational Technical Review or a marketplace listing.
What portability has to mean to count
Three properties. Two hold today and are checkable; the third is the one that needs a real deployment to prove.
- The evidence contract does not change. The same signed decision record, the same hash chain, the same replay semantics on every target.
- Verification needs nothing from us. An evidence pack is checkable with a standalone verifier that contains no EcoKure code, runs offline, and keeps working if EcoKure does not. That is what makes an exit plan real rather than contractual.
- An identical decision replays across targets. Proven for software upgrades. Not proven across clouds, because only one target has a written reference architecture and none has been applied.