Skip to main content
Sukhdev Vyash

Selected work

Enterprise projects

Five platform engagements, described as architecture and outcomes rather than case studies.

All of this was delivered for enterprise clients under commercial confidentiality, so no organisation is named. Clients are identified by sector only, and the detail here covers design decisions and trade-offs rather than anything specific to a client's environment.

01

Enterprise AI

Enterprise AI Platform on Azure AI Foundry

Enabled safe, production-grade generative AI adoption across an enterprise estate.

Governance
Content filtering and responsible-AI controls enforced platform-wide
Cost control
Per-workload token budgets with chargeback visibility
Strategic impact
Became the technical foundation for the AIOps initiative
Enterprise AI platform request pathConsuming applications authenticate with Entra ID workload identities and call a managed gateway. The gateway applies quotas, content filtering and responsible-AI policy, then forwards requests over Private Link to Azure AI Foundry, which serves Azure OpenAI models and a retrieval index with document-level access trimming. Secrets are held in Key Vault. Every request emits token, latency and guardrail telemetry to Azure Monitor, which feeds both cost chargeback and audit reporting.Private Link — no public egressApplicationsEntra ID identityManaged gatewayToken quotasContent filteringResponsible-AI policyAzure AI FoundryAzure OpenAI modelsRetrieval indexAccess-trimmedKeyVaultAzure Monitor — tokens, latency, guardrail interventionsFeeds cost chargeback and audit reporting
Enterprise AI platform request path

Context

Generative AI had arrived in the organisation the way it arrived nearly everywhere: from the bottom up. Individual teams were calling model endpoints directly with their own keys, prototypes were being demoed to clients, and the momentum was genuine. So was the exposure.

Three problems sat underneath it. Prompts containing client data were leaving controlled networks. Spend was invisible until the invoice arrived, with no way to attribute it to a team or a workload. And nobody could answer the question a regulated client’s risk function asks first: what prevents this system from producing something harmful, and how would you know if it had?

The brief was not to slow any of it down. It was to make the governed path the path of least resistance, so that using the platform was easier than going around it.

Architecture

Azure AI Foundry became the control plane for model access, with everything reaching it through a managed gateway rather than talking to model endpoints directly. That single decision is what made the rest enforceable.

Consuming applications authenticate with Entra ID workload identities. No application holds a model key; the gateway brokers access, and secrets live in Key Vault with rotation handled by the platform rather than by each team. All traffic between application subnets, the gateway, and Foundry runs over Private Link, so prompt and completion payloads never traverse the public internet.

Content filtering and responsible-AI controls are applied at the platform layer as policy, not left to application configuration. A team cannot ship a workload that quietly opts out, because the opt-out is not reachable from where they deploy. Retrieval-augmented generation is served from indexed enterprise content with document-level access trimming, so a user’s results respect the permissions they already have rather than flattening them at the point of retrieval.

Every request emits a structured telemetry record to Azure Monitor: the consuming workload, the model, token counts in and out, latency, and whether a guardrail intervened. That record is what makes both the cost story and the audit story possible.

The whole environment is defined in Terraform and deployed through the same pipelines as the rest of the estate. Adding a workload is a pull request, not a ticket.

Key decisions

A gateway rather than direct endpoint access. Direct access is faster to stand up and impossible to govern afterwards. Putting the gateway in from the start meant quotas, filtering, and telemetry were properties of the platform rather than things each team had to remember.

Guardrails as policy rather than documentation. Written standards describe intent; policy enforces it. Controls that teams could disable would eventually be disabled, usually under deadline pressure.

Token budgets as a first-class primitive. Each workload has a budget with alerting before it becomes an overspend. Cost became an engineering signal available at design time, not a finance surprise a month later.

Retrieval before fine-tuning. Grounding answers in current enterprise content solved most real use cases without creating the model-lifecycle and data-residency obligations that fine-tuning brings.

Outcome

The platform moved generative AI from something the organisation was doing cautiously into something it could put in front of regulated clients, with guardrails, content filtering, and responsible-AI controls enforced centrally and cost attributable per workload.

It also became the technical foundation for the wider AIOps initiative. Because access, telemetry, and cost controls were already solved, later agentic and multi-agent work started from a governed baseline rather than rebuilding the same controls a second time.

