Skip to main content

How Techpartner Alliance delivered the governed AWS foundation, DevSecOps pipeline and managed operations behind an AI platform that observes, proves compliance and optimises spend across multi-cloud and on-premise estates.

CUSTOMER   OpsVision

INDUSTRY   Technology / Cloud Governance SaaS

PARTNER ROLE   Infrastructure, DevSecOps and Managed Services Partner

KEY SERVICES   AWS Landing Zone · Amazon Bedrock · ECS/EKS · Terraform · CI/CD (OIDC) · Managed Ops · FinOps · Compliance Hardening

Customer Overview

OpsVision is an AI-native cloud governance platform that unifies three capabilities enterprises normally buy as three separate products: continuous observability, continuous compliance evidence, and cost optimisation. It connects to AWS, Azure, Google Cloud, Kubernetes, vSphere and OpenStack through least-privilege, read-only connections, scans those estates continuously, reasons over the results using generative AI, and proposes change-safe remediations that a human approves before anything is modified.

The product is deliberately agent-less from the customer’s perspective — nothing is installed inside the customer estate, and all connector traffic is outbound only. It is offered both as a managed SaaS service and as a self-hosted deployment for data-residency-sensitive and regulated buyers. That dual posture, combined with a compliance model that distinguishes machine-verified evidence from estimated or manually-attested evidence, is the platform’s core commercial differentiator.

Techpartner Alliance, an AWS Premier Consulting Partner, is OpsVision’s infrastructure and DevSecOps partner — responsible for the governed AWS foundation the platform runs on, the delivery pipeline that ships it, the security and compliance hardening a governance product is expected to demonstrate itself, and the ongoing managed operations and cost governance of the production estate.

The Challenge

Building a generative AI platform that enterprises will trust with their cloud estate imposes a harder set of constraints than building a conventional SaaS product. OpsVision faced the following:

  • Credibility burden — The product’s entire value proposition is governance and audit-readiness, so the platform’s own AWS estate had to be demonstrably better governed than the estates it inspects — a weak posture would be disqualifying in front of a sceptical CISO or auditor.
  • Data boundary for AI — Customer resource data has to reach a large language model for reasoning, but bucket contents, secret values, database rows and personal data must never leave the platform boundary. A contractual assurance from a model provider was not considered sufficient control.
  • Unpredictable inference economics — Generative AI cost is a variable, per-call cost that scales with customer estate size. Without per-call metering the unit economics of the product would be unknowable, and gross margin unforecastable.
  • Explainability and audit trail — Every AI conclusion and every AI-proposed action had to be reconstructable after the fact — what the model was asked, what it answered, what it cost — because the platform sells explainability as a feature.
  • Human-in-the-loop by construction — Any action that mutates a customer cloud resource needed a dry-run, an approval gate and an immutable log, which meant the write path had to be architecturally separated from the read path.
  • Dual deployment model — The same codebase had to run unchanged as multi-tenant SaaS on AWS and as a customer-hosted deployment, including for customers with no-egress requirements.
  • Small team, enterprise expectations — A founder-led engineering team could not also carry 24×7 platform operations, patching, backup, DR and cost governance without losing product velocity.

The Solution

Techpartner Alliance designed and delivered the AWS foundation and operating model beneath the platform, while OpsVision’s team built the product and its AI reasoning layer on top. The engagement covered four workstreams:

  • Landing zone and account governance — A multi-account AWS organisation with separated management, security-tooling and workload accounts under a governed landing zone, service control policy guardrails, and federated human access through IAM Identity Center rather than static keys.
  • DevSecOps delivery pipeline — Infrastructure as code in Terraform, container build and deployment onto AWS container services, and CI/CD pipelines that reach AWS through short-lived OIDC-federated credentials — no long-lived deployment keys anywhere in the pipeline.
  • Generative AI on Amazon Bedrock — Amazon Bedrock adopted as the inference path for Claude models, so that generative AI calls stay inside the AWS account boundary, are governed by the same IAM and logging controls as the rest of the estate, and inherit the region and data-residency posture the platform promises its customers.
  • Security and compliance hardening — WAF, GuardDuty and Security Hub coverage, KMS-managed encryption at rest across database, cache, object storage and secrets, scheduled secret rotation, and organisation-wide guardrails that prevent the audit trail itself from being disabled or deleted.
  • Scalable, multi-AZ runtime — Stateless, horizontally scalable web, API and worker tiers spread across availability zones, queue-depth-driven autoscaling for scan workers, and a serverless auto-scaling relational tier that contracts toward near-zero when idle.
  • Managed operations — 24×7 monitoring, patching, backup and disaster-recovery routines, and incident response for the production estate, run by Techpartner’s DevOps pods so the product team stays on product.
  • FinOps and cost governance — Continuous rightsizing and spend governance on the OpsVision production estate, applying to the platform the same cost discipline the platform sells.

