Skip to main content
Celestique Cloud

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. The organisation structure the pipeline deploys into is landing zone work and sits below this.

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 as an estate grows. AWS CDK fixes the ergonomics and 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.
  • CloudFormation's failure modes are the ones that cost a weekend. A stack that lands in UPDATE_ROLLBACK_FAILED needs manual intervention, imported resources drift quietly, and nested stacks make the blast radius of one bad change larger than the change itself.
  • Amazon EKS carries a control plane charge per cluster, and once a minor version leaves standard support that charge rises several times over for the extended support window. Falling a version behind is a cost event, not only a risk. 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.
  • The AWS developer tools have had an unsettled few years: new access to CodeCommit was closed in 2024 and reopened at the end of 2025. Most estates we see host source in GitHub or GitLab and use CodePipeline and CodeBuild for the AWS-side work, and that is the arrangement we would default to.

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.Agreed measure: 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.Agreed 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.Agreed measure: 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.Agreed measure: Elapsed time to rebuild a non-production account from the repository, established by rehearsing it rather than estimating.
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.Agreed measure: Open configuration non-conformances by account, reported monthly with an owner attached to each.

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, because once a version leaves standard support the control plane charge rises sharply for the extended support window.

  • 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.

  1. 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.

    • CloudFormation, CDK or Terraform. Compared against your team's languages, existing investment, hiring reality and appetite for managing state, then recorded as a decision with its trade-offs.
    • Account separation and blast radius. Environment separation reviewed, with workloads sharing an account that should not be sharing a failure identified explicitly.
    • API activity read for console changes. Account API activity used to establish how many resource changes currently arrive outside a pipeline, broken down by account and by role.
    • Resources reconciled to templates. Running resources checked against templates and state files to list what is unmanaged, duplicated or orphaned, with an owner for each item.
    • Container runtime chosen per workload. Amazon ECS, Amazon EKS and AWS Fargate assessed on cost, operational load and the Kubernetes primitives each workload genuinely uses.
    • Sequenced plan with a commercial case. Effort, dependencies, cost and the two or three measures that define success, ordered so the first increment stands on its own.
  2. 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.

    • Account baseline distributed as code. The baseline defined as code and rolled out with CloudFormation StackSets, so every account starts from the same foundation and stays on it.
    • A published construct or module library. Versioned AWS CDK constructs or Terraform modules published with pinned versions and a tested upgrade path for the teams consuming them.
    • Change set or plan before approval. AWS CodePipeline stages 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.
    • Registry hardened, deployed by digest. Amazon ECR configured with image scanning and immutable tags, with deployment to Amazon ECS or Amazon EKS on AWS Fargate pinned to an image digest.
    • State locked without a side table. Terraform state kept in Amazon S3 using the backend's own conditional-write lock, since the DynamoDB locking arguments are now deprecated, with access restricted and recovery rehearsed.
    • Proven by an account rebuild. A non-production account rebuilt from the repository end to end to prove the platform, with the elapsed time recorded as a baseline.
  3. 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.

    • OIDC federation, no access keys. Long-lived keys replaced with OIDC federation from your source control provider, so a pipeline assumes a scoped role only for the length of a run.
    • Roles bounded per account. Deployment roles scoped per account and per environment, with permission boundaries that stop a pipeline granting itself more access than it was given.
    • Secrets and parameters separated. Credentials stored and rotated in AWS Secrets Manager, non-secret configuration held in Systems Manager Parameter Store, and both referenced at deploy and run time.
    • Config rules chosen, not switched on. AWS Config rules selected to match your control set, each with a named owner and a recorded remediation decision, rather than every managed rule enabled at once.
    • Scanning with thresholds you agree. Templates, dependencies and container images scanned on every pull request in AWS CodeBuild, failing the build at severity thresholds you set rather than defaults.
    • Controls mapped to your framework. Account guardrails and pipeline controls mapped 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.
  4. 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.

    • A starter repository to clone. Pipeline definition, construct or module references, scanning, Amazon ECR access and role assumption already configured, so a new service starts deployable.
    • First services built in pairs. The first services written with your engineers, so the patterns are authored by the team that will maintain them afterwards.
    • Approvers taught to read change sets. Sessions on reading a CloudFormation change set and a Terraform plan, because an approval given without understanding the diff is a control on paper only.
    • Runbooks for AWS-specific failures. Stack rollback and UPDATE_ROLLBACK_FAILED, stuck state locks, failed Amazon ECS or Amazon EKS deployments and expired federation trust.
    • Hand-over by doing, while we watch. Your team runs a production release and an account rebuild while we observe and only advise.
    • Pipeline share tracked, not asserted. The proportion of resource changes arriving through the pipeline reported against the baseline captured during assessment.
  5. 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.

    • EKS support windows tracked. Version support windows and node group or AMI releases watched, with upgrades scheduled before standard support ends and the extended support charge begins.
    • Versions kept current and tested. AWS CDK, Terraform provider, construct, module and container base image versions updated on a cadence and tested in a non-production account first.
    • Drift detected across stacks and state. Scheduled drift detection, with each change either returned to code or recorded as an accepted exception carrying an owner and a review date.
    • Config suppressions closed off. AWS Config findings and suppressions reviewed monthly, closing the suppressions that were only ever meant to be temporary.
    • Pipeline failures acted on. Duration, failure rate and build minutes watched in Amazon CloudWatch, with the failures teams have learned to retry past treated as defects.
    • Cost reported by account. Spend broken down by account, environment and workload, including non-production capacity that could be scheduled off or retired.

