Op welke cloud werken jullie?

Platform-onafhankelijk: AWS, Azure, Google Cloud of een andere provider. We kiezen wat past bij je situatie, of bouwen een opzet die met meerdere clouds overweg kan.

Kunnen jullie bestaande workloads migreren?

Ja. We migreren bestaande applicaties en data in golven, met CI/CD-pipelines en een terugvalpad per stap, zodat downtime beperkt en gepland blijft.

Houden jullie de kosten in de hand?

Ja. Kostenbeheersing en FinOps zijn onderdeel van de opzet: kosten per omgeving en team toewijsbaar, budgetbewaking, right-sizing en een maandrapport in heldere taal.

Hoe borgen jullie security in cloudomgevingen?

Security zit ingebakken, niet achteraf: least-privilege toegang, netwerksegmentatie, encryptie van data in rust en onderweg, en centrale logging. Beleid leggen we vast als code en toetsen we automatisch met guardrails.

Werken jullie met multi-cloud of hybride opstellingen?

Beide. Voor multi-cloud stemmen we netwerk, identiteit en tooling op elkaar af. Bij hybride koppelen we je datacenter veilig aan de cloud, met heldere afspraken over connectiviteit en verantwoordelijkheid.

Doen jullie managed Kubernetes en containerbeheer?

Ja, op de cloud-oplossingskant. We richten managed clusters op EKS, AKS of GKE in en beheren ze: netwerkbeleid, identiteit, autoscaling, ingress, back-up, image-scanning en upgrades.

Doen jullie ook applicatieontwikkeling?

Nee. Wij doen de cloud-oplossingskant: fundament, infrastructure as code, migratie, clusters en beheer. Je eigen team of softwareleverancier bouwt de applicatie.

Hoe verlopen onderhoud en beheer na oplevering?

We blijven je cloudomgevingen beheren zolang je dat wilt: patches, monitoring en alerting, back-up en herstel, en periodieke reviews van kosten en security. Omdat alles in code vastligt, voeren we wijzigingen gecontroleerd door.

Cloud engineering · platform-onafhankelijk

Een fundament dat meegroeit.

Proxa bouwt en beheert cloudomgevingen op AWS, Azure en Google Cloud: landing zones, infrastructure as code, migratie en managed Kubernetes. Een omgeving waarvan je weet wat ze doet en wat ze kost, omdat je haar kunt lezen.

Neem contact op Bekijk wat we doen

Gratis kennismaking, daarna een offerte op maat.

laag 01 · governance

laag 02 · fundament

laag 03 · omgevingen

laag 04 · platform

fig. 01 · fundament

Guardrails & beleid

Beleid als code: regels die afwijkingen blokkeren of direct zichtbaar maken, met verplichte tagging en encryptie.

Werkt op AWS Azure Google Cloud of een andere provider

Waarom dit telt

Cloud groeit ongemerkt uit tot een black box

Handmatig opgebouwd werkt het, tot niemand meer durft te wijzigen: onduidelijk wat er draait, wat het kost, en of het veilig en herstelbaar is. Zonder herhaalbaar fundament wordt elke wijziging een gok.

Drie vragen die elke organisatie vroeg of laat stelt. Het verschil zit in hoe snel en hoe zeker het antwoord komt.

vraag 01

Wat draait er, en waarom?

Zonder fundament

Navragen bij wie het ooit heeft gebouwd. Wijzigingen in de console laten geen spoor na.

Met een leesbaar fundament

Lees het na in de repository, inclusief de merge request en de reden van elke wijziging.

vraag 02

Wat kost het, en voor wie?

Zonder fundament

Een totaalbedrag op de factuur dat elke maand hoger uitvalt.

Met een leesbaar fundament

Kosten per omgeving en per team, met budgetalarmen voordat de factuur komt.

vraag 03

Wat als het omvalt?

Zonder fundament

Opnieuw opbouwen is giswerk, en of de back-up werkt weet niemand zeker.

Met een leesbaar fundament

De omgeving komt opnieuw uit code, en herstel is getest met een tijd die je kent.

Wat we doen

Vijf pijlers onder je cloudomgevingen, uitrol én beheer uit een hand

pijler a · 1 van 5

Landing zone & governance

Het fundament: accounts, netwerk, identiteit, toegang en beleid, een keer goed ingericht zodat alles wat erbij komt volgens dezelfde regels landt.

voor de technische lezer

Multi-account of multi-subscription opzet, centrale identiteit, netwerksegmentatie, beleid als code en verplichte tagging en encryptie.

