Amazon SCS-C02: Netwerken en VPC-beveiliging — Studiegids

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Onderdeel van de AWS Security Specialty SCS-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

VPC-eindpunten en eindpuntbeleid

VPC-eindpunten houden verkeer naar AWS-services op het AWS-netwerk, waarbij het publieke internet, NAT-gateways en internetgateways worden omzeild. Er zijn twee structureel verschillende soorten, en het verwarren van deze twee is een van de meest voorkomende ontwerpfouten.

Gateway-eindpunten bestaan alleen voor Amazon S3 en DynamoDB. Het zijn vermeldingen in de route-tabel — je koppelt het eindpunt aan route-tabellen, en verkeer bestemd voor de prefixlijst van de service (bijvoorbeeld pl-63a5400a voor S3 in us-east-1) wordt stilzwijgend omgeleid via het eindpunt. Ze kosten niets en zijn niet bereikbaar van buiten de VPC waaraan ze zijn gekoppeld.

Interface-eindpunten (aangedreven door AWS PrivateLink) zijn ENI’s met private IP-adressen die in je subnets worden geplaatst. Ze zijn vereist voor elke service die niet S3 of DynamoDB is — Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR, en honderden andere. Als een EC2-instance in een private subnet zonder NAT-gateway GetSecretValue moet uitvoeren vanuit Secrets Manager, zal een gateway-eindpunt niet helpen; je moet een com.amazonaws.<region>.secretsmanager interface-eindpunt aanmaken en Private DNS inschakelen zodat de standaard service-hostnaam wordt omgezet naar het private IP-adres van het eindpunt.

Eindpuntbeleid beperkt wat er via het eindpunt kan worden gedaan, onafhankelijk van IAM-beleid op de aanroeper. De twee belangrijkste condition keys om data-exfiltratie te voorkomen zijn aws:PrincipalOrgID (de identiteit die de aanroep doet moet tot jouw Organization behoren) en aws:ResourceOrgID (de S3-bucket, KMS-sleutel, etc. die wordt aangesproken moet tot jouw Organization behoren). Het toepassen van beide sluit de klassieke exfiltratieroute af waarbij een gecompromitteerde instance met legitieme S3-permissies data wegschrijft naar een bucket buiten je org die door een aanvaller wordt beheerd — de credentials werken nog steeds tegen S3, maar het eindpunt weigert het verzoek door te sturen.

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-abc123",
        "aws:ResourceOrgID":  "o-abc123"
      }
    }
  }]
}

Het standaard eindpuntbeleid is volledig permissief ("Action":"*" op "Resource":"*"), wat de reden is dat een subnet met alleen een gateway-eindpunt en least-privilege IAM nog steeds misbruikt kan worden voor exfiltratie, tenzij je het eindpuntbeleid zelf aanscherpt.

Hybride connectiviteit: VPN en Direct Connect

Site-to-Site VPN zet twee IPsec-tunnels op tussen een virtual private gateway (of Transit Gateway) en een customer gateway-apparaat. Het is snel te provisioneren, standaard versleuteld en loopt via het publieke internet — dus de doorvoersnelheid en latentie zijn afhankelijk van het pad van je ISP.

AWS Direct Connect provisioneert een speciaal fysiek circuit via een Direct Connect-locatie. Het biedt voorspelbare lage latentie en hoge, consistente bandbreedte (1/10/100 Gbps), wat belangrijk is voor intensief on-premises databaseverkeer. Direct Connect is op zichzelf niet versleuteld op laag 3; de frames lopen over private glasvezel. Voor workloads die zowel lage latentie als IPsec vereisen, is het canonieke antwoord Direct Connect plus een Site-to-Site VPN die over een public VIF draait (of een Transit Gateway met MACsec op nieuwere DX-poorten). VPN alleen is ook de aanbevolen versleutelde back-up voor een primaire Direct Connect-link, wat veerkracht biedt als het circuit uitvalt.

• Alleen Direct Connect: lage latentie, privaat, maar niet versleuteld op de IP-laag.
• Alleen VPN: versleuteld, snel te implementeren, maar met latentie en jitter van het internetpad.
• Direct Connect + VPN: lage latentie en IPsec-versleuteling; ook het standaard HA-patroon.

