Cloud platforms · AWS and Azure

CI/CD and infrastructure as code with GitHub Actions, Terraform, ECR and blue/green

A delivery pipeline with no long-lived credentials: pull requests plan, merges apply, images are scanned and signed, and releases shift traffic gradually with automatic rollback.

A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.

  • ACSC Essential Eight
  • SA ISMF and ACSC ISM alignment
  • Secure development practices

Architecture

Architecture diagram. Tinted boundaries show regions, accounts, networks and trust zones. Numbered arrows match the flow below.
CI/CD and infrastructure as code with GitHub Actions, Terraform, ECR and blue/green architectureDeveloper to Repository: PR. Repository to GitHub Actions: trigger. GitHub Actions to Scan and test: gates. GitHub Actions to Amazon ECR: push image. GitHub Actions to Terraform: plan / apply. Terraform to S3 state + lock: state. Amazon ECR to CodeDeploy: image. CodeDeploy to ECS service: shift traffic. CloudWatch alarms to CodeDeploy: rollbackGitHubAWS accounts (tooling, non-prod, prod)DeveloperPull requestRepositoryBranch protection, CODEOWNERSGitHub ActionsOIDC, environmentsScan and testSAST, SCA, secrets, IaC checksAmazon ECRImmutable tags, scan on pushTerraformPlan on PR, apply on mergeS3 state + lockVersioned, KMSCodeDeployBlue/green, canary, alarmsECS serviceBlue and green target groupsCloudWatch alarmsTrigger rollback1PR2trigger3gates4push image5plan / applystate6image7shift traffic8rollbackPlatform servicesAWS IAMAmazonCloudWatchAWS CloudTrailAWS KMS
  • People and clients
  • Delivery tooling
  • AI and ML
  • Compute and containers
  • Object and file storage
  • Monitoring, audit and analytics
  • Security and identity
  • Request or data flow
  • Asynchronous or optional
  • Boundary: region, account, network or trust zone

Request and data flow

  1. A developer opens a pull request. Branch protection requires review, status checks and signed commits for protected branches.

  2. The workflow starts and requests an OIDC token from GitHub. AWS trusts only this repository, branch or environment through the IAM role trust policy.

  3. Unit tests, static analysis, dependency and secret scanning, and IaC policy checks (for example Checkov or OPA) run as gates.

  4. A successful build pushes an image tagged with the commit SHA to ECR. Scan on push findings above the agreed threshold fail the release.

  5. Terraform plans on the pull request and posts the plan. On merge to main it applies in non-production, then production after an environment approval.

  6. CodeDeploy or the ECS deployment controller registers the new task set with the load balancer as the green environment.

  7. Traffic shifts in a canary or linear pattern while health checks and test listeners validate the release.

  8. CloudWatch alarms on error rate and latency trigger an automatic rollback to the blue task set if breached.

Components and why they were chosen

ComponentWhat it doesWhy this choice
GitHub repository and branch protectionSource of truth, code review and required checks.Review and status checks are the control that stops unreviewed change reaching production.
GitHub Actions with OIDCRuns the pipeline and obtains short-lived cloud credentials.Eliminates stored cloud keys. Use Azure federated credentials in the same way.
Terraform (or CDK or Bicep)Declarative infrastructure with plan and apply.Plan output is reviewable. Choose one tool per platform to avoid drift between tools.
S3 backend with lockingRemote state with versioning and encryption.Protects state, which can contain secrets.
Amazon ECRPrivate image registry with scanning and lifecycle rules.Native to ECS and IAM, with immutable tags for traceability.
AWS CodeDeploy (ECS blue/green)Traffic shifting with hooks and alarms.Automatic rollback is the main safety net.
Checkov, tfsec or OPAPolicy-as-code for IaC.Catches public buckets and wildcard IAM before they are deployed.
Image signing (Cosign or AWS Signer)Proves that an image came from the pipeline.Admission checks can refuse unsigned images.

Design decisions and trade-offs

Credentials

OIDC federation with branch and environment conditions.

