Building PCI DSS-Compliant Architectures on Amazon EKS

PCI DSS on EKS is not one control. It is a set of controls that have to line up: network inspection, identity, logging, and evidence retention. AWS’s April 2026 guidance is useful because it treats compliance as an architecture problem instead of a checkbox exercise.

The common mistake is to focus on the cluster first and the evidence later. That is backwards. In practice, the logs, detections, and access boundaries are what make the cluster defensible when an auditor or incident responder asks hard questions.

Control Table

Compliance Flow

flowchart LR
  Internet[Inbound traffic] --> Firewall[AWS Network Firewall]
  Firewall --> EKS[EKS cluster]
  EKS --> Logs[CloudTrail, CloudWatch, application logs]
  EKS --> GD[GuardDuty]
  GD --> SH[Security Hub]
  Logs --> SH

What Actually Helps

The best part of the AWS guidance is that it pushes the same operational idea across the stack: keep the control plane boring and the evidence complete. If your platform team already owns Security Hub and GuardDuty, this post is really about making EKS fit that existing model instead of inventing a separate one.

The gotcha is compliance language. AWS is clear that the content is guidance, not legal advice. That means the architecture can be well designed and still need a formal assessment before anyone claims PCI compliance.

Related reading

• GuardDuty fundamentals
• Security Hub as a findings control plane
• centralized network inspection
• identity and RBAC boundaries on EKS

Sources

• AWS Containers Blog: Building PCI DSS-Compliant Architectures on Amazon EKS
• AWS EKS security best practices