# Building PCI DSS-Compliant Architectures on Amazon EKS: A Complete Guide

- Link: https://thestackobserver.com/building-pci-dss-compliant-architectures-on-amazon-eks-a-complete-guide/
- Published: 2026-04-04T19:47:59-04:00
- Author: Stackxx

Running payment card data workloads on Kubernetes no longer requires exclusive dedicated
infrastructure. AWS now supports PCI DSS compliance on Amazon EKS using shared tenancy
EC2 instances, fundamentally changing the cost and operational calculus for financial
services organizations. The shift from dedicated hosts to shared tenancy can reduce
infrastructure costs by 60-80% while maintaining full PCI DSS compliance, provided
you implement the correct compensating controls.

## The Shared Tenancy Decision

Historically, PCI DSS environments defaulted to dedicated hosts due to concerns 
about multi-tenant isolation. AWS’s shared tenancy support changes this assumption,
but organizations must carefully evaluate trade-offs across cost, scalability, isolation
levels, and compliance overhead.

| Factor | Shared Tenancy | Dedicated | 
| Cost | ~60-80% lower | Premium pricing | 
| Scalability | Dynamic (Karpenter/CAS) | Manual planning | 
| Isolation | Hypervisor-level | Physical host | 
| Compliance scope | Additional controls needed | Simplified scoping |

The key insight from the AWS whitepaper: shared tenancy is viable for PCI workloads
when you implement compensating controls for the reduced physical isolation. AWS
provides PCI DSS Attestation of Compliance for shared tenancy, and numerous enterprises
already run compliant workloads on standard EC2 infrastructure.

## Architecture Overview

A compliant PCI architecture on shared tenancy EKS requires layered controls across
network segmentation, workload isolation, encryption, and access management. Each
layer addresses specific PCI DSS requirements while accounting for the multi-tenant
environment.

## 1. Network Segmentation

Apply strict VPC segmentation to isolate CDE (Cardholder Data Environment) workloads.
The recommended approach includes deploying dedicated EKS clusters for PCI workloads,
using private subnets exclusively with no internet gateways in CDE subnets, configuring
VPC Endpoints for AWS services to keep traffic within AWS network, and implementing
AWS Transit Gateway for controlled inter-VPC connectivity.

 * Dedicated EKS cluster for PCI workloads
 * Private subnets exclusively – no internet gateways in CDE subnets
 * VPC Endpoints for AWS services (S3, KMS, CloudWatch, Secrets Manager)
 * AWS Transit Gateway for controlled inter-VPC connectivity

## 2. Workload Isolation

Shared tenancy requires robust runtime isolation at the Kubernetes level. Implement
Pod Security Standards with Restricted profile for all CDE namespaces, use node 
taints and tolerations to ensure PCI pods run only on designated nodes, and deploy
runtime security monitoring via Falco or EKS security groups for behavioral analysis.
Resource quotas prevent resource starvation attacks that could impact other tenants
on the same physical host.

## 3. Encryption Everywhere

PCI DSS mandates encryption of cardholder data in transit and at rest. For EKS workloads,
implement TLS 1.2+ for all service communication using AWS Private CA for internal
mTLS certificate management. Encrypt EBS volumes via AWS KMS, and store sensitive
configuration in encrypted AWS Secrets Manager entries. Use separate Customer Managed
Keys (CMKs) for PCI scope with IAM restrictions. Enable automatic key rotation annually,
and monitor key usage via CloudTrail for anomalous access patterns.

## 4. Access Control

Implement defense-in-depth for administrative access. Use IAM Roles for Service 
Accounts (IRSA) to avoid node-level AWS credentials entirely. Apply RBAC with principle
of least privilege, review access quarterly, and use AWS SSO for centralized authentication
to clusters. Enable audit logging via CloudTrail and EKS control plane logs, shipping
to immutable S3 storage for compliance evidence.

## Managing Node Provisioning

Shared tenancy compliance applies regardless of node provisioning strategy. Whether
using Karpenter, Cluster Autoscaler, or EKS Auto Mode, implement PCI-specific node
pools with explicit taints to ensure workloads land on appropriate infrastructure.
Karpenter node pools should use on-demand capacity rather than spot instances for
PCI workloads. Configure node rotation every 30 days for compliance requirements
using the expireAfter parameter.

## Monitoring and Evidence Collection

PCI DSS requires continuous monitoring and evidence retention. Implement file integrity
monitoring via AWS GuardDuty for EKS runtime events. Enable Amazon Inspector for
ECR image scanning and CIS benchmarks. Configure WAF and CloudFront logs to S3 with
Object Lock enabled. Retain CloudWatch logs for one year minimum for compliance 
investigations.

## Resources

 * AWS provides comprehensive guidance including a whitepaper on [Architecting with EKS for PCI DSS Compliance](https://d1.awsstatic.com/whitepapers/architecting-amazon-eks-for-pci-dss-compliance.pdf)
 * The [PCI DSS v4.0 Compliance Guide](https://d1.awsstatic.com/whitepapers/compliance/pci-dss-compliance-on-aws-v4-102023.pdf)
   maps requirements to AWS services
 * AWS Artifact provides [PCI DSS Attestation of Compliance](https://aws.amazon.com/artifact/)
   for auditors

With proper architecture, shared tenancy is not just viable—it is the pragmatic 
choice for most PCI workloads on EKS. Organizations save substantially on infrastructure
while maintaining full compliance.

## Sources

 * [Building PCI DSS-Compliant Architectures on Amazon EKS](https://aws.amazon.com/blogs/containers/building-pci-dss-compliant-architectures-on-amazon-eks/)(
   AWS Blog, Apr 1, 2026)
 * [Architecting with EKS for PCI DSS Compliance](https://d1.awsstatic.com/whitepapers/architecting-amazon-eks-for-pci-dss-compliance.pdf)(
   AWS Whitepaper)