A utility OT/IT bridge VPC must allow historian hosts to reach analytics only on specific ports, using security groups as the primary instance-level control and network ACLs as coarse subnet guardrails. Which prescription is correct?
Select an answer to reveal the explanation.
Short Explanation
Security groups are the precise door locks on each machine; NACLs are the hallway gates. Lock historian-to-analytics ports with SG allow rules, then use NACLs only as coarse backup fences. Wide-open SGs with NACL-only dreams miss how AWS expects you to segment.
Full Explanation
On a utility OT/IT bridge VPC, security groups should be the primary instance-level control allowing historian hosts to reach analytics only on the specific ports required, using stateful allow rules from historian security groups to analytics security groups. Network ACLs then act as coarse, stateless subnet guardrails that support—not replace—those security groups. That layered prescription matches AWS guidance: security groups for microsegmentation, NACLs for subnet-level allow/deny boundaries when needed.
Using only network ACLs for all microsegmentation while leaving security groups open to 0.0.0.0/0 inverts the model and makes operators maintain brittle ephemeral-port rules for every flow. Disabling both security groups and NACLs because “routing alone enforces least privilege” is false—routing forwards packets; it does not authorize application ports. Placing historians and analytics in the same security group with all protocols allowed collapses OT/IT separation into a single trust blob.
Exam caveat: security groups are stateful; NACLs are stateless and evaluated at subnet boundaries—exam distractors often swap their roles or claim one replaces the other. Operational check: implement SG allow rules for only the historian-to-analytics ports, keep NACLs minimal and documented, probe disallowed ports and protocols to confirm drops, and review Flow Logs for REJECT actions when OT hosts scan beyond the allow-list.