Security Groups, NACL’s, DHCP en Source/Destination-controles

Security groups zijn stateful: als je een inkomend verzoek toestaat, wordt het antwoord automatisch naar buiten toegestaan. Ze ondersteunen alleen allow-regels en worden per ENI geëvalueerd.

Network ACL’s (NACL’s) zijn stateless en opereren op de subnetgrens. Elke flow vereist twee regels — één voor de initiële richting en één voor het retourverkeer op het efemere poortbereik (Linux doorgaans 32768–60999, Windows 49152–65535, en NLB’s/ELB’s gebruiken 1024–65535). Een NACL die inkomend TCP 443 toestaat maar uitgaand TCP 1024–65535 vergeet, zal TLS stilzwijgend verbreken. ICMP is geen TCP/UDP: retour “echo reply”-pakketten moeten expliciet worden toegestaan, en Path MTU Discovery is afhankelijk van ICMP type 3 code 4, wat gemakkelijk per ongeluk kan worden geblokkeerd. NACL-regels worden ook in numerieke volgorde geëvalueerd, waarbij de eerste match wint, met een impliciete deny aan het einde.

DHCP option sets bepalen wat een VPC meegeeft aan instances bij het opstarten: domain-name-servers, domain-name, NTP-servers, NetBIOS. Het vervangen van de standaard AmazonProvidedDNS door een aangepaste on-premises resolver kan legitiem zijn, maar het heeft reële veiligheidsconsequenties. Services zoals GuardDuty leiden op DNS gebaseerde bevindingen af (bijvoorbeeld de “cryptocurrency”- en “C&C-domein”-detecties) uit queries die via de Route 53 Resolver lopen. Zodra je instances naar een DNS-server van derden verwijst, ziet GuardDuty de queries niet meer en verdwijnen die typen bevindingen — een gemakkelijke manier om per ongeluk detectie te verblinden.

Source/destination-controle is een ENI-attribuut dat elk pakket weggooit waarvan het bron- of doel-IP-adres niet overeenkomt met de ENI. Die standaardinstelling is correct voor gewone instances, maar verstoort de werking van elk apparaat dat als taak heeft verkeer door te sturen — NAT-instances, virtuele firewalls (Palo Alto, Fortinet, Check Point), transit routers, VPN-concentrators. Schakel voor die ENI’s de controle uit:

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --no-source-dest-check

VPC Peering, via RAM gedeelde VPC’s en NAT-ontwerp

VPC-peering is een één-op-één, niet-transitieve layer-3-verbinding. Als A peert met B en B peert met C, kan A C niet bereiken — je moet A–C rechtstreeks peeren of een Transit Gateway gebruiken. Route tables aan beide kanten moeten routes naar de peer-CIDR bevatten, en security groups kunnen alleen binnen een Region verwijzen naar security-group-ID’s van de peer.

Gedeelde VPC’s via AWS Resource Access Manager (RAM) stellen een networking-account in staat om eigenaar te zijn van een VPC en individuele subnets te delen met participant-accounts. Participants lanceren resources in gedeelde subnets, maar kunnen de VPC, route tables of endpoints niet wijzigen — de eigenaar behoudt de controle over het connectiviteitsbeleid. Dit is vaak goedkoper en eenvoudiger dan het peeren van veel VPC’s.

Voor uitgaand internetverkeer vanuit private subnets, implementeer je een NAT gateway per Availability Zone en routeer je elk private subnet naar de NAT in zijn eigen AZ. Een enkele NAT gateway is een cross-AZ-afhankelijkheid en een knelpunt voor schaalbaarheid en beschikbaarheid. Wanneer je workload een derde partij aanroept die je uitgaande verkeer op een IP-allowlist zet (bijvoorbeeld een betalingsverwerker), is het Elastic IP van de NAT gateway wat je registreert. Omdat instances achter een Auto Scaling group allemaal via dat vaste EIP uitgaand verkeer sturen, verandert het bron-IP-adres niet wanneer de groep schaalt. Het plaatsen van de EC2-instances en de RDS-database in private subnets en het uitsluitend beëindigen van HTTP/HTTPS op de ALB voltooit dit patroon.

