Platform Engineering and Infrastructure as Code on AWS
Platform Engineering and Infrastructure as Code on AWS
AWS assumes accounts are cheap and boundaries are structural, which changes the shape of a delivery platform: environments separate by account, and the pipeline crosses those boundaries deliberately. Celestique Cloud builds that structure with AWS CloudFormation, AWS CDK or Terraform, container runtimes on Amazon ECS, Amazon EKS or AWS Fargate, and guardrails that report on the whole estate rather than only on the pipeline. The first decision we help you make is which infrastructure-as-code path your team will still be maintaining in three years.
Why AWS
When this is the right platform.
- AWS CloudFormation is the substrate the rest of AWS assumes. StackSets roll a baseline across every account in an organisation, and drift detection is native rather than something you have to build.
- AWS CDK lets teams that already write TypeScript or Python define infrastructure in the language they test in, while the synthesised CloudFormation template stays reviewable as a change set before anything is applied.
- AWS Fargate removes node fleet management for container workloads, so a small platform team can run Amazon ECS or Amazon EKS services without also running an instance patching programme.
- Account-per-environment separation is the normal AWS pattern rather than an add-on, so isolating production is a structural boundary instead of a naming convention or a tag someone forgot.
- AWS Systems Manager covers the unglamorous middle ground: patch baselines, parameter storage, audited shell access without bastion hosts and commands run across accounts, which reduces the number of separate tools a platform team maintains.
Where it is less suited
We would rather say this now than after a migration.
- Raw CloudFormation becomes long and repetitive at scale. AWS CDK fixes the ergonomics but adds a build step, a dependency tree and a version upgrade path that somebody on your side has to own.
- Running Terraform and CloudFormation side by side is common and workable, but two state models need explicit ownership boundaries, otherwise a resource ends up managed by both and reconciled by neither.
- Amazon EKS carries a control plane charge per cluster plus a regular upgrade cadence. For a small number of stateless services, Amazon ECS on AWS Fargate is usually cheaper to run and cheaper to staff.
- AWS Config is easy to enable across every region and resource type, and easy to be surprised by on the invoice. Scope recording to the resource types your control set actually needs.
Business outcomes
What AWS delivers here.
- One deployment path across every account
- Teams deploying into separate development, test and production accounts use the same pipeline and the same templates, so the account boundary adds isolation without adding process. We measure the share of resource changes applied by pipeline rather than console, read from account API activity records.
- Baselines that reach new accounts on creation
- A new account arrives with logging, guardrails, deployment roles and network foundations already applied, so a project does not open with a fortnight of setup. We measure elapsed time from account request to that team's first successful deployment.
- Container platforms without a server estate
- Running services on AWS Fargate takes instance patching, scaling and capacity planning off the platform team's list entirely. We measure the share of container workloads with no customer-managed instances behind them, and the maintenance hours that returns.
- Environments rebuilt rather than restored
- If an account is lost or compromised, the environment is reconstructed from templates and pipelines instead of from a recovery process nobody has rehearsed. We measure it by rebuilding a non-production account from the repository and recording the elapsed time.
- Configuration exceptions surfaced continuously
- Risk and platform owners see non-conforming resources as they appear rather than at audit, because AWS Config evaluates the estate independently of how a change arrived. We measure open non-conformances by account and report them monthly with owners attached.
Common client problems
What we usually hear first.
We started with CloudFormation, someone introduced CDK, and a contractor left us Terraform.
We map which part of the estate each tool owns today, then set one primary path and a documented reason for every exception rather than converting everything at once. Ownership boundaries are written down so no resource ends up managed by two tools and reconciled by neither.
Every new account takes weeks of manual setup before anyone can deploy anything.
We define the account baseline as code and distribute it with StackSets, so logging, guardrails, deployment roles and networking are applied on creation. A new account then arrives ready for its first pipeline run instead of ready for a setup ticket.
Our EKS cluster costs more than the workloads running on it.
We assess each workload against what it genuinely needs and move the services that never used Kubernetes primitives to Amazon ECS on AWS Fargate. Where Amazon EKS is the right answer we right-size it, consolidate where sensible and put the upgrade cadence on a schedule rather than leaving it to surprise you.
Our build role can do anything in the account and the credentials are years old.
We replace long-lived access keys with OIDC federation from your source control provider, so the pipeline assumes a scoped role only for the duration of a run. Each deployment role is narrowed to the resources it actually touches and verified against real deployments before the old key is removed.
We turned on AWS Config, got a bill and a thousand findings, and turned it off again.
We scope recording to the resource types your control set depends on and select rules that map to a decision somebody will actually make, each with a named owner. Findings then arrive as a short, actionable list rather than a wall of noise nobody reads.
How we deliver
Our AWS delivery approach.
- 01
Assessment and advisory
The AWS decisions that matter here are about ownership and maintenance in three years, not about which tool demonstrates better. We make them with evidence from your accounts.
- Compare AWS CloudFormation, AWS CDK and Terraform against your team's languages, existing investment, hiring reality and appetite for managing state.
- Review account structure and environment separation, and identify workloads sharing an account that should not be sharing a blast radius.
- Read account API activity to establish how many resource changes currently arrive outside a pipeline, broken down by account and by role.
- Reconcile running resources against templates and state files to list what is unmanaged, duplicated or orphaned, with an owner for each item.
- Assess container workloads against Amazon ECS, Amazon EKS and AWS Fargate on cost, operational load and the primitives each workload genuinely uses.
- Produce a sequenced plan with effort, dependencies, commercial case and the two or three measures that define success.
- 02
Architecture and implementation
We build the account baseline, the pipeline and the runtime together, proving each on a real workload before it becomes the organisation's standard.
- Define the account baseline as code and distribute it with CloudFormation StackSets, so every account starts from the same foundation and stays on it.
- Build a versioned construct or module library in AWS CDK or Terraform, published with pinned versions and a tested upgrade path for consuming teams.
- Build AWS CodePipeline stages that compile and test in AWS CodeBuild, produce a reviewable change set or plan, gate on approval, then release through AWS CodeDeploy or a controlled service update.
- Stand up Amazon ECR with image scanning and immutable tags, and deploy to Amazon ECS or Amazon EKS on AWS Fargate by image digest.
- Configure remote state with locking, restricted access and a rehearsed recovery procedure wherever Terraform is used.
- Rebuild a non-production account from the repository to prove the platform end to end, and record the elapsed time as a baseline.
- 03
Security and governance
Standing credentials and over-broad deployment roles are the two findings we see most often on AWS delivery platforms. Both are cheap to fix early and expensive to fix late.
- Replace long-lived access keys with OIDC federation from your source control provider, so a pipeline assumes a scoped role only for the length of a run.
- Scope deployment roles per account and per environment, with permission boundaries that stop a pipeline granting itself more access than it was given.
- Store and rotate credentials in AWS Secrets Manager, hold non-secret configuration in AWS Systems Manager Parameter Store, and reference both at deploy and run time.
- Evaluate the estate continuously with AWS Config rules chosen to match your control set, with a named owner and a remediation decision recorded for each rule.
- Scan templates, dependencies and container images on every pull request in AWS CodeBuild, failing the build at severity thresholds you agree rather than defaults.
- Map account guardrails and pipeline controls to the framework your customers ask about, so evidence can be produced on request. We help you align to a framework rather than certify against one.
- 04
Adoption and enablement
We hand over a platform your engineers have already operated under supervision, not a repository and a wiki page with our names on it.
- Publish a starter repository with the pipeline definition, construct or module references, scanning, Amazon ECR access and role assumption already configured.
- Pair-build the first services with your engineers, so the patterns are authored by the team that will maintain them.
- Run sessions on reading a CloudFormation change set and a Terraform plan, so approvers understand the change they are gating rather than clicking through it.
- Write runbooks for stack rollback and UPDATE_ROLLBACK_FAILED, stuck state locks, failed Amazon ECS or Amazon EKS deployments and expired federation trust.
- Hand over with your team running a production release and an account rebuild while we observe and only advise.
- Report adoption as the share of resource changes arriving through the pipeline, measured against the assessment baseline.
- 05
Managed service continuation
Under an agreed managed scope we keep the AWS platform maintained, because Amazon EKS versions, AWS CDK releases, Terraform providers and base images all age whether or not anyone is watching.
- Track Amazon EKS version support windows and node group or AMI releases, scheduling upgrades before standard support ends.
- Keep AWS CDK, Terraform provider, construct, module and container base image versions current, tested in a non-production account first.
- Run scheduled drift detection across stacks and state, returning changes to code or recording accepted exceptions with an owner and review date.
- Review AWS Config findings and suppressions monthly, closing the suppressions that were only ever meant to be temporary.
- Watch pipeline duration, failure rate and build minutes in Amazon CloudWatch and act on the failures teams have learned to retry past.
- Report cost by account, environment and workload, including non-production capacity that could be scheduled off or retired.
Technology reference
The AWS services we build with.
A reference architecture view of the platform services used in this domain, and what each one does in the design.
Pipeline and build
AWS CodePipelineOrchestrates build, review, approval and release stages across separate environment accounts.
AWS CodeBuildRuns builds, tests, template synthesis, plan generation and security scanning in isolated, versioned build environments.
AWS CodeDeployManages controlled rollouts, including blue/green and canary patterns with automatic rollback conditions.
Infrastructure as code
AWS CloudFormationDeclares and applies resources, with change sets for review, StackSets for account baselines and native drift detection.
AWS CDKDefines infrastructure in TypeScript or Python as tested, reusable constructs that synthesise to reviewable CloudFormation.
TerraformDeclares infrastructure where the estate reaches beyond AWS or an existing Terraform investment should be extended.
Container build and runtime
Amazon ECRStores container images with vulnerability scanning, lifecycle rules and immutable tags.
Amazon ECSRuns container services that need scheduling, service discovery and rolling updates without Kubernetes.
Amazon EKSRuns Kubernetes workloads where the ecosystem, operators or portability justify maintaining a cluster.
AWS FargateRuns Amazon ECS and Amazon EKS tasks without customer-managed instances, removing node patching and capacity planning.
Guardrails, secrets and operations
AWS Systems ManagerHolds configuration parameters, applies patch baselines and provides audited shell access without bastion hosts.
AWS ConfigEvaluates resource configuration continuously against rules, independently of how the change was made.
AWS Secrets ManagerStores and rotates secrets and database credentials, referenced at deploy and run time rather than embedded.
Amazon CloudWatchCollects logs, metrics and alarms for pipelines, containers and platform components, including deployment failure signals.
Product names and icons are trademarks of Microsoft and Amazon Web Services, reproduced unmodified from their official architecture icon libraries to identify the technologies used in these architectures. Their presence does not indicate partnership, certification or endorsement by either vendor.
Related industries
Where this work has the most leverage.
Logistics and Warehousing
Shipment and document automation, proof-of-delivery processing and exception dashboards that let a small team run a large network.
Manufacturing and Distribution
Demand and inventory intelligence, production analytics and supplier automation built on data your planners already trust.
Professional Services
Governed enterprise search, document intelligence and secure copilots that respect matter confidentiality and conflict boundaries.
Free discovery workshop
Start with a platform engineering and iac discovery workshop.
Bring one challenge. We will assess whether AWS is the right platform for it before recommending anything.