Introduction
We were engaged by the financial branch of a German automotive group to build a multi-environment AWS platform for proxying financial transactions from the client’s existing merchant applications to external third-party payment gateway providers. Because the platform processes live card transactions, the production systems had to be compliant with the Payment Card Industry Data Security Standard (PCI DSS).
ITGix operates both managed-services and professional-services practices, giving us the expertise to design and implement infrastructure of this kind end to end. Our team has extensive experience delivering projects with complex security and compliance requirements across the financial, fintech, and banking sectors, as well as for digital payment software companies. We focus on automation, infrastructure as code, and AWS architectures built on the latest security and operational best practices for the financial industry.
Audit and Prerequisites
We began with an audit and discovery phase to scope the project and define the infrastructure and software requirements. Working together with the client’s software development providers, we produced an architecture design comprising four environments: three non-production environments and one production Cardholder Data Environment (CDE). The production environment is the one that carries PCI DSS certification.
The Challenge
The platform had to be highly available, scalable, and secure – and it had to satisfy every security and compliance requirement for PCI DSS certification.
Delivery timelines were strict. A PCI certification audit was already scheduled for three months after the discovery and design phases began. Within that window, the production system had to be fully built and ready for certification, penetration testing, and application scalability and reliability testing.
The Solution
Our goal was to fully automate every component of both the infrastructure and the application build-and-deploy lifecycle, factoring all security and compliance requirements into that automation so that no manual configuration was ever required.
AWS Architecture
The platform spans 9 AWS accounts:
- 1 common-services account hosting shared repositories.
- 4 application accounts – one of which is the production, PCI DSS-certified environment holding live card data.
- 4 logging accounts – used to aggregate logs from the application accounts into a centralized space.
Access to all AWS accounts is centralized through a SAML integration with a Keycloak identity provider. Access to production is ephemeral – typically scoped to the duration of a specific maintenance or deployment task – and granted only after a series of approvals. Additional controls restrict production access to PCI DSS-compliant laptops and approved networks.
Later in the project, GitLab was replaced by Azure DevOps repositories and CI/CD pipelines, consolidating all client automation under their preferred CI/CD toolchain.
AWS Production Environment
The production environment connects the merchant applications to external payment gateways, handling live card data in encrypted form.
This setup evolved over the lifecycle of the project, particularly after certification. The most significant change was the introduction of AWS Network Firewall, which blocks all outbound traffic from the infrastructure by default and allow-lists specific domains for HTTP/TLS traffic.
CI/CD Automation Pipelines
All infrastructure was built following infrastructure-as-code best practices using Terraform and CI/CD pipelines. Application components run on Kubernetes via Amazon EKS, with their build-and-deploy lifecycle handled through Docker images and Helm charts inside the pipelines.
The pipelines create self-contained, versioned Docker images of the infrastructure and application code during the CI stage, and deploy those same images to each environment during the CD stage. Two of the non-production environments host a GitLab/Azure DevOps runner, allowing CI pipelines to execute inside the AWS internal network. The CD pipelines then deploy the pre-built images. This runs on the AWS-managed CI/CD services CodeBuild and CodePipeline, chosen specifically because certain PCI DSS requirements could not be met with external tooling.
Logging
All logs are collected – via a range of tools – into CloudWatch log groups. A custom Lambda then restructures the logs and forwards them to an Elasticsearch instance in a dedicated logging account, where they are aggregated, indexed, and visualized in Kibana.
Monitoring
Monitoring is built into the automation itself – embedded in the Terraform modules, Helm charts, and pipelines – so every component ships with its own alerts, whether for AWS-managed services, URL/endpoint monitoring, or application-level metrics. The core monitoring stack is CloudWatch, Synthetic Canary checks, Prometheus with Alertmanager, and Grafana.
The Conclusion
Despite strict deadlines and demanding security and compliance requirements, we delivered the project on time and without compromising on end-to-end automation. The client’s production Cardholder Data Environment was successfully certified, and we continue to support the platform under an ongoing managed-services engagement.
The Results
- PCI DSS certification achieved on schedule – the production CDE was certified within the 3-month audit deadline.
- 100% infrastructure-as-code – all 9 AWS accounts provisioned via Terraform with zero manual configuration.
- Zero standing access to production – all human access is ephemeral and granted only after multi-step approval.
- Default-deny egress – all outbound production traffic is blocked by AWS Network Firewall, with explicit domain allow-listing for HTTP/TLS.
- Well-Architected by design – AWS Well-Architected Framework best practices applied across all four environments.
- Fully Automated CI/CD pipelines – all infrastrcuture and application changes are being deployed via CI/CD pipelines with an approval process.