Route 53 Resolver: Forwarding en Query Logging

De Route 53 Resolver (het .2-adres in elke VPC) is de spil voor hybride DNS. Outbound resolver endpoints sturen specifieke domeinnamen vanuit AWS door naar on-premises DNS-servers via conditional forwarding rules — bijvoorbeeld gebruikt zodat corp.example.internal wordt opgelost via je Active Directory. Inbound resolver endpoints doen het omgekeerde: ze geven on-premises hosts een privaat IP-adres in je VPC dat ze kunnen bevragen om *.eu-west-1.compute.internal en Private Hosted Zones op te lossen.

Resolver query logging schrijft elke DNS-query die vanuit de VPC wordt gedaan naar CloudWatch Logs, S3 of Kinesis Firehose. Het is de gezaghebbende bron voor het onderzoeken van vermoedelijke data-exfiltratie of misbruik en vult GuardDuty aan, maar vervangt het niet. Onthoud dat als een DHCP option set instances omleidt naar een niet-Amazon-resolver, zowel query logging als GuardDuty DNS-bevindingen onzichtbaar worden, omdat de queries de Route 53 Resolver nooit bereiken.

Praktijkprobleem: Gebruiksscenario

Scenario: Meridian Financial beheert een multi-account AWS-omgeving met een hub-and-spoke-netwerk: een via RAM gedeelde shared-services VPC host centrale NAT Gateways, Route 53 Resolver endpoints en Transit Gateway attachments, terwijl meerdere applicatie-VPC’s zijn gepeerd met of gekoppeld aan de Transit Gateway. On-premises datacenters maken verbinding via Direct Connect met VPN-failover, en teams vertrouwen op gecentraliseerde DHCP option sets en gedeelde resolver endpoints voor hybride DNS-resolutie.

Uitdaging: Een recent incident toonde aan dat gevoelige S3-objecten via het publieke internet werden benaderd omdat spokes routeerden naar de gedeelde NAT in plaats van naar VPC endpoints. DNS-queries voor interne zones lekten naar publieke resolvers, en een EC2-instance die als ad-hoc router werd gebruikt (source/dest check uitgeschakeld) maakte laterale beweging mogelijk.

Aanbevolen Aanpak:

1. Implementeer Gateway VPC Endpoints voor S3 en DynamoDB en Interface Endpoints (AWS PrivateLink) voor Secrets Manager en KMS in de shared-services VPC. Koppel expliciete endpoint policies die de toegang beperken tot specifieke buckets en service principals.
2. Herzie het NAT-ontwerp zodat applicatiesubnets VPC endpoints gebruiken voor AWS API’s en S3; behoud NAT Gateways alleen voor echt uitgaand internetverkeer met strikte egress security groups en Flow Logs naar CloudWatch/S3.
3. Schakel source/dest checks opnieuw in op alle EC2-instances, behalve op gedocumenteerde routing-appliances; verplaats routing naar Transit Gateway attachments of beheerde NAT-instances en dwing ’least privilege’ af voor route tables.
4. Versterk Security Groups en subnet-NACL’s naar een ‘deny-by-default’-houding, en pas gecentraliseerde IAM+SG-baselines toe via AWS Organizations SCP’s en AWS Config-regels.
5. Verhard hybride DNS door Route 53 Resolver inbound/outbound endpoints te implementeren, conditional forwarding en DNS Firewall-regels te configureren, Resolver query logging naar CloudWatch Logs in te schakelen en DHCP option sets te gebruiken om interne resolvers af te dwingen voor alle VPC’s die via RAM worden gedeeld.

Redenering: Deze aanpak elimineert onnodig uitgaand internetverkeer door VPC endpoints met endpoint policies te gebruiken, centraliseert en controleert routing via Transit Gateway/Direct Connect, herstelt beveiligingen op instance-niveau en voorkomt DNS-lekkage met Resolver endpoints en logging — in lijn met de best practices van AWS voor netwerken en ‘defense-in-depth’.