02

Cloud Governance

Azure Enterprise Scale Landing Zones & Multi-Cloud Governance

Compliance guardrails spanning NIST, HIPAA, and PCI-DSS across two clouds.

Compliance
NIST, HIPAA, and PCI-DSS guardrails codified as policy
Provisioning
Subscription and account vending reduced to a repeatable pipeline
Consistency
One governance model applied across Azure and AWS
Management group hierarchy and policy inheritanceA tenant root management group holds policy initiatives covering NIST, HIPAA and PCI-DSS. Beneath it, a platform branch contains identity, connectivity and management subscriptions, while a landing zones branch splits into production, non-production and sandbox. Workload subscriptions sit inside those branches and inherit whichever policies apply at their scope. A parallel AWS Organizations structure mirrors the same hierarchy using organisational units and service control policies. Both are provisioned by one Terraform vending pipeline.Tenant root management groupNIST · HIPAA · PCI-DSS initiativesPlatformIdentityConnectMgmtLanding zonesProdNon-prodSandboxMirrored in AWSOrganizations OUsService control policiesControl Tower vendingTerraform vending pipeline — Checkov scanned pre-mergeProduces correctly placed, correctly configured subscriptions and accounts
Management group hierarchy and policy inheritance

Context

Regulated clients arrived with cloud estates that had grown organically. Subscriptions had been created ad hoc, naming was inconsistent, network topology differed per team, and controls existed as written standards that someone was supposed to apply. When an auditor asked how a control was enforced, the honest answer was usually “by convention”.

That is workable at ten subscriptions and untenable at a hundred. The specific pain was not a lack of intent, it was the absence of a place to put intent so that it applied automatically. Every new workload became a negotiation, and every negotiation was an opportunity to drift.

The goal was a baseline that a team could land on and inherit correctness, across both Azure and AWS, without the platform team reviewing each request by hand.

Architecture

The Azure side follows Cloud Adoption Framework enterprise-scale patterns. A management group hierarchy separates platform subscriptions (identity, connectivity, management) from landing zones for workloads, with distinct branches for production, non-production, and sandbox. Placement in the hierarchy determines what a subscription inherits, so governance is a property of where a workload sits rather than something configured inside it.

Azure Policy carries the controls. Initiatives are assigned at the management group level and grouped by the obligation they serve, so a control traces to the requirement it satisfies. Policies deny outright what must never exist, such as public blob access or unencrypted storage, and audit or remediate where enforcement would break legitimate work. Deploy-if-not-exists handles the baseline that should always be present: diagnostic settings pointed at central logging, backup configuration, required tags.

Networking follows a hub-and-spoke topology with the hub in a platform subscription. Workload spokes peer to it, egress is centralised and inspected, and private endpoints are the default path to PaaS services.

The AWS estate mirrors the intent with native equivalents: Organizations with an OU structure matching the Azure hierarchy, Control Tower for account vending, service control policies for the deny-list, and centralised CloudTrail and Config aggregation.

Everything is Terraform. Policy definitions, hierarchy, network topology, and the vending pipeline live in version control and deploy through Azure DevOps. Checkov runs on every pull request, so misconfiguration is caught before it reaches a cloud API.

Key decisions

Deny the small set, audit the long tail. A baseline that blocks everything questionable gets exceptions granted until it means nothing. Reserving deny for genuinely non-negotiable controls kept the deny-list credible and short, and pushed everything else into audit with visible drift.

One governance model, two implementations. Rather than a lowest-common-denominator abstraction over both clouds, the model was defined once conceptually and implemented with each provider’s native primitives. Teams get idiomatic tooling; auditors get one map.

Policy-as-code with pre-merge scanning. Controls enforced only at the cloud API produce failed deployments and frustrated engineers. Running Checkov pre-merge moved most of that feedback to the pull request.

Subscription vending as a pipeline, not a ticket. Landing a new workload is a parameterised pipeline run that produces a correctly placed, correctly configured subscription. Removing the human step removed the drift.

Outcome

Governance and compliance guardrails covering NIST, HIPAA, and PCI-DSS are enforced across both clouds rather than documented and hoped for. New workloads inherit the baseline by landing in the right part of the hierarchy, and provisioning is a repeatable pipeline instead of a bespoke exercise.