Multi-cloud

Andere namen, hetzelfde fundament

We kiezen het platform dat bij je situatie past, niet wat bij ons certificaat past. Kies een cloud en zie hoe dezelfde lagen daar heten.

accountscheiding

Organizations, OU's

Azure: Management groups, subscriptions · Google Cloud: Organisatie, folders, projecten

identiteit

IAM Identity Center

Azure: Entra ID met PIM · Google Cloud: Cloud Identity, IAM

netwerk

VPC, Transit Gateway

Azure: VNet, Virtual WAN · Google Cloud: VPC, Network Connectivity Center

beleid

Service control policies

Azure: Azure Policy · Google Cloud: Organization policies

kubernetes

EKS

Azure: AKS · Google Cloud: GKE

kosten

Cost Explorer, budgets

Azure: Cost Management · Google Cloud: Billing, budgets

Nog niet zeker welk platform bij je past? Dat zoeken we samen uit.

Neem contact op

Infrastructure as code

Je omgeving is leesbaar: wat er draait, staat in code

Geen verstopte klikpaden. Elke laag van je fundament staat als herleidbare code in een repository. Loop de drie bestanden langs en zie welke laag elk bestand bouwt.

01organisatie/ou.tf Accounts & OU's

locals {
  root_id = aws_organizations_organization.this.roots[0].id
}

resource "aws_organizations_organizational_unit" "wl" {
  name      = "workloads"
  parent_id = local.root_id
}

resource "aws_organizations_account" "prod" {
  name      = "proxa-prod"
  email     = "aws+prod@example.nl"
  parent_id = aws_organizations_organizational_unit.wl.id
}

02netwerk/main.tf Netwerk

module "network" {
  source = "../modules/network"

  name            = "prod"
  cidr_block      = "10.20.0.0/16"
  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.20.0.0/20", "10.20.16.0/20", "10.20.32.0/20"]
  nat_per_az      = true

  tags = {
    environment = "prod"
    managed_by  = "terraform"
  }
}

03guardrails/policy.tf Guardrails & beleid

resource "aws_organizations_policy" "eu_only" {
  name    = "deny-regions-outside-eu"
  type    = "SERVICE_CONTROL_POLICY"
  content = data.aws_iam_policy_document.eu_only.json
}

resource "aws_organizations_policy_attachment" "wl" {
  policy_id = aws_organizations_policy.eu_only.id
  target_id = aws_organizations_organizational_unit.wl.id
}

stap 1 van 3

Accounts & OU's

Netwerk

Guardrails & beleid

fig. 02 · van code naar infra · Accounts & OU's

Deze resources bepalen de scheiding van je omgeving: een aparte organisatie-eenheid voor workloads met een productie-account eronder, herleidbaar vastgelegd.

Hoe we werken

Eerst het doel scherp, dan pas uitrollen

We kunnen complete omgevingen op afroep uitrollen, maar doen dat pas als helder is wat erop moet landen.

Oplevering

Wat je bij oplevering in handen hebt

Geen zwarte doos en geen afhankelijkheid van ons geheugen. Wat we bouwen, dragen we over in materiaal dat ook zonder ons leesbaar blijft.

Repository met modules

Alle infrastructuur in Terraform of OpenTofu, met de geschiedenis van elke wijziging erbij.

Architectuurtekening

Een tekening die klopt met wat er draait, plus de keuzes die eraan vooraf gingen.

Toegangsmatrix

Wie kan wat, in welke omgeving, en hoe tijdelijk meer rechten werken.

Runbooks

Korte procedures voor herstel en uitrol, ook om drie uur 's nachts duidelijk.

Kostenoverzicht

Wat elke omgeving kost, en welke knoppen er zijn om dat te veranderen.

Maandrapport

In heldere taal: wat er gebeurde, wat het kostte en wat we aanraden.

Een cloud waarvan je weet wat ze doet, en wat ze kost. Geen black box, maar een leesbaar systeem.

Cloudbeheer

Beheer is een ritme, geen brandje blussen

Dezelfde mensen die het fundament bouwen, houden het daarna bij, zolang je wilt. Maandelijks opzegbaar, geen jaarcontract.

Security & guardrails

Security zit erin, niet eroverheen

Least privilege standaard

Rollen krijgen precies genoeg rechten, beheerrechten zijn tijdelijk en aanvragen laten een spoor achter.

Netwerk gesegmenteerd

Omgevingen staan gescheiden, uitgaand verkeer loopt langs een pad dat je kunt inspecteren.

