AWS CLOUD-NATIVE DEVOPS

GitOps CI/CD Suite

A modular deployment engine using GitHub Actions and AWS CodeSuite, featuring automated canary deployments and rollbacks for marciobolsoni.cloud.

EXPLORE PIPELINEDEPLOYMENT GUIDE
4
GITHUB WORKFLOWS
80.1%
SLA UPTIME %
2
ROLLBACK TRIGGERS
8%
CANARY % INITIAL
SCROLL
SECTION 01

Pipeline Explorer

Click any stage to explore its role in the deployment engine, configuration details, and tooling.

SELECT A STAGE
Click any pipeline stage above to explore its configuration and role
PIPELINE FLOW
COMMIT→CI→BUILD→STAGING→APPROVAL→CANARY→PRODUCTION
SECTION 02

GitHub Actions Workflows

Five purpose-built workflows covering the full software delivery lifecycle — from pull request validation to production rollback.

TRIGGER: Pull Request

Continuous Integration

ci.yml

Runs on every pull request to main. Performs linting, unit tests, security scans, Docker build, and Terraform plan with a PR comment.

WORKFLOW STEPS
1
Checkout & Setup
actions/checkout
2
Lint & Unit Tests
pytest / eslint
3
Trivy Container Scan
aquasecurity/trivy
4
Checkov IaC Scan
bridgecrewio/checkov
5
Snyk Dependency Audit
snyk/actions
6
Docker Build & Push ECR
aws-actions/ecr
7
Terraform Plan
hashicorp/setup-terraform
SECTION 03

Canary Deployment Strategy

AWS CodeDeploy shifts traffic progressively using ECSCanary10Percent5Minutes. Five CloudWatch alarms act as automated rollback triggers.

TRAFFIC DISTRIBUTION
MONITORING
NEW VERSION10%
STABLE VERSION90%
CODEDEPLOY CONFIG
deploymentConfig: ECSCanary10Percent5Minutes
trafficRoutingConfig: CANARY
canaryInterval: 5 minutes
autoRollbackEnabled: true
ROLLBACK TRIGGER ALARMS

Any alarm breach during the canary bake period triggers an automatic rollback via CodeDeploy.

HTTP 5xx Rate
Threshold: > 1%
CRITICAL
P99 Latency
Threshold: > 2s
CRITICAL
ECS CPU
Threshold: > 85%
WARNING
ECS Memory
Threshold: > 90%
WARNING
Running Tasks
Threshold: < min
CRITICAL
ROLLBACK PIPELINE
ALARM BREACH→STOP DEPLOY→ECS REDEPLOY→HEALTH CHECK→NOTIFY
SECTION 04

Security Model

A defense-in-depth approach following AWS Well-Architected Framework principles — zero long-lived credentials, supply chain scanning, and network isolation.

01

OIDC Authentication

Zero Long-Lived Credentials

GitHub Actions authenticates to AWS using OpenID Connect (OIDC). No AWS access keys are stored in GitHub Secrets — the IAM role is assumed dynamically per workflow run via a short-lived token.

→GitHub OIDC Provider in AWS IAM
→IAM Role with condition: token.actions.githubusercontent.com
→Least-privilege policy per workflow
→Automatic token expiry after job completion
SECURITY COMPLIANCE CHECKLIST
✓OIDC Auth (no static keys)
✓Private Subnets
✓TLS in Transit
✓Security Group Rules
✓No Hardcoded Secrets
✓Trivy Scan
✓Checkov IaC Scan
✓Snyk Audit
✓CloudTrail Logging
✓KMS Encryption
SECTION 05

Infrastructure as Code

The entire AWS infrastructure is defined in Terraform, organized into four reusable modules. Remote state is stored in S3 with DynamoDB locking.

TERRAFORM MODULE

Network Foundation

◈Multi-AZ VPC (3 AZs)
◈Public / Private / Data subnets
◈NAT Gateways (per AZ)
◈VPC Flow Logs
◈Network ACLs
FILE PATH
infrastructure/terraform/
modules/vpc/main.tf
REMOTE STATE
# backend.tf
backend "s3" {
bucket = var.TF_STATE_BUCKET
key = "prod/terraform.tfstate"
encrypt = true
dynamodb_table = var.TF_LOCK_TABLE
}
SECTION 06

Deployment Guide

Five steps to get the GitOps CI/CD Suite running in your AWS account. Prerequisites: AWS account, GitHub repository, and the required secrets configured.

STEP 01

Configure AWS OIDC

Create an IAM OIDC provider for GitHub Actions and an IAM role with the required permissions. Store the role ARN in GitHub Secrets as AWS_ROLE_ARN.

# Create OIDC provider
aws iam create-open-id-connect-provider \
--url https://token.actions.githubusercontent.com \
--client-id-list sts.amazonaws.com
⚠
REQUIRED GITHUB SECRETS
AWS_ROLE_ARNTF_STATE_BUCKETTF_LOCK_TABLESLACK_WEBHOOK_URLSNYK_TOKEN