Eén VPC voor alles of een VPC per app, wat is verstandig?
Voor de meeste MKB's is één VPC per omgeving (prod, staging) genoeg, met aparte subnets per app of tier. Meer VPC's betekent meer peering, meer NAT, meer kosten.
support/cloud-platforms/vpc-design-een-vpc-vs-meerderestappen: 5
Probeer dit eerst zelf
- Begin met één VPC per omgeving en /16 CIDR die ruim genoeg is om in 5 jaar niet vol te lopen, bijvoorbeeld 10.0.0.0/16 voor prod en 10.1.0.0/16 voor staging.
- Splits per AZ in een public en private subnet, en zet alle workloads in private. Public is alleen voor load-balancers en NAT-gateways.
- Gebruik aparte subnets of security-groups per app, niet aparte VPC's. Dat houdt routing simpel en NAT-kosten laag.
- Een aparte VPC pas overwegen als de app een ander security-profiel heeft (bijvoorbeeld klant-tenant-isolatie, betalingsverkeer, of compliance-scope).
- Documenteer je CIDR-plan in een tabel die je deelt, anders krijg je collisions zodra iemand on-prem of een andere cloud wil koppelen.
Wanneer ons inschakelen
Wil je multi-tenant SaaS bouwen waar elke klant netwerk-isolatie nodig heeft, dan is het ontwerp wezenlijk anders. Even meekijken loont voordat je vastloopt.
Zie ook
- Iedereen logt in met het root-account van AWSHet root-account is voor noodgevallen en facturatie. Dagelijks werk hoort via IAM-users of SSO.
- Iedere developer heeft AdministratorAccessAdministratorAccess overal is gemak nu, drama later. Begin met rolgebaseerde policies.
- Iedereen heeft losse IAM-users met eigen wachtwoordIdentity Center (voorheen AWS SSO) koppelt aan je IdP en geeft tijdelijke credentials per sessie.
Past het bovenstaande niet?
Beschrijf je situatie hieronder. We sturen jouw input plus de stappen die je al zag naar onze AI en geven gericht vervolg-advies. Als het te risicovol is om zelf te doen, zeggen we dat ook.
Of doe het helemaal niet zelf
Onze Managed IT-klanten zoeken dit soort vragen niet op. Eén aanspreekpunt, vaste prijs per maand, en het is binnen werktijd opgelost.