The durable benefit is auditability. Asking how a control is enforced now has a concrete answer: a policy definition in version control, assigned at a known scope, with compliance state visible per subscription.

03

FinOps

FinOps Cost Optimization Practice

Delivered roughly £100K in annual cloud savings.

Annual savings
~£100K, sustained rather than one-off
Accountability
Showback and chargeback by team and workload
Forecasting
Projections engineering and finance both trusted
Cost attribution and optimisation cycleBilling data from Azure Cost Management and AWS Cost Explorer is normalised into a single cost model. A tagging standard enforced by Azure Policy supplies the owner, environment and cost-centre dimensions that make attribution possible. From the model, two Power BI views are published: an engineering view of spend by workload against budget, and a finance view of spend by cost centre. Findings feed a recurring optimisation cycle covering rightsizing, commitment coverage and waste removal, which changes the estate and therefore the next billing period, closing the loop.Azure Cost MgmtBilling exportAWS Cost ExplorerCURTagging standardOwner · envCost centreUnified cost modelOne schemaBoth providersAttributed spendEngineering viewWorkload vs budgetFinance viewShowback → chargebackRecurring optimisation cycleRightsizing · commitment coverage · waste removalNon-prod scheduled shutdown as a platform defaultEstate changes, so next period's billing data changes
Cost attribution and optimisation cycle

Context

Cloud spend was a monthly surprise. Finance received an invoice, engineering received a question about it, and nobody could reconcile the two because the bill was a single number covering dozens of teams. Cost conversations happened in arrears and in the abstract.

There was no FinOps practice to improve. There was no practice at all. The first task was not optimisation, it was making spend legible enough that optimisation could be argued about with evidence.

Two failure modes needed avoiding. A pure cost-cutting exercise would deliver a one-off saving and then decay as new workloads arrived with the same habits. And a dashboard nobody owned would be admired briefly and then ignored.

Architecture

Attribution came first. Without knowing whose spend it is, every later step is guesswork. A tagging standard covering owner, environment, cost centre, and workload was defined, then enforced through Azure Policy so untagged resources either inherit a default or fail to deploy. Retrospective tagging cleaned up the existing estate.

Cost and usage data from Azure Cost Management and AWS Cost Explorer is consolidated into a single model, normalising the two providers’ different shapes into one schema with consistent dimensions. Power BI sits on top with two distinct audiences in mind: an engineering view showing spend by workload against its budget, and a finance view showing spend by cost centre with month-on-month variance.

Optimisation runs as a recurring cycle rather than a project. Rightsizing recommendations from Advisor and Cost Explorer are triaged into what is safe to apply, what needs a workload owner’s agreement, and what is a false positive given the workload’s pattern. Commitment coverage is reviewed on a schedule, with reservations and savings plans sized against the stable baseline rather than peak usage, leaving burst capacity on demand.

Idle and orphaned resources are the least glamorous and most reliable source of savings: unattached disks, stale snapshots, idle load balancers, non-production environments running through the weekend. Scheduled shutdown for non-production is a platform default rather than an opt-in.

Showback ran first so teams could see their number without immediate financial consequence. Chargeback followed once the data had been challenged and corrected.

Key decisions

Tagging and attribution before optimisation. Optimising an unattributed bill produces savings nobody owns and nobody sustains. Fixing attribution first was slower to show a number and made every later number defensible.

Showback before chargeback. Teams will find the errors in a cost model when they can see it without being billed for it. Running showback first surfaced misattribution early and made chargeback a non-event.

Commitments sized to the baseline, not the peak. Over-committing to reservations trades a discount for lock-in on capacity that may not be needed. Sizing to the stable floor captured most of the discount while keeping room to change direction.

Forecasting as an engineering signal. Publishing projections where engineers already work made cost a design-time input. Architecture decisions started including a cost argument without anyone being asked to make one.

Outcome

The practice delivered roughly £100K in annual savings through rate optimisation, rightsizing, and the removal of waste. The number that mattered more was that it held, because the controls preventing waste were part of the platform rather than a cleanup campaign.

Spend became attributable, forecastable, and owned. Engineering could see the cost of a design before committing to it, and finance could explain the invoice without a translation layer.

04

Platform Engineering

Enterprise Kubernetes Platform (AKS)

