Provisioning AWS solutions in minutes with Infra as Github Actions

I remember those days when I created infra by clicking in the console 😬 eventually that became a nightmare to manage and infra as code came to save the day 🦸 but with that, it also started an awkward phase of coupling infra code and app code
Some platform teams decided to move infra code to their own repos, that worked, specially for access control, but that required exceptions like:

• Ignoring the image version since it was going to be managed by the app pipeline
• The awkward environment variables setup

I've been searching for ways to bring infra back infra code to app repos

The first experiment was to keep network and LBs and move ECS services with Fargate to the app repo, this continuous to work surprisingly well after 3 years, environment variables changes are in the same PR as app that depended on it, another advantage was that terraform itself managed the newly built docker image tag. However, app developers rarely touched most of the terraform code, as terraform requires significant effort to learn, there has to be a better way 🤔

Entering Infra as GitHub Actions

With just a few line of YML, we can create pretty complex depended workflows, what if we can use Github Actions to compose infra?

I write a couple of actions that will provision the S3, CloudFront and Route53 with fairly simple steps:

• Login to AWS
• Setup the Backend
• Provision the website

The whole workflow relies on only 3 inputs- Instance name: an identifier for the infra- Domain: DNS for the website, you need to own it on Route53- Path: content to publish as root on the website

permissions: 
  id-token: write
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repo
        uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: us-east-1
          role-to-assume: ${{ secrets.ROLE_ARN }}
          role-session-name: ${{ github.actor }}
      - uses: alonch/actions-aws-backend-setup@main
        with: 
          instance: demo
      - uses: alonch/actions-aws-website@main
        with: 
          domain: ${{ env.DOMAIN }}
          content-path: public

How it works

When a GitHub Action job is initialized, it checks out its source code from the repo, this unlocks interesting capabilities, for example: an action could apply terraform as if the terraform code is part of the current repo

actions-aws-backend-setup (repo)

  - uses: alonch/actions-aws-backend-setup@main
    with: 
      instance: demo

This action requires a custom instance name to query AWS by tag, we need to find the S3 and Dynamodb to setup the terraform backend

In case where it doesn’t exist, it will provision it and setup the environment variables:

• TF_BACKEND_s3: bucket name
• TF_BACKEND_dynamodb: table name

actions-aws-website (repo)

      - uses: alonch/actions-aws-website@main
        with: 
          domain: ${{ env.DOMAIN }}
          content-path: public

This action assumes the backend setup has run, and it requires a domain and the path to the content that needs to be publish as the website
Similar to the backend action, GitHub checks the source code which includes the terraform code to provision a Bucket, Cloudfront, Certificate and route53 routes
Using Github Actions is incredible flexible as the only dependency is on the AWS role and the backend instance name, in the case were we need to upgrade the infra, we just need to tag the new action version and terraform will sync the resources to the latest desired state

New degree of freedom

With Infra as Github Actions we basically can achieve ephemeral environments with a 31 lines of YML

name: Deploy Ephemeral Environment
on:
  pull_request:
    types: [opened, synchronize, reopened, closed]
env: 
  DOMAIN: ${{github.head_ref}}.test.realsense.ca
permissions: 
  id-token: write
jobs:
  deploy:
    environment:
      url: "https://${{ env.DOMAIN }}"
      name: ${{github.head_ref}}
    runs-on: ubuntu-latest
    steps:
      - name: Check out repo
        uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: us-east-1
          role-to-assume: ${{ secrets.ROLE_ARN }}
          role-session-name: ${{ github.actor }}
      - uses: alonch/actions-aws-backend-setup@main
        with: 
          instance: demo
      - uses: alonch/actions-aws-website@main
        with: 
          domain: ${{ env.DOMAIN }}
          content-path: public
          # destroy when PR closed
          action: ${{github.event.action == 'closed' && 'destroy' || 'apply'}}

This will create a new infra for that PR, update it in sync and destroy it when the PR is closed

What’s next?

This is just the beginning, I believe GitHub actions dependency could be use to compose and orchestre complex infra with simple interfaces
I'm considering building:

• actions-aws-http-lambda: Serverless API from folder path
• actions-aws-edge-auth: Website behind social media login from client secrets
• actions-aws-http-server: Web hosting from docker image

What do you think? What should I focus on next?