Two infrastructure engagements delivered end to end — discovery, architecture, build and handover. Diagrams below show the architecture pattern; client account identifiers, internal hostnames and network ranges are deliberately omitted.
Payments platform infrastructure, built to compliance
Atmoon · Greenfield build · Delivered in 3 months
A payments platform needs its compliance posture designed in, not retrofitted. This engagement ran from a discovery pass over the existing estate through to running environments — account structure, network tiering, cluster security and patching, built against PCI DSS requirements.
Architecture
Two availability zones. Every tier is its own subnet with its own NACL and security group, so traffic between tiers is explicitly allowed rather than implicitly reachable.
Region overviewPayments workload VPC and a separate management VPC, peered rather than shared, across two availability zones. Every tier is its own subnet with its own NACL and security group.
Traffic pathNorth-south flow from the internet down to the database tier, and why the private tiers have no route to the internet gateway.
Tier
Inbound allowed from
Ports
Outbound
Public
Internet
80, 443
Application tier
Application
Public tier security group
80, 443, ephemeral
Middleware · NAT gateway
Middleware
Application tier security group
queue and cache ports
Database tier
Database
Middleware tier security group
database ports only
None
Management
OpenVPN security group
22, 443
All tiers (administrative)
Rules reference security groups, not CIDR blocks. A rule that names a security group keeps working when subnets are resized or an instance is replaced, and it cannot be widened by accident the way a hand-typed range can.
Tier controlsThe inbound and outbound rules that make the tiering real. Traffic between tiers is explicitly allowed rather than implicitly reachable.
Operational accessHow engineers and pipelines reach the platform without putting an administrative entry point inside the application network.
Cluster and observabilityEKS with Istio for mTLS and APM telemetry, Kubernetes RBAC on top, and the Prometheus, Grafana and EFK stack that shipped with the platform.
1 / 5
Management VPC — peered, not shared
Jenkins, the application load balancer, OpenVPN access and the EKS control-plane endpoint live in a separate VPC peered to the workload VPCs. Operational entry points sit outside the application network, so administrative access is not a hole in the workload perimeter.
What was delivered
Pre-discovery before build. Established what actually ran where, so the target design addressed real workloads rather than assumptions.
Account structure and guardrails. OUs per environment with Service Control Policies scoped per account, and a central tagging policy enforced across the estate for cost attribution and ownership.
Everything in Terraform. Infrastructure provisioned as code, so environments are reproducible and drift is visible rather than discovered during an incident.
Patching that does not depend on people. OS configuration through Ansible, patch cycles through AWS Systems Manager Patch Manager.
Cluster security in depth. Istio provides mTLS between services and the APM visibility the compliance requirement asked for; Kubernetes RBAC governs who and what can act inside the cluster.
Observability from day one. Prometheus and Grafana for metrics, EFK for logs — in place at handover, not added after the first incident.
Multi-account landing zone and compliance re-architecture
Aerohub · India · Landing zone re-architecture
Aerohub ran a flat AWS estate where environments and business verticals shared blast radius and access. This engagement moved them onto an Organizations-based landing zone so compliance and access boundaries follow the org chart instead of cutting across it.
Organization structure
Guardrails are attached at OU level and inherited downward, so a new account arrives governed rather than needing policy reapplied by hand.
Organization structureCore, Security and Infrastructure OUs alongside per-vertical workload OUs. Guardrails are attached at OU level and inherited, so a new account arrives governed.
Management account and identityControl Tower, Service Catalog and centralised billing at the root — and the federated path a person takes from the corporate directory into an account.
Environments per verticalEach business vertical gets QA, performance-test and production accounts under its own OU, so blast radius and access follow the org chart.
Security and audit planeSecurity Hub, GuardDuty and Config in a dedicated Security account; CloudTrail and CloudWatch aggregated into a separate Log Archive account.
Attached at
Guardrail
What it prevents
Root
Deny leaving the organization; deny disabling CloudTrail, Config or GuardDuty
An account quietly stepping outside governance
Core OU
Deny changes to logging destinations and retention
Evidence being altered by the estate it covers
Security OU
Deny anything but the security tooling's own roles
Workload teams reaching into the audit plane
Workload OU
Region allow-list; deny public S3 and unencrypted volumes
Data landing outside approved regions or controls
Production OU
Everything above, plus deny IAM user creation and manual console changes to network paths
Drift between what Terraform says and what production runs
Policies are attached at OU level and inherited downward, so a newly vended account arrives governed. Reapplying policy per account is what lets guardrails drift as an estate grows.
Guardrails by OU levelWhat is denied where. Inheritance is the point — a guardrail written once at the right level covers every account beneath it, including ones that do not exist yet.
1 / 5
What was delivered
OU hierarchy designed around blast radius. Core, Security and Infrastructure OUs alongside per-vertical workload OUs, each with QA, performance-test and production accounts underneath.
SCPs at every level. Guardrails inherited down the tree rather than reapplied per account — which is what stops policy drift as the estate grows.
Control Tower and Service Catalog. Landing zone provisioning plus standardised account vending, so a new account is a request rather than a project.
Federated access. IAM Identity Center wired to Aerohub's existing identity provider — single sign-on into every account with per-account permission sets, and no long-lived IAM users to rotate or leak.
Centralised audit trail. A dedicated Log Archive account aggregating CloudTrail and CloudWatch into S3, separate from the Security account running Security Hub, GuardDuty and AWS Config across the organisation.
Cost visibility per vertical. Centralised billing at the root, with account boundaries that make spend attributable to the team that caused it.
The pipeline these platforms are delivered through — commit to production, with the gates that run on the way.
GitDesired state
GitLab CIBuild · test
Security gatesSAST · Gitleaks · Trivy
TerraformPlan · apply
Argo CDApp-of-Apps sync
EKSIstio canary
ObservabilityPrometheus · Grafana
Rollback is a git revert — the same path in reverse, not a separate runbook.
Remapping your own infrastructure?
If you are looking at a flat AWS estate, an upcoming compliance audit, or a platform that needs to move onto Kubernetes without a rewrite — this is the work I do. Discovery first, then a target architecture you can actually operate.