VPC-eindpunten en Eindpuntbeleid

VPC-eindpunten stellen workloads binnen een VPC in staat om AWS-service-API’s te bereiken zonder via het openbare internet of een NAT-gateway te gaan. Er zijn twee architecturale varianten, en het kiezen van de verkeerde is een veelvoorkomende oorzaak van verkeerd gerouteerd verkeer.

• Gateway-eindpunten: Alleen gebruikt voor Amazon S3 en DynamoDB. Ze worden geïmplementeerd als een target in een routetabel (prefixlijst pl-xxxxxxxx die verwijst naar vpce-xxxxxxxx). Er wordt geen ENI aangemaakt, er zijn geen DNS-wijzigingen nodig en er zijn geen kosten per uur.

• Interface-eindpunten (PrivateLink): Gebruikt voor KMS, SQS, SNS, Secrets Manager, STS, EC2 API en de meeste andere services. Ze provisioneren ENI’s met privé-IP’s binnen gekozen subnets en worden per uur plus per GB gefactureerd.

Voor een cross-account batchtaak waarbij EC2-instances in Account B lezen uit een S3-bucket in Account A die versleuteld is met een KMS-sleutel in Account A, is het juiste ontwerp een gateway-eindpunt voor S3 plus een interface-eindpunt voor KMS. Het gateway-eindpunt houdt s3:GetObject, s3:PutObject, s3:PutObjectAcl en s3:ListBucket van het internet af; het interface-eindpunt doet hetzelfde voor kms:Decrypt, kms:Encrypt en kms:GenerateDataKey. Omdat de KMS-sleutel-ARN de standaard kms.<region>.amazonaws.com-hostnaam gebruikt, moet het interface-eindpunt Private DNS ingeschakeld hebben, zodat de ongewijzigde hostnaam van de SDK resolvet naar de ENI van het eindpunt in plaats van naar de openbare KMS-service. Zonder Private DNS (of zonder dat zowel DNS-hostnames als DNS-resolutie op VPC-niveau zijn ingeschakeld), zou de client nog steeds het openbare eindpunt benaderen — vandaar dat de eis van “geen codewijzigingen” impliciet Private DNS vereist.

Eindpuntbeleid is een tweede, onafhankelijke autorisatielaag. Er bestaat een permissief standaardbeleid, maar het verharden voor een specifieke bucket en sleutel ziet er als volgt uit:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
  }]
}

Alleen het aanmaken van het eindpunt is niet voldoende. Twee faalmodi komen vaak voor: (1) het eindpunt bestaat, maar de routetabel van het private subnet heeft geen route voor de S3-prefixlijst, waardoor verkeer alsnog via de NAT-gateway naar buiten gaat; (2) het eindpuntbeleid laat een actie zoals s3:PutObjectAcl weg of richt zich op de verkeerde bucket-ARN, waardoor aanroepen die IAM anders zou toestaan stilzwijgend worden geblokkeerd. Zowel het bucketbeleid als het eindpuntbeleid moeten het verzoek toestaan — de doorsnede van de beleidsregels wordt genomen, niet de unie.

Securitygroepen, NACL’s en Snelle Indamming

Securitygroepen en NACL’s lossen overlappende problemen op verschillende lagen op, en het examen dwingt vaak een keuze tussen beide voor incidentrespons.

• Securitygroepen: Stateful, geëvalueerd op de ENI. Retourverkeer wordt automatisch toegestaan. Er bestaan alleen ‘allow’-regels. Ideaal voor beleid op hostniveau (“web-tier kan app-tier bereiken op 8080”).

• Network ACL’s: Stateless, geëvalueerd op de subnetgrens. Er bestaan zowel ‘allow’- als ‘deny’-regels, die op volgorde van regelnummer worden verwerkt. Ideaal voor grove blokkades voor het hele subnet — met name het op een zwarte lijst plaatsen van een IP-range of het afsluiten van een specifieke poort voor elke instance in een subnet.