Reference architecture

An AWS delivery platform, layer by layer.

How the pieces fit together on AWS. Every engagement adapts this, and we will tell you which layers you already have.

  1. 01

    Source and review

    Required review and code ownership before anything reaches a build.

    • GitHub or GitLab
    • Branch protection and CODEOWNERS
    • OIDC trust into AWS
  2. 02

    Build and synthesise

    Templates synthesised, plans generated and images built in one audited place.

    • AWS CodeBuild
    • cdk synth or terraform plan
    • Amazon ECR image build
  3. 03

    Approve

    A change set or saved plan reviewed by someone other than its author.

    • Change set or saved plan
    • Manual approval action
    • Second reviewer
  4. 04

    Deploy across accounts

    The account boundary crossed deliberately, with a scoped role each time.

    • AWS CodePipeline
    • Cross-account deployment roles
    • CloudFormation StackSets
  5. 05

    Run and observe

    Where the workload runs, and what catches a change the pipeline never saw.

    • Amazon ECS or EKS on AWS Fargate
    • Amazon CloudWatch
    • AWS Config rules

Across every layer

  • OIDC federation instead of long-lived access keys
  • Permission boundaries on every deployment role
  • Every layer defined in version-controlled code
  • Cost reported by account and environment
Layer 04 is where AWS platforms are quietly compromised. Running the pipeline inside the production account is faster on day one, and it hands the account you bought for isolation a role that can rebuild it, so the boundary you paid for stops existing. Layer 05 is the other skipped one: AWS Config is what tells you about the change nobody put through the pipeline.

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.
  • GitHubHosts repositories, pull requests and required review, and issues the OIDC token a pipeline exchanges for a scoped AWS role.

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, identity and secrets

  • AWS Identity and Access ManagementHolds the federated deployment roles a pipeline assumes, with permission boundaries limiting what any run can grant itself.
  • 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.

AWS questions

What people ask about doing this on AWS.

Cost, lock-in and the parts that go wrong, answered before you have to ask twice.

  • CloudFormation, AWS CDK or Terraform? Which one should we standardise on?

    If your team already writes TypeScript or Python and will keep engineers who do, CDK gives the best ergonomics and you accept owning a build step and an upgrade path. If the estate reaches beyond AWS, or Terraform is already in the building, Terraform is usually the answer and state becomes an operational responsibility. Plain CloudFormation is still the right call for account baselines and StackSets whatever else you pick. What we will not do is run all three, because a resource managed by two tools is reconciled by neither.

  • Why is our EKS bill going up when nothing changed?

    Most often because a Kubernetes minor version left standard support. The control plane charge for a cluster on extended support is several times the standard rate, and it applies per cluster per hour whether or not anyone noticed the transition. Consolidating clusters helps, but the real fix is putting the upgrade cadence on a schedule with an owner. If the workloads on the cluster never used Kubernetes primitives, the cheaper answer is moving them to Amazon ECS on AWS Fargate and retiring the cluster.

  • Do we still need a DynamoDB table for Terraform state locking?

    No. The S3 backend now takes a lock using a conditional write against the state bucket itself, and the DynamoDB locking arguments are deprecated and slated for removal. If you have an existing setup, both can run together during the changeover, which is the migration path we use. Worth being clear that this changes where the lock lives, not whether you need one: a concurrent apply without a lock is still how state gets corrupted.

  • Can we run the pipeline in the same account as production?

    You can, and we would advise against it. The deployment role has to be trusted from somewhere, and if that somewhere is production then the account you separated for isolation now hosts a role that can rebuild it. Putting the pipeline in its own account and assuming a scoped role per target account costs almost nothing and keeps the boundary you bought accounts for. The cost is a little more IAM to reason about, which is the trade we recommend making.

  • AWS Config cost us a fortune last time. How do you scope it?

    By deciding what you will act on before switching anything on. Recording is scoped to the resource types your control set depends on rather than every type in every region, and rules are selected where a finding maps to a decision somebody will actually make, each with a named owner. Configuration item recording and rule evaluations are both billable, so a broad enablement across many accounts and regions is genuinely expensive. We estimate it at your account count rather than at one account.

  • Should we build this with our own AWS engineers instead?

    If you have engineers with real CloudFormation or Terraform depth and the capacity to spend on it, often yes, and we will tell you so. Where in-house builds tend to stall is the unglamorous half: cross-account role design, permission boundaries, state recovery, the exception register, upgrade cadence. Those decide whether the platform is still trusted in two years. A useful middle option is that your team builds and we review the design and the IAM before it becomes the standard.

  • Is the AWS Code suite a safe thing to build on?

    CodePipeline and CodeBuild are widely used and we are comfortable building on them, particularly for the cross-account deployment work where being inside AWS IAM is an advantage. We are more cautious about the source hosting: new access to CodeCommit was closed in 2024 and reopened at the end of 2025, which is not a pattern that inspires long-term confidence. Our default is source and review in GitHub or GitLab, with CodePipeline and CodeBuild doing the AWS-side work, which also keeps the pipeline replaceable.

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.

Book a Free Discovery WorkshopGet in Touch