AWS infrastructure that can survive production traffic, audit questions, and future operators.
I design Terraform-managed AWS environments with explicit account boundaries, deployment paths, cache behavior, secrets posture, and operational controls.
For teams whose AWS footprint grew organically, where infrastructure lives in the AWS console rather than in code, where IAM trust boundaries are unclear, and where an audit (or a security incident) would expose how much of the cloud posture is held together by tribal knowledge.
Who this engagement is for
Who this is for
- Teams whose AWS footprint grew organically and now needs repeatable infrastructure, clearer security boundaries, and rotation-safe credentials before scale, audit, or diligence.
- Companies preparing for SOC 2, ISO 27001, regulated-industry audit, or M&A diligence where the AWS posture has to be defensible end to end.
- Engineering teams that need an outside senior engineer to call the architecture decisions before the cloud cost or security gap becomes expensive.
- Founders or CTOs whose CI / CD currently runs with long-lived AWS keys in env vars and who want STS-only credentials end to end.
- Teams running multi-account AWS without a coherent Organization design, where account boundaries don't reflect blast radius or audit requirements.
- Companies where infrastructure lives in the console rather than in Terraform and the migration plan needs to be safe.
Who this is NOT for
- Greenfield startups with one developer and no production load. The right answer there is usually 'don't over-architect'; this engagement is for teams whose footprint already needs rationalization.
- Teams that want a one-off security audit without operational accountability for the remediation work.
- Buyers looking for a managed AWS hosting service. This is architecture + IaC + posture work, not a managed offering.
- Companies that want to migrate off AWS to a different cloud. The engagement assumes AWS as the target.
Where this engagement starts
The problem
Most AWS accounts grew organically. Someone clicked things in the console for years. Resources got created with default settings. IAM policies got copied from blog posts. Long-lived access keys ended up in a .env file somewhere. CI/CD ran as a privileged user with credentials nobody can rotate cleanly. Infrastructure-as-code coverage is partial. Drift is real. The cost dashboard is opaque.
An audit would surface how much of the cloud posture is held together by tribal knowledge. A security incident would surface how much of the blast radius is uncontrolled. A team change would surface how much of the operational knowledge lives in one engineer's head.
The fix is repeatable infrastructure in code, defined IAM trust boundaries, sovereign multi-account architecture, GitHub OIDC for CI (no long-lived keys), KMS / Secrets Manager discipline, and observability that gives operations a clear signal before incidents compound.
The approach
How this engagement runs
Audit the actual AWS posture. Specify the sovereign target architecture. Migrate the production footprint into Terraform. Replace long-lived credentials with STS-only access. Define the guardrails that keep the posture from drifting again.
AWS posture audit
Inventory the actual AWS footprint: accounts, regions, IAM users + roles + policies, network topology, data stores, secrets, observability, cost surface. Find the long-lived keys, the over-privileged roles, the click-ops drift, the security gaps.
Sovereign target architecture
Multi-account AWS Organization design: separate accounts for production, staging, audit / logging, sandbox. Defined IAM trust boundaries. KMS / Secrets Manager discipline. CloudFront / WAF posture. Observability via CloudTrail / Config / GuardDuty in a dedicated audit account.
Terraform migration
Move the production footprint from console-clicks into Terraform. Per-environment workspaces with remote state in a dedicated backend account. Importable resources where they exist; cutover plan for resources that need replacement.
STS-only credential rebuild
Replace long-lived AWS access keys with GitHub OIDC trust to AWS. Every CI / CD deploy runs as a short-lived assumed role scoped to the operations the deploy actually needs. Local-dev posture defined explicitly.
Guardrails + ongoing operation
Service Control Policies at the Org level, AWS Config rules, drift detection, cost alarms. Architectural Decision Records the team inherits. Optional Fractional CTO retainer for ongoing posture review.
Outcomes
What you walk away with
- Multi-account Org with explicit trust boundariesSovereign AWS Organization (anchor client)Source: Fine's Gallery production AWS posture (ECS Fargate + RDS + S3 + CloudFront + KMS + IAM)
- STS-only via GitHub OIDCLong-lived credentials eliminated (this site)Source: petertconti.com deploy pipeline (commit ce9708e: 'remove long-lived credentials')
- Approved client-owned design (control plane / ledger workload / audit-logging accounts)Confidential project: sovereign AWS target architectureSource: Confidential energy-sector certificate registry (Lead Architect)
- SAA + SAPAWS architecture credentialsSource: AWS Certified Solutions Architect Associate + Professional
- Roughly a third of original AWS billCost-optimization storySource: petertconti.com infra cost-opt commit c6c0c55 (drop RDS Proxy, drop NAT Gateway, downgrade RDS, reduce ECS task)
- ~25,000 LOC Terraform across 7 modulesSelf-built reference architectureSource: petertconti.com infra/ (in production for the consultancy site)
Concrete deliverables
- AWS posture audit + risk register: account inventory, IAM trust map, network topology, secret inventory, drift report, cost-surface audit, security gap analysis.
- Sovereign multi-account AWS Organization design: production, staging, audit / logging, sandbox accounts with defined trust boundaries and Service Control Policies at the Org level.
- Terraform migration of the production footprint: per-environment workspaces, remote state in a dedicated backend account, importable resources where they exist, cutover plan for the rest.
- STS-only credential rebuild: GitHub OIDC trust to AWS replaces long-lived access keys. Every CI / CD deploy runs as a short-lived assumed role scoped to the operations it actually needs.
- KMS / Secrets Manager discipline: encryption-at-rest defaults, key rotation, secret rotation, no plaintext secrets in env files or repos.
- CloudFront / WAF posture review: edge caching, web ACL configuration, origin protection, viewer-request function discipline (with the OpenNext gotcha documented if applicable).
- Observability: CloudTrail in a dedicated audit account, AWS Config rules, GuardDuty findings routed to operations, drift detection, cost alarms with thresholds the owner can act on.
- Architectural Decision Records, runbooks, and handoff documentation. The next person who has to operate this should be able to read the record and pick up where the engagement ended.
FAQ
Frequently asked questions
Yes. The audit phase identifies what's already in Terraform, what isn't, and what's drifted out of sync. The migration plan respects existing IaC and brings the rest into the same posture. Cutover doesn't require a rip-and-replace.
Not the certification process itself. This engagement makes the AWS posture audit-defensible: defined IAM trust boundaries, evidence trail, encryption discipline, observability, and the architectural records auditors actually ask for. The certification body / auditor is a separate engagement.
Recent confidential reference: Lead Architect on a regulated energy-sector certificate registry where the AWS target architecture was specifically designed to be audit-defensible end to end.
AWS Partners are usually structured around AWS service certifications, regional sales support, and Well-Architected reviews delivered by rotating teams. The engagement model is consultative.
This engagement is solo senior architecture work that owns the architecture decision and the implementation that gates it. AWS SAP + SAA credentials, real production posture in client-owned AWS Organizations, Terraform-managed end to end. The consultancy's own site runs on the same posture (~25,000 LOC Terraform, STS-only credentials, sovereign infrastructure) as a working reference architecture.
A written architecture decision document: AWS posture inventory, risk register, target-state design, Terraform migration plan, STS-only credential rebuild plan, observability + governance specification, cost-impact analysis. Delivered in 3 weeks for $15K. You can run the implementation with anyone, including yourself.
Yes, as part of the architecture work. The petertconti.com infrastructure went through a cost-optimization pass that dropped the RDS Proxy, dropped the NAT Gateway, downgraded the RDS instance, and reduced the ECS task size. Net result: roughly a third of the original AWS bill with no observable change in user-facing performance.
Cost optimization is a load-bearing engineering decision, not a separate consulting product.
Architecture sprints from $15K (3 weeks). Full Terraform migration + STS-only credential rebuild + governance work scopes after the assessment.
If the engagement scopes naturally as ongoing senior architecture governance, it usually runs as a Fractional CTO retainer at $15K/month.
Solo delivery by Peter T. Conti, AWS Solutions Architect Professional + Associate. Lead Architect on a national-scale energy-sector certificate registry (sovereign AWS target architecture). Principal engineer on the Fine's Gallery commerce platform's production AWS posture.
No agency, no offshore, no junior team. The same person who scopes the engagement runs the audit, ships the Terraform, and owns the posture.
Related work
See this in production
Peter T Conti Consulting Platform
The consulting practice's own site, built as the reference architecture for what the practice sells. Same Next.js + Payload + Postgres + ECS Fargate + Terraform stack as the anchor engagement. STS-only IAM, no long-lived credentials anywhere. Cost-tuned to run for a small fraction of the naive default AWS footprint, with full editorial workflow operated as code.
Confidential Energy Registry Architecture
Lead architect on a regulated energy-sector certificate registry. Designed and built the replacement for a managed SaaS ledger platform with a client-owned PostgreSQL system. Five database-owned write functions hold the entire authoritative mutation surface. Append-only canonical ledger with a blockchain-style UTXO model and double-entry credit/debit postings, validated by a comprehensive integration test suite against real PostgreSQL.
Fine's Gallery Platform Modernization
Solo-built end-to-end commerce platform for a luxury marble and stonework gallery. $5M+ annual revenue running on a sovereign, client-owned AWS Organization. Zero-downtime production cutover. 20+ years of legacy operational data migrated into the new platform without loss. Marketing dominance on the new platform supports $500K+/month in commerce volume. Systematic removal of vendor lock-in across SaaS commerce, payment, and warehouse tooling. Now operates on a Fractional CTO retainer.
Read more
In-depth on this topic
Stop Renting Your Revenue Engine: The Sovereign Infrastructure Blueprint for High-End E-Commerce
The goal is straightforward: you own the platform that owns your revenue.
The SaaS Ceiling: Why High-Ticket Brands Need Sovereign Commerce Infrastructure
For high-ticket ecommerce, you need infrastructure built around your business model, not the other way around.
Credentials and Fit
Directly relevant experience for high-trust delivery
I lead architecture and implementation personally, with technical depth that spans product, cloud, and execution operations.
AWS Certified Solutions Architect - Associate
Cloud decisions are grounded in secure, cost-aware architecture with practical production tradeoff management.
Dual technical foundation
B.S. Computer Science plus B.S. Chemistry with undergraduate research and scientific presentation discipline.
AWS Certified Solutions Architect - Professional
My ability to use AWS to solve complex business requirements has been demonstrated at the highest enterprise level.
Cloud Infrastructure Inquiry
Share your current hosting footprint, traffic bottlenecks, and compliance requirements so I can map a deterministic cloud hardening plan.
Pressure-test the platform decision before you commit budget.
Schedule a complimentary 30-minute consultation to align on objectives, stress-test your architecture, and leave with a concrete set of recommendations. No obligation, no sales pitch. Just actionable technical guidance.