Generative AI Architecture

Generative AI in OpsVision is not a chat feature bolted onto a dashboard. It is the reasoning layer of the product, and it was designed under three non-negotiable constraints: redact before you infer, meter every call, and never mutate without approval.

The infrastructure view of that design is shown in Figure 1 overleaf.

FIGURE 1 — INFRASTRUCTURE ARCHITECTURE

Governed AWS landing zone, agent-less read-only connectors, the redaction boundary in front of Amazon Bedrock, and the human-in-the-loop approval gate on the write path.

 

Generative AI Architecture (continued)

Four AI agent roles

The platform runs four distinct generative AI agent roles, each with its own prompt contract, its own model tier and its own output schema:

  • Classification and anomaly detection — interprets raw connector output and scores findings — misconfigurations, deviations, cost anomalies — into a consistent severity and confidence model.
  • Compliance reasoning — maps observed configuration state to control requirements across CIS Benchmarks, ISO/IEC 27001:2022, SOC 2 Type II, PCI DSS 4.0, GDPR, NIST CSF and DPDP India, and explains why a control is met, gapped or unverifiable.
  • Remediation planning — produces the step-by-step fix behind a finding, with the signals that produced the verdict, an effort estimate, and a rollback path — surfaced to the user in the Investigate drawer.
  • Report writing — generates long-form executive summaries, weekly snapshots, compliance reports and cost narratives, streamed to the console so the experience stays responsive.

Cost-tiered model routing on Amazon Bedrock

The overwhelming majority of calls are high-volume classification and scoring, and these are routed to the smallest, fastest model tier. More capable tiers are reserved for genuinely agentic reasoning and for the comparatively rare task of writing long-form reports. Prompt caching and response caching reduce both latency and the marginal cost of scaling the intelligence layer. Because the routing policy is configuration rather than code, a role can be moved between tiers once real usage evidence exists — which is how the platform keeps inference cost proportionate to the value of each call rather than to estate size alone.

The redaction boundary

A redaction layer sits physically between connector output and the AI engine. Resource identifiers, account numbers and region names are shared with the model because they are required for reasoning; bucket contents, secret values, database rows and personal data are not. Because the layer sits inside the platform network boundary and every crossing is recorded, the boundary is auditable rather than merely asserted — it is a technical control that holds independently of any contractual commitment from a model provider.

Metering and explainability

Every model invocation writes a first-class Agent Run record capturing the model used, input and output token counts, cache hits, latency, agent type, result and the full raw response. This single design decision does three jobs at once: it makes the unit economics of the product measurable rather than assumed, it gives the customer and their auditor the ability to reconstruct exactly what the AI was asked and what it answered for any action ever taken, and it gives Techpartner’s FinOps practice a real cost signal to govern against.

Human-in-the-loop execution

Read and write paths are architecturally separate. The default permission shape on every cloud connection is strictly read-only; customers grant narrowly scoped write permissions only for the remediation classes they explicitly allow. Any action that would change a cloud resource enters an approval inbox as a pending item with its proposed change and a dry-run plan. Low-risk classes the customer has pre-approved can execute automatically; high-risk actions require a typed confirmation phrase. Every call to a provider API is logged for audit.

Conversational Copilot (in development)

An AI Copilot is in active development — a natural-language interface to the customer’s entire estate rather than a help widget. It is designed to translate plain-language questions into structured CloudTrail queries, correlate events across CloudTrail, CloudWatch and Security Hub in a single trace, and propose remediation that flows through the same approval gate as every other AI-proposed action, with conversational memory carried across sessions. It is described here as roadmap, not as shipped capability.

AWS Services Used

LayerServices
Generative AIAmazon Bedrock (Anthropic Claude model family, cost-tiered by agent role)
GovernanceAWS Organizations, Control Tower–style landing zone, Service Control Policies, IAM Identity Center
ComputeContainerised web, API and worker tiers across multiple Availability Zones
DataManaged multi-AZ PostgreSQL with auto-scaling capacity, managed Redis, S3 object storage
SecurityAWS WAF, GuardDuty, Security Hub, KMS, Secrets Manager, CloudTrail (guardrail-protected)
DeliveryCI/CD with OIDC short-lived federated credentials, container registry, Terraform-managed infrastructure
CostCost Explorer and budget controls feeding the FinOps governance cadence