Wanneer een malware-uitbraak je dwingt om uitgaand verkeer op TCP/2905 naar een reeks command-and-control-IP’s te blokkeren voor veel instances, is een NACL ‘deny’-regel het juiste instrument. Securitygroepen kunnen geen ‘deny’ uitdrukken en zouden vereisen dat elke SG die door elke getroffen ENI wordt gebruikt, wordt opgesomd en gewijzigd. Eén enkele NACL ‘deny’-regel op subnetniveau met een laag regelnummer (bijv. 90) dekt onmiddellijk alle instances in dat subnet, terwijl niet-gerelateerd verkeer dat door latere ‘allow’-regels wordt geëvalueerd, behouden blijft.

Omdat NACL’s stateless zijn, moet je onthouden dat voor beide richtingen regels nodig zijn. Het blokkeren van uitgaand verkeer op 2905 vereist geen inkomende regel, maar als je ook inkomende antwoorden wilt weigeren, moet je een inkomende regel toevoegen — en er moeten inkomende ‘allow’-regels voor efemere poorten (1024–65535) bestaan om legitiem retourverkeer door te laten.

NAT-gateways, Routing en AZ-onafhankelijkheid

Een NAT-gateway is een zonale resource. Het canonieke patroon is één NAT-gateway per Availability Zone, waarbij de routetabel van elk private subnet 0.0.0.0/0 laat verwijzen naar de NAT in dezelfde AZ:

PrivateRouteTable-AZ-a:  0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b:  0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c:  0.0.0.0/0 -> nat-cccc (in subnet public-az-c)

Eén enkele NAT-gateway die over meerdere AZ’s wordt gedeeld, lijkt goedkoper, maar introduceert twee problemen: kosten voor dataverkeer tussen AZ’s voor elk pakket, en een harde afhankelijkheid van beschikbaarheid — als die AZ uitvalt, verliest elk private subnet zijn uitgaande internetverbinding. Het zonale NAT-patroon vermijdt ook problemen met asymmetrische retourpaden in combinatie met Transit Gateway-inspectie (zie hieronder).

VPC Flow Logs voor Onderzoek

Flow Logs leggen 5-tuple metadata vast (bron/doel-IP, poort, protocol, actie ACCEPT/REJECT, bytes, pakketten) op VPC-, subnet- of ENI-niveau. Om instances op te sporen die ‘beaconen’ naar C2-hosts op TCP/2905, schakel je Flow Logs in op de VPC met het verkeerstype ingesteld op REJECT (aangezien de NACL dit verkeer nu weigert) en voer je een query uit in CloudWatch Logs Insights of Athena:

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;

De srcaddr-kolom onthult de IP’s van geïnfecteerde instances met minimale inspanning — geen packet-captures, geen host-agents. Het kiezen van “ALL” verkeer werkt ook, maar produceert meer data en kosten; als je alleen “ACCEPT” kiest, mis je de geweigerde pogingen volledig, en dat is nu precies wat je moet zien.

PrivateLink, Transit Gateway en Network Firewall

PrivateLink breidt het interface-endpointmodel uit naar uw eigen services: een provider-VPC stelt een NLB beschikbaar achter een VPC-endpointservice, en consumenten creëren interface-endpoints om deze te bereiken zonder VPC-peering of het delen van routes. Het is unidirectioneel en verbergt de CIDR van de provider volledig.

Transit Gateway (TGW) is de hub voor many-to-many connectiviteit tussen VPC’s en on-premises omgevingen. Een veelvoorkomend patroon is een gecentraliseerde inspectie-VPC die AWS Network Firewall of appliances van derden draait, waarbij TGW-routetabellen het spoke-to-spoke verkeer door de inspectie-VPC sturen. Dit ontwerp faalt onder het standaardgedrag van TGW, omdat TGW flows hasht over attachment-ENI’s in verschillende AZ’s, en het retourpad een andere AZ kan binnenkomen dan het voorwaartse pad. Stateful firewalls droppen de mid-flow pakketten waarvoor ze nooit de SYN hebben gezien.