Cut deployment cycle times by more than 40% at 99.95% availability.

Deployment speed
40%+ faster release cycles
Availability
99.95% sustained
Scaling
Event-driven autoscaling on queue depth, not just CPU
GitOps delivery across federated AKS clustersA merge to the Git repository holding desired cluster state is reconciled by an in-cluster agent in each AKS cluster, so continuous integration never holds cluster credentials. Clusters are separated by blast-radius boundary rather than consolidated into one. Every cluster is produced from a single Terraform module and receives the same parameterised Helm baseline: ingress, certificate management, policy enforcement, workload identity, and Prometheus and Grafana telemetry. Within each cluster KEDA scales workloads on queue depth and event backlog rather than on CPU alone.GitDesired stateDeploy = mergeProduction clusterReconciliation agentKEDA — queue depthWorkload identityFurther clustersSame baselineSame delivery modelReplaceable, not petsOne Terraform module · parameterised Helm baselineIngress · certificates · policy · secretsPrometheus + Grafana, delivered with the clusterFederated AKS — separated by blast radiusNo clustercredentialsheld in CI
GitOps delivery across federated AKS clusters

Context

Container adoption had outrun the platform underneath it. Clusters had been created per team and per environment, each configured by whoever built it. Ingress worked differently in three places, secrets were handled four ways, and upgrades were deferred because nobody was confident what would break.

Delivery felt slow for reasons that had little to do with the pipeline. Releases waited on manual steps, on someone with cluster access, on knowing which of several similar-looking clusters was the right target. Meanwhile scaling was CPU-based, which suited steady request traffic and handled queue-driven workloads poorly: a backlog would build while CPU sat low and nothing scaled out.

Architecture

Clusters are treated as replaceable infrastructure rather than pets. Every cluster is defined in Terraform from one module, so its node pools, networking, identity integration, and add-ons are consequences of configuration rather than of who built it. Recreating a cluster is a routine operation, which is what makes upgrades unremarkable.

Multiple clusters are federated behind a consistent delivery model rather than consolidated into one. Workloads are distributed across clusters by environment and blast-radius boundary, with a shared baseline every cluster receives: ingress, certificate management, policy enforcement, log and metric shipping, and secret access via workload identity rather than mounted credentials.

Delivery is GitOps. The desired state of every cluster lives in Git, and an in-cluster agent reconciles toward it. Deploying is a merge; the cluster converges on its own. Nobody needs cluster credentials to ship, which removed both a bottleneck and a standing access requirement. Helm charts are shared and parameterised per environment, so environment differences are visible as values rather than buried in divergent manifests.

KEDA handles scaling. Alongside CPU and memory, workloads scale on the signal that actually predicts their load: queue depth, event backlog, or scheduled patterns for known peaks. Queue-driven consumers scale from near zero and back down, which cut idle capacity on workloads that had previously been provisioned for peak around the clock.

Prometheus and Grafana cover observability, with dashboards and alerts delivered as part of the cluster baseline so a new cluster arrives already observable.

Key decisions

Multiple clusters, one delivery model. A single large cluster is cheaper and concentrates failure. Separate clusters per blast-radius boundary kept incidents contained, and standardising delivery across them meant the extra clusters cost operational effort rather than multiplying it.

GitOps over pipeline-push deployment. Pipelines that push into clusters need credentials, and those credentials accumulate. Reconciliation from Git inverted that, removed standing cluster access from CI, and made drift visible as a diff.

Event-driven autoscaling, not just CPU. Scaling on the metric that predicts load rather than a proxy for it fixed both responsiveness under burst and idle cost at rest.

Cluster configuration as one module. The alternative, per-cluster bespoke Terraform, reproduces the original problem more neatly. One module with parameters meant a fix applied everywhere.

Outcome

Deployment cycle times fell by more than 40%, largely by removing the waiting rather than by making any single step faster. Availability held at 99.95% across the estate, helped by contained blast radius and by upgrades becoming routine instead of deferred.

Clusters stopped being individually interesting. Adding one is a module invocation, and it arrives with the same ingress, policy, observability, and delivery behaviour as every other.

05

Security

Zero Trust Security Architecture

Replaced perimeter assumptions with verified identity and least privilege.

Identity
Conditional access and time-bound privileged elevation
Segmentation
Micro-segmented boundaries between workloads
Posture
Continuous compliance monitoring and drift detection
Identity-centred access path and workload segmentationEvery access request from a user or workload is evaluated by Entra ID conditional access against device compliance, sign-in risk, location and target sensitivity, then allowed, challenged or blocked. Legacy authentication protocols that cannot participate are blocked outright. Administrative roles are eligible rather than active, with elevation requested through Privileged Identity Management, time-bound, justified and logged. Beyond identity, each workload sits in its own micro-segmented boundary that defaults to deny, egress is centrally inspected through Azure Firewall, and PaaS access runs over Private Link so public endpoints stay disabled. Defender for Cloud continuously assesses posture while Azure Policy prevents the misconfiguration that should never deploy.UsersWorkloadsScoped identityConditional accessDevice complianceSign-in riskLocationTarget sensitivityAllow · challenge· blockPIM elevationEligible, not activeTime-bound · loggedLegacy authprotocolsBlockedMicro-segmented — default denyWorkload AOwn boundaryWorkload BOwn boundaryPrivate Link to PaaSPublic endpoints disabledAzure FirewallInspected egressAzure Policy prevents · Defender for Cloud detectsFindings routed to the team that owns the resource
Identity-centred access path and workload segmentation

Context

The security model assumed a network perimeter that no longer described how anyone worked. Being on the corporate network conferred trust; being off it meant a VPN that granted broad access once connected. Administrative rights were standing rather than requested, held by people who needed them occasionally and retained them permanently.

Inside the cloud estate, segmentation was coarse. Workloads shared flat network space, so a compromise in a low-value system had a wide path to explore. None of this reflected negligence; it reflected controls designed for an environment that had since changed around them.

The direction was straightforward to state and harder to land: stop treating network position as evidence of trust, verify explicitly at each access, and grant the least privilege that gets the job done.

Architecture

Identity became the control plane. Entra ID conditional access evaluates each authentication against device compliance, user and sign-in risk, location, and the sensitivity of the target, then decides whether to allow, challenge, or block. Phishing-resistant multi-factor authentication is required for administrative access, and legacy authentication protocols that cannot support these checks are blocked outright rather than tolerated.

Standing privilege was removed. Privileged Identity Management makes administrative roles eligible rather than active: elevation is requested, justified, time-bound, and logged, and it expires automatically. Access reviews run on a schedule so entitlements that were once justified do not persist unexamined. Applications and pipelines use workload identities with scoped permissions instead of shared service accounts.

Network controls moved from perimeter to segment. Each workload sits in its own boundary with explicit rules for what may cross it, defaulting to deny. Egress is centralised and inspected through Azure Firewall. Access to PaaS services runs over Private Link, so data-plane traffic stays on the private network and public endpoints can be disabled rather than merely firewalled.

Defender for Cloud provides continuous posture assessment, with findings routed to the teams that own the resources rather than into a central queue. Azure Policy enforces the preventable controls so posture management handles genuine findings instead of configuration that should never have deployed.

All of it is Terraform, which matters here more than elsewhere: security configuration that drifts silently is worse than no configuration, because it is trusted.

Key decisions

Identity as the primary boundary. Network controls remain necessary but insufficient. Making identity the point of evaluation meant access decisions accounted for who, what device, and what risk rather than only where.

Eligible rather than standing privilege. The simplest way to reduce the impact of a compromised administrative account is for there to be no permanently active administrative accounts. Time-bound elevation cost a few seconds per use and removed a standing target.

Block legacy authentication rather than monitor it. Protocols that cannot participate in conditional access are an exemption from the entire model. Blocking them required migration work and closed the bypass properly.

Prevent with policy, detect with posture management. Sending preventable misconfiguration to a detection tool generates findings instead of outcomes. Policy denies what should never exist so that posture findings are worth reading.

Outcome

Conditional access, identity governance, and micro-segmentation are in force across the enterprise cloud environments, with privileged access time-bound and audited rather than permanently held. Compliance state is continuously monitored, and the controls are version-controlled so drift is visible.

The practical difference is blast radius. A compromised credential now yields narrow, conditional, time-limited access rather than a position from which to move laterally.

Want the detail behind any of these?

Happy to walk through the architecture and the decisions in more depth.

Get in touch