Financial institution

A secure AWS landing zone for a financial institution

Teams moving to the cloud each on their own, with no governance or overall view. In four months, we designed and built an AWS landing zone that enforces the institution’s security rules automatically, and that became the cloud foundation of the whole organisation.

Where they started

AWS accounts were created one by one, each with its root account handed straight to the team and its own payment card. No central organisation, no least privilege, no visibility on costs. For a financial institution, the security posture was untenable.

The challenge

The technology was not the hardest part. Above all, we had to:

  • get everyone aligned: security, identity and application teams, each with their own priorities;
  • take over what existed: bring standalone accounts into the organisation and make applications compliant, with as little downtime as possible.

What we delivered

As AWS architect for the landing zone, we turned the institution’s security requirements into rules that apply automatically:

  • Structure: AWS Organizations, Control Tower and Account Factory, all described in Terraform.
  • Identity: IAM Identity Center connected to the corporate SSO. No more shared root accounts.
  • Guardrails (SCPs and controls): allowed regions and resource types, mandatory KMS encryption, no public resources, mandatory tagging.
  • FinOps: automated cost reports, with an alert when forecasts drift.

Outcome

  • Security: the institution’s posture changed completely.
  • A cloud account is no longer a blank cheque: every new account is born inside a governed framework, with its rules already in place.
  • Scale: the landing zone became the cloud foundation of the whole organisation, and keeps welcoming new services.

Other case studies

  • Video software vendor

    Air-gapped Kubernetes, embedded in trucks

    Context
    No prior experience with container orchestration, and an ambitious goal: Kubernetes clusters embedded in trucks that operate anywhere in the world, from jungle to desert, with no connectivity at all.
    What we did
    A tailor-made, fully air-gapped Kubernetes cluster, deployed through versioned and tested Ansible playbooks, and scaling of the client’s application.
    Outcome
    A self-contained platform that runs without any connection, and that the client still builds on today.
    Read the full case study — Air-gapped Kubernetes, embedded in trucks
  • Healthcare start-up

    On-premise sovereign AI

    Context
    Customer feedback volumes that had become unmanageable, and medical data that must never leave the company.
    What we did
    Open-weight LLMs on custom-orchestrated on-premise hardware, RAG over internal knowledge, and MCP servers built to query business software.
    Outcome
    In production, several hours saved per case, and an MVP delivered at two thirds of the estimated budget.
    Read the full case study — On-premise sovereign AI
  • IT service provider

    Open-source observability for 1,500 services

    Context
    A proprietary monitoring stack at the end of its rope: no way to group signals or model dependencies, slowness, and around fifteen incidents a day.
    What we did
    A highly available observability platform (OpenTelemetry, Mimir, VictoriaMetrics, Loki, Tempo), service discovery, and custom Prometheus-compatible probes.
    Outcome
    From fifteen incidents a day to one or two a month, and on-call engineers who are hardly ever woken at night.
    Read the full case study — Open-source observability for 1,500 services

Contact

A similar project?

Tell us about your context. We reply within two working days with a first, concrete opinion.

Prefer a direct line?

contact@okko.be