Twee correcties zijn tegelijkertijd vereist. Ten eerste, schakel Appliance Mode in op de TGW-attachment voor de inspectie-VPC; dit koppelt elke bidirectionele flow aan dezelfde AZ ENI, zodat het voorwaartse en retourverkeer door hetzelfde firewall-endpoint gaan. Ten tweede, configureer TGW-routetabellen zodat spoke-attachments verkeer naar de inspectie-VPC-attachment sturen, en een aparte post-inspectie routetabel op de inspectie-VPC het verkeer terugstuurt naar de juiste spoke. Het overslaan van een van beide — alleen appliance mode zonder de routetabellen, of alleen de routetabellen zonder appliance mode — laat asymmetrische drops bestaan.

Network Firewall zelf gebruikt Suricata-compatibele regels en is afhankelijk van symmetrische routing om de flow-status te behouden; de combinatie met Flow Logs op zowel de inspectie-VPC als de spoke-VPC’s levert het forensische spoor op dat nodig is om te bewijzen welke spoke een sessie heeft geïnitieerd en of de firewall deze heeft toegestaan of gedropt.

Praktijkprobleem: Gebruiksscenario

Scenario: Meridian Financial beheert een multi-account AWS-omgeving met productie-VPC’s verspreid over drie Availability Zones in us-east-1, verbonden door een AWS Transit Gateway met een centrale security-VPC. Ze gebruiken NAT Gateways in elke AZ voor egress, S3 Gateway Endpoints en Interface Endpoints (PrivateLink) voor SaaS van partners, en een gecentraliseerde AWS Network Firewall naast Security Groups en NACL’s; VPC Flow Logs streamen naar CloudWatch voor monitoring.

Uitdaging: Een productie-EC2-instance wordt verdacht van ’lateral movement’ en pogingen tot data-exfiltratie naar een extern IP-adres en naar S3, en Meridian heeft snelle indamming nodig over alle AZ’s heen zonder andere bedrijfskritische VPC’s te verstoren.

Aanbevolen Aanpak:

1. Plaats de gecompromitteerde instance onmiddellijk in quarantaine door de bijbehorende Security Groups te vervangen door een restrictieve ‘quarantaine’-SG die al het uitgaande/inkomende verkeer weigert, en tag de instance voor geautomatiseerde herstelacties via Systems Manager; pas tegelijkertijd Network ACL-regels op subnetniveau toe om egress naar verdachte externe IP-reeksen te blokkeren.
2. Isoleer de VPC op de Transit Gateway door de TGW-routetabel-attachment voor de betreffende VPC te verwijderen of te wijzigen naar een quarantaine TGW-routetabel (blackhole of geen route naar andere attachments), om ’lateral movement’ naar andere VPC’s te stoppen.
3. Leid de resterende VPC-egress om via de gecentraliseerde AWS Network Firewall door TGW/routetabel-entries bij te werken om inspectie af te dwingen en bekende kwaadaardige bestemmingen te blokkeren, waarbij de AZ-onafhankelijkheid wordt behouden door NAT Gateways per AZ te handhaven voor veerkrachtige, geïnspecteerde egress.
4. Versterk de data-plane-controles door restrictieve VPC Endpoint-policies toe te passen op S3/DynamoDB Gateway Endpoints om Put/Get van niet-goedgekeurde principals te weigeren en ervoor te zorgen dat interne API’s Interface Endpoints (PrivateLink) gebruiken om internetpaden te vermijden.
5. Gebruik VPC Flow Logs met CloudWatch Logs Insights en AWS CloudTrail om forensisch onderzoek uit te voeren, herstel vervolgens de instance (re-image, roteer sleutels) en herintroduceer deze pas na validatie; dwing regels af via AWS Firewall Manager/AWS Config.

Rationale: Deze volgorde biedt snelle ’least-privilege’ indamming op zowel de host- als de netwerklaag, centraliseert inspectie met Network Firewall en Transit Gateway-routing om de ‘blast radius’ te minimaliseren, behoudt AZ-veerkracht met per-AZ NAT, en gebruikt VPC Flow Logs voor verantwoord onderzoek—in lijn met de ‘defense-in-depth’ best practices van AWS.

← Gegevensbescherming en S3 · Alle domeinen · Edge en Applicatiebeveiliging →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Amazon →