Amazon SAP-C02: Organisatorische Complexiteit & Multi-Account Strategie — Studiegids
Onderdeel van de AWS Solutions Architect Professional SAP-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.
Multi-accountstrategie en account vending
Een multi-accountstrategie begint met een duidelijke scheiding van verantwoordelijkheden: security en audit, gedeelde netwerken, productieworkloads en sandbox- of ontwikkelaarsaccounts. Het gebruik van AWS Organizations met ofwel AWS Control Tower of een custom landing zone dwingt deze scheiding vanaf dag één af. De Account Factory van Control Tower biedt een ‘account vending’-patroon dat het aanmaken van accounts, baseline IAM-rollen, VPC-templates en guardrails automatiseert, terwijl een custom landing zone, gebouwd met CloudFormation/CDK en Service Catalog, meer flexibiliteit biedt voor op maat gemaakte netwerken en governance. De belangrijkste afweging is operationele overhead versus de beperking van de blast radius: meer accounts vergroten het beheeroppervlak (automatisering, cross-account rollen, facturatie-inzicht), maar beperken de blootstelling bij een domeincompromittering en vereenvoudigen de compliance per account. Netwerkkeuzes — VPC sharing met AWS Resource Access Manager, een Transit Gateway hub-and-spoke-model, of geïsoleerde VPC’s met VPC peering — bepalen de afwegingen tussen kosten en latency. Gedeelde services (DNS, NAT, Active Directory) bevinden zich vaak in een networking- of shared-services-account; account vending zou nieuwe accounts automatisch moeten koppelen aan deze gedeelde resources of gedelegeerde VPC’s moeten provisioneren. Plan quota’s en automatisering: centraliseer pipelines voor baseline-artefacten zodat de schaal van accounts het handmatige werk niet vermenigvuldigt.
Governance: SCP’s, Control Tower guardrails en organisatiebeleid
Governance in een multi-account AWS-omgeving is afhankelijk van beleidshandhaving op organisatieniveau en van gedelegeerde runtime-controles. Service Control Policies (SCPs) stellen de bovengrens in voor toegestane acties over alle accounts; ze zijn krachtig maar meedogenloos — deny-regels op de root-OU verhinderen zelfs beheerders om service-linked roles aan te maken of services te gebruiken, tenzij expliciet toegestaan. Control Tower biedt vooraf gebouwde guardrails (verplicht, sterk aanbevolen, optioneel) die veelvoorkomende SCP’s en Config-regels implementeren, maar kan beperkend zijn voor geavanceerde servicepatronen. De ontwerpbeslissing draait om gecentraliseerde versus gedelegeerde governance: een strikte deny-list op root-niveau maximaliseert de compliance, maar verhoogt de frictie voor productteams en automatisering, terwijl permissieve baselines met permission boundaries en IAM-rolcontroles een hogere ontwikkelsnelheid mogelijk maken. Beleid voor logging en auditing (organization CloudTrail, AWS Config aggregator, Security Hub en GuardDuty delegated administrators) moet worden afgedwongen vanuit het managementaccount om onveranderlijke audittrails te garanderen. Een pragmatische aanpak is gelaagde governance: organisatie-SCPs voor beperkingen met een hoge impact, permission boundaries voor de scope van ontwikkelaars, en geautomatiseerde guardrails die worden toegepast door de CI/CD van de landing zone om consistentie te behouden zonder handmatige goedkeuring.
Security boundaries: cross-account rollen, KMS en resource-beleid
Cross-account toegang is een kernpatroon en moet worden geïmplementeerd met least privilege en sterke vertrouwenscontroles. Het gangbare patroon delegeert toegang via IAM-rollen in elk account, die vertrouwde principals aannemen met STS: rollen voor CI/CD-deployment, monitoring (CloudWatch/SSM) en integraties met derden zouden waar nodig MFA moeten vereisen en external ID’s moeten gebruiken voor partnertoegang. Resource-gebaseerd beleid op S3, SQS en KMS keys maakt directe cross-account toegang mogelijk, maar KMS voegt complexiteit toe: een KMS key policy moet expliciet de principals en services van het vertrouwende account toestaan, en grants of grants-with-constraints kunnen nodig zijn voor tijdelijke toegang. Het gebruik van een gecentraliseerde KMS key in het logging- of security-account vereenvoudigt gecentraliseerde encryptie, maar creëert operationele koppeling en mogelijke beschikbaarheidsoverwegingen; sleutels per account verkleinen de blast radius, maar vermenigvuldigen het beheer van sleutelrotatie en grants. Veelvoorkomende valkuilen zijn SCP’s die onbedoeld de aanmaak van KMS of service-linked roles weigeren, bucket policies die conflicteren met SCP’s, en het vergeten om de delegatierol toe te voegen aan Config/CloudTrail in het collector-account. Ontwerpbeslissingen moeten een afweging maken tussen administratieve eenvoud, least privilege en cross-account latency.
Gecentraliseerde patronen voor logging, facturering en automatisering
Gecentraliseerde logging en facturering vormen de ruggengraat van de zichtbaarheid binnen een onderneming. Een organization CloudTrail met trails die worden afgeleverd in een S3-bucket in een gecentraliseerd security- of audit-account zorgt voor een fraudebestendige vastlegging van events; vul dit aan met CloudWatch Logs subscription filters naar Kinesis Data Firehose voor analyses, en aggregeer Config-data met een aggregator naar hetzelfde account. Zichtbaarheid van kosten vereist geconsolideerde facturering in Organizations, Cost Explorer, Budgets en centraal aangeleverde Cost and Usage Reports; tag governance en geautomatiseerde tag-handhaving via Config-regels verbeteren de nauwkeurigheid van doorbelastingen. Automatiseringspatronen die over meerdere accounts schalen, maken vaak gebruik van een gedeelde CI/CD-pipeline of een deployment-account dat cross-account deployment-rollen aanneemt, of CloudFormation StackSets met een delegated administrator voor massale provisioning. Gebruik Systems Manager Automation en State Manager voor cross-account patching en configuratie, maar onthoud dat elk account de benodigde rollen en SSM-permissies moet verlenen. Afwegingen balanceren centralisatie en latency: centrale aggregatie vermindert dubbele opslag en vereenvoudigt analyse, maar creëert afhankelijkheden van het netwerk en de beschikbaarheid; gedistribueerde logging dupliceert data maar isoleert storingen. Maak een plan voor retentie, lifecycle rules, cross-region replication voor DR en beheer van encryptiesleutels dat in overeenstemming is met de compliance-eisen.
Praktijkprobleem: Use-Case Scenario
Scenario: Contoso Media beheert een enterprise AWS-omgeving met Organizations en Control Tower. Ze hebben een management-account, een shared-services networking-account en 20 member-accounts met productie-, staging- en developer-workloads verspreid over twee Regions.
Uitdaging: Contoso moet snel 15 nieuwe project-accounts onboarden en tegelijkertijd zorgen voor gecentraliseerde logging, passende SCP-guardrails, geautomatiseerde netwerkconnectiviteit met het shared-services-account via Transit Gateway, en deployment-pipelines die geen handmatige IAM-configuratie per account vereisen.
Aanbevolen Aanpak:
- Gebruik Control Tower Account Factory of een geautomatiseerde AWS Organizations API-workflow om accounts uit te geven met een baseline CloudFormation/CDK-template die het account registreert in AWS Config, een organization CloudTrail inschakelt die naar de S3-bucket van het audit-account wijst, en de vereiste tags toepast.
- Koppel SCP’s op OU-niveau die denies met hoge impact afdwingen (bijvoorbeeld het weigeren van cross-region key deletion en niet-toegestane regions), terwijl OUs voor development-permissies minder restrictief blijven; valideer SCP’s in een sandbox voordat ze breed worden toegepast.
- Configureer Transit Gateway in het shared-services networking-account en maak attachments voor de Transit Gateway VPC-attachment van elk nieuw account met behulp van Infrastructure-as-Code en een delegated admin of een cross-account role die het uitgifteproces aanneemt om het aanmaken van attachments en route propagation te automatiseren.
- Provisioneer een gecentraliseerde CI/CD-deployment-pipeline in een tooling-account die gebruikmaakt van cross-account IAM-rollen (assume-role) die zijn aangemaakt door het account-uitgifteproces; gebruik CloudFormation StackSets (delegated admin) of cross-account CodePipeline-acties voor de initiële baseline-provisioning en doorlopende updates.
Rationale: Het automatiseren van de accountuitgifte met baseline-artefacten dwingt governance af en minimaliseert handmatige stappen; het delegeren van netwerk- en deployment-taken via cross-account rollen en Transit Gateway centraliseert gedeelde services, verkleint de blast radius en schaalt de onboarding op zonder in te boeten aan security of auditeerbaarheid.
Oefen deze vragen → · Getimede oefening op ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Slaag voor je examen →