Third-Party Tools Integrated

  • Terraform — Every account, network, security and platform resource is declared as code and promoted through environments, so the production estate is reproducible and reviewable.
  • Grafana / Prometheus — Platform-side metrics, dashboards and alerting for the OpsVision production estate itself, separate from the customer-facing observability the product provides.
  • Slack and Jira — Alert and approval notifications routed to the operating team, and two-way ticket synchronisation for incidents that need engineering action.
  • Next.js, Django and Celery — The application stack — Next.js and TypeScript on the front end, Django and Django REST Framework on the back end, Celery and Redis for asynchronous scan processing.

DevOps Approach

Automation

Nothing reaches production by hand. Infrastructure is defined in Terraform and promoted through environments; application containers are built, scanned and deployed by pipeline; scans inside the product are scheduled through a queue-based scheduler rather than long-running requests, so a scan of a large estate decomposes into parallel units of work rather than one fragile job. The result is that capacity is added by adding stateless workers, and a failed run is re-runnable from its record alone.

Security

The security model assumes the platform will be evaluated by exactly the kind of auditor it is built to serve. No long-lived customer credentials are stored: AWS access is a cross-account read-only role assumed with a per-customer external identifier and short-lived session tokens, Azure uses a read-only service principal, and Google Cloud is accessed through workload identity federation. Deployment credentials are equally short-lived and federated. Encryption is applied in transit and at rest across every store, with customer-managed keys available in self-hosted deployments. Organisation-wide guardrails prevent the audit trail from being disabled or deleted — including by the platform’s own operators.

Scaling and resilience

Web, API, worker and scheduler tiers are stateless and horizontally scalable, spread across availability zones, with autoscaling driven by processor load and by queue depth. The relational tier uses a serverless auto-scaling configuration that expands within minutes under load and contracts toward near-zero when idle, which keeps the idle cost of a multi-tenant platform low. The first phase of the hosting environment is complete and operating; multi-region disaster recovery is designed and scheduled rather than yet implemented — a distinction the team states deliberately rather than papering over.

Cost governance

Because every AI call is metered and every infrastructure component is tagged and tracked, cost governance is a data exercise rather than a monthly surprise. Techpartner’s FinOps cadence covers rightsizing of the compute and data tiers, idle-capacity reclamation, and review of the AI model-routing policy against actual per-role token consumption — the single largest variable-cost lever in a generative AI product.

Business and Technical Impact

  • AI inference kept inside the governed boundary — Generative AI inference runs inside the AWS account boundary through Amazon Bedrock, under the same IAM, logging and residency controls as the rest of the estate — which removes a standing objection in enterprise and regulated-buyer security reviews.
  • Inference economics became measurable — Per-call metering turned generative AI from an unbounded variable cost into a measured, governable line item, making the product’s gross margin forecastable and the model-routing policy tunable against evidence.
  • Explainability is evidenced, not asserted — Every AI conclusion and every AI-proposed action is reconstructable — model, prompt, response, cost and latency — so explainability is demonstrable in an audit rather than claimed in a datasheet.
  • No unattended mutation of customer estates — The read/write separation, dry-run previews, approval inbox and typed confirmation for high-risk actions mean no AI-initiated change reaches a customer resource without a human decision and an audit record.
  • The platform can pass its own audit — A governed multi-account landing zone, federated access, guardrail-protected audit trail and encrypted data stores let a governance product credibly demonstrate the posture it sells.
  • Scale is a capacity decision, not a redesign — Stateless tiers, queue-driven autoscaling and a serverless data tier allow the platform to absorb concurrent multi-tenant scan load by adding capacity rather than by re-architecting.
  • Engineering velocity protected — Managed operations, patching, backup, DR and cost governance are carried by Techpartner’s DevOps pods, keeping a founder-led engineering team on product delivery rather than on platform upkeep.
  • One codebase, two commercial shapes — Because the deployment-mode layer separates configuration from code, the same platform serves managed SaaS and self-hosted or no-egress customers without forking the codebase.

Why Techpartner Alliance

Generative AI products fail enterprise security review for infrastructure reasons far more often than for model reasons — an ungoverned account structure, static credentials in a pipeline, an unbounded data path to a model provider, or an audit trail that the operator can quietly turn off. Techpartner Alliance brought two decades of production AWS experience and a DevOps practice built around BFSI and regulated workloads to exactly those problems, so that OpsVision’s team could spend its effort on the AI reasoning layer and the product, not on rebuilding a governed cloud foundation from first principles.

The engagement continues as a managed partnership: the landing zone and pipeline are operated and evolved, the production estate is monitored and cost-governed, and the security posture is maintained to the standard a compliance product is expected to hold itself to.