Why. No secrets to leak or rotate.

Trade-off. Trust policy conditions must be precise or any workflow in the org could assume the role.

Release strategy

Blue/green with canary traffic shifting.

Why. Fast rollback and real-traffic validation.

Trade-off. Double capacity during rollouts and database changes must be backward compatible.

Environment promotion

Build once, promote the same image digest.

Why. What you tested is what you ship.

Trade-off. Configuration must be injected per environment, never baked in.

IaC apply

Apply from the pipeline only, humans read-only.

Why. Eliminates console drift and gives an audit trail.

Trade-off. Emergency changes need a break-glass process that is then reconciled in code.

Well-architected pillars

Security

OIDC, least-privilege deploy roles, scans as gates, signed artefacts, protected branches and environment approvals.

Reliability

Gradual traffic shifting, automated rollback and backward-compatible database migrations (expand then contract).

Performance

Cached builds, parallel jobs and a small test pyramid keep lead time in minutes.

Cost optimisation

Runner minutes, ECR storage and the temporary double capacity during blue/green.

Operational excellence

DORA metrics (deployment frequency, lead time, change failure rate, time to restore) tracked from the pipeline.

Sustainability

Cache dependencies, lifecycle old images and use ephemeral runners.

Network, identity and data

Networking

Self-hosted runners, if used, live in a private subnet with endpoints and no inbound access. Production deploy roles can only be assumed from the production environment in the workflow.

Identity and least privilege

Separate IAM roles per account and per purpose: plan (read-only), apply (scoped), deploy (ECS and CodeDeploy only). Trust policies pin repo, ref and environment claims. GitHub environments hold required reviewers.

Data and encryption

State files and build logs are encrypted and access-limited. Secrets are fetched at runtime from Secrets Manager or Key Vault, never written to logs or artefacts.

Security and compliance mapping

ControlHow this design addresses it
Application controlOnly signed pipeline-built images are deployable. Essential Eight application control principle.
Patch applicationsScheduled base-image rebuilds and dependency updates through automated pull requests. Essential Eight.
Restrict administrative privilegesHumans have read-only access to production. Essential Eight.
Change managementPull-request approval and plan output provide evidence for ISMF change control expectations.

Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.

Failure modes, targets and scaling

  • Target RTOMinutes to roll back a release
  • Target RPONot applicable to code; state is versioned
  • Scaling and limitsParallel pipelines per service. Watch runner concurrency and IAM role session limits.
Failure modeMitigation
Pipeline compromiseOIDC conditions, pinned third-party actions by SHA, least-privilege roles and approvals for production.
Bad release reaches usersCanary stage with alarms triggers automatic rollback.
Terraform state lost or lockedVersioned bucket, DynamoDB or S3-native locking and a documented unlock procedure.
Incompatible database migrationExpand and contract pattern, with migrations run as a separate reversible step.

Observability and runbooks

  • Pipeline duration, failure rate and flaky test dashboard.
  • Deployment events annotated on service dashboards.
  • Alarm: any apply outside the pipeline (detected by CloudTrail principal).

Cost drivers and levers

CI minutes, artefact storage and extra capacity during blue/green.

  • Cache builds and use path filters.
  • Lifecycle rules in ECR.
  • Shorten canary windows for low-risk changes.
  • Use larger runners only where they cut total time.

Implementation and fit

Phased approach

  1. Get one service building and deploying from the pipeline with OIDC.
  2. Add scanning gates, plan on PR and environment approvals.
  3. Introduce blue/green and alarms.
  4. Roll the template out to the other services and retire manual deploys.

Anti-patterns to avoid

  • Long-lived access keys in CI secrets.
  • Deploying from developer laptops.
  • Rebuilding different images per environment.
  • Third-party actions referenced by mutable tags.

When to use it

  • Any team shipping to production more than occasionally.
  • Environments that need an audit trail of change.

When not to

  • One-off scripts with no ongoing ownership (the process cost will not pay back).

More in cloud platforms

Related insights

Discuss this architecture

Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.

Start a conversationCall 0402 401 584