Versleuteld met beheerde sleutels

Data in rust en onderweg versleuteld, sleutelbeheer en rotatie geregeld in plaats van aangenomen.

Logging centraal en onveranderlijk

Wie wat deed staat vast in een account waar niemand het kan aanpassen.

Herstel dat getest is

Back-up is pas back-up als de restore is uitgevoerd, met een tijd die je kent.

We leveren de technische onderbouwing voor audits, AVG-vragen of een NIS2-traject: wie had toegang, wat is versleuteld, wat is gelogd, hoe snel is herstel. Certificeren doen we niet zelf, dat hoort bij een auditor.

Waar we op sturen

Drie situaties die we vaak tegenkomen

Proxa is jong en publiceert geen cijfers die we niet kunnen laten zien. Dit zijn de verifieerbare uitkomsten waar een traject op wordt ingericht.

Scale-up zonder herhaalbare omgeving

01 · situatie

De cloud is handmatig gegroeid en werkt, maar niemand durft nog iets te wijzigen. Kennis zit bij een persoon.

02 · aanpak

Landing zone opnieuw opzetten in code, guardrails erop, CI/CD voor elke wijziging en de bestaande workloads erin trekken.

03 · waar we op sturen

Elke wijziging herleidbaar en herhaalbaar, en de omgeving is opnieuw op te bouwen zonder verrassingen.

Waarom proxa

Vakmanschap dat je kunt nalezen

Platform-onafhankelijk

AWS, Azure, Google Cloud of een combinatie. We kiezen wat bij je situatie past.

Alles in code

Wat er staat, staat in de repository, inclusief de reden van elke wijziging.

Uitrol en beheer uit een hand

Geen overdracht naar een partij die het fundament niet kent.

Kubernetes als cloud-vraagstuk

Wij doen netwerk, security, schaling en beheer van clusters. Je team bouwt de software.

Hoe de samenwerking eruitziet

Vooraf helder wie waarvoor staat. Wij doen de cloud-kant, jouw team houdt de regie over de applicatie en de data.

Proxa Samen Jouw team

Landing zone, netwerk en identiteit

Infrastructure as code en CI/CD

Migratie, clusters en doorlopend beheer

Doel, scope en architectuurkeuzes

Migratievensters en de afweging kosten, snelheid, beschikbaarheid

De applicatie en functionele keuzes

Eigenaarschap van data

Vragen over cloud

Cloudomgevingen, van fundament tot beheer

Staat je vraag er niet bij? Stel hem via het contactformulier.

Wat is een landing zone?

Een landing zone is de veilige, goed ingerichte basis van je cloudomgeving: accounts, netwerk, identiteit, toegang en beleid, klaar om workloads op te draaien. Je richt hem een keer goed in, daarna landt alles wat erbij komt volgens dezelfde regels.

Waarom infrastructure as code?

Omdat je omgeving dan reproduceerbaar, versioneerbaar en controleerbaar is. Wijzigingen zijn herleidbaar tot een merge request en je kunt alles opnieuw opbouwen zonder verrassingen.

Welke tools gebruiken jullie voor infrastructure as code?

Doorgaans Terraform of OpenTofu, aangevuld met cloud-eigen diensten waar dat beter past. Modules zijn herbruikbaar en versioneerbaar en draaien in CI/CD-pipelines, zodat iedere wijziging getoetst en herleidbaar wordt uitgerold.

Hoe lang duurt het opzetten van een landing zone?

Een lichte, single-account opzet staat doorgaans binnen enkele dagen. Een multi-account landing zone met netwerk, identiteit, guardrails en CI/CD kost meestal enkele weken. Na een kennismaking noemen we een concrete doorlooptijd.

Termen, kort uitgelegd

De ingerichte basis van je cloud: accounts, netwerk, identiteit, toegang en beleid, klaar om workloads op te draaien.

Begin bij het fundament

Een gratis kennismaking, daarna een plan op maat

We krijgen eerst je doel scherp: wat er moet landen en wat er nu staat. Daarna een offerte op maat. Geen traject dat je niet kunt stoppen.

01Wat moet erop landenWelke applicaties, hoeveel omgevingen, wat er over een jaar bij komt.

02Welke eisen geldenBeschikbaarheid, hersteltijd, waar data mag staan, wie toegang heeft.

03Wat er nu staatWat er draait, wie het beheert en wat er misgaat. Ook als dat rommelig is.

Bedankt, we hebben je bericht.

We reageren binnen twee werkdagen met een voorstel voor een kennismaking.