DEV Community: Trent Hornibrook

From the Developer Lounge: Building a Secure Container Pipeline with Amazon Inspector & GitHub Actions at AWS Sydney Summit 2025

Trent Hornibrook — Fri, 06 Jun 2025 06:39:19 +0000

This week at the AWS Summit Sydney 2025 I had the privilege of speaking in the Developer Lounge about a topic that’s close to my heart: baking security straight into the CI pipeline.
In this post I’ll recap the session and leave you with practical next-steps you can put into production today.

TL;DR
Scan early, scan often, scan cheaply. With Amazon Inspector, GitHub Actions, and a few well-placed network controls you can catch vulnerabilities before they ever reach a cluster—often for around $0.01 a scan and in ~10 seconds.

Why Container Security Still Hurts 🔍

87 % of production container images contain critical or high-severity vulnerabilities (Sysdig Cloud-Native Security Report 2023). The reasons are familiar:

Upstream code moves fast – new CVEs land daily.
Images live long – they’re rebuilt far less frequently than source.
Runtime drift is opaque – knowing exactly what’s running when a zero-day drops is hard.

The goal: bring continuous, automated vulnerability insight into the developer feedback loop, instead of treating it as an after-thought.

The Stack I Showcased ⚙️

Layer	What We Used	Why It Matters
CI	GitHub Actions	Native for most teams; easy to extend with Marketplace actions.
Scanning	Amazon Inspector GitHub Action	Full CVE scan + SBOM (CycloneDX) creation in one step.
Scheduling	GitHub Actions – cron	Daily rebuilds keep “known-good” images fresh.
Cost	≈ AUD 0.015 / scan	Cheap enough to run every build.
Network guard-rails	VPC Interface Endpoints, AWS Network Firewall & Route 53 DNS Firewall	Ensure only approved images are pulled, and egress is controlled.
Posture visibility	AWS Security Hub	See which ECR images are vulnerable.
Dependency hygiene	Renovate Bot	Automated PRs to keep base images & libraries current.
AI code reviews	Amazon Q Developer for GitHub (preview)	Inline suggestions & security insights on every PR.

All the code is open-source here → https://github.com/tnhtnh/container-pipeline-sydney-summit-2025

Walkthrough: The Secure Pipeline in Action 🚀

1. Set the risk for the workload

env:
  AWS_REGION: ${{ vars.AWS_REGION || 'ap-southeast-2' }}
  ECR_REPOSITORY: ${{ vars.ECR_REPOSITORY || 'my-ecr-repo' }}
  CRITICAL_THRESHOLD: ${{ vars.CRITICAL_THRESHOLD || 0 }}
  HIGH_THRESHOLD: ${{ vars.HIGH_THRESHOLD || 0 }}
  MEDIUM_THRESHOLD: ${{ vars.MEDIUM_THRESHOLD || 10 }}
  LOW_THRESHOLD: ${{ vars.LOW_THRESHOLD || 10 }}
  OTHER_THRESHOLD: ${{ vars.OTHER_THRESHOLD || 20 }}

2. Build the Image


      - name: Build Docker image
        uses: docker/build-push-action@v6
        with:
          context: .
          file: ./Dockerfile
          push: false
          build-args: |
            GIT_SHA=${{ github.sha }}
          tags: |
            ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}

3. Scan with Amazon Inspector

      - name: Scan built image with Inspector
        uses: aws-actions/vulnerability-scan-github-action-for-amazon-inspector@v1
        id: inspector
        with:
          artifact_type: 'container'
          artifact_path: '${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}'
          critical_threshold: ${{ env.CRITICAL_THRESHOLD }}
          high_threshold: ${{ env.HIGH_THRESHOLD }}
          medium_threshold: ${{ env.MEDIUM_THRESHOLD }}
          low_threshold: ${{ env.LOW_THRESHOLD }}
          other_threshold: ${{ env.OTHER_THRESHOLD }}

Average runtime during the demo: *~10 seconds***.

4. Fail the job if it exceeds my risk threshold

      - name: Fail job if vulnerability threshold is exceeded
        run: exit ${{ steps.inspector.outputs.vulnerability_threshold_exceeded }}

Pro tip: Add a scheduled workflow (schedule: cron: "0 2 * * *") to rebuild daily. If a new CVE surfaces, the pipeline fails and you’re notified immediately—long before it hits prod.

Beyond CI: Defence-in-Depth 🛡️

Control	What It Does	Quick Win
VPC Interface Endpoints (ECR)	Keep image pulls on private links; block public Internet.	Enable `com.amazonaws.<region>.ecr.dkr` in your build VPC.
AWS Network Firewall	Enforce allow-lists / Suricata rules for egress.	Deny outbound traffic to public Docker Hub.
Route 53 DNS Firewall	Policy-based DNS filtering.	Block wildcard `*.docker.io` except the repos you explicitly mirror.

Combine these with Security Hub’s Inspector container findings to answer, “Which running tasks are based on image X?” in seconds.

Cost & Performance Numbers 💰

Item	Cost (Sydney)	Notes
On-demand image scan	≈ AUD 0.015	First 1000 / mo on Free Tier.
Continuous re-scan	≈ AUD 0.003	When using ECR continuous scanning.
Build time impact	+ ~10 s	Scales with image size; cache your layers!

For most teams the spend is pennies compared to the blast-radius of shipping a vulnerable container.

Pulling It All Together 🧩

Fork the demo repo and adapt the workflow to your project.
Set your thresholds—zero criticals in prod, relaxed for dev.
Schedule daily (or hourly) rebuilds to detect new CVEs fast.
Lock down egress with VPC endpoints & firewalls.
Enable Security Hub for a single pane of glass across Inspector, GuardDuty, and more.
Let Renovate & Amazon Q Developer keep dependencies—and your colleagues—honest.

Follow me on LinkedIn for updates, and if you tried the pipeline, tell me how it went—I’d love to feature real-world lessons in a future post!

✨ Resources

GitHub repo – https://github.com/tnhtnh/container-pipeline-sydney-summit-2025
AWS Blog – Inspector ↔️ running-container mapping announcement https://aws.amazon.com/blogs/aws/amazon-inspector-enhances-container-security-by-mapping-amazon-ecr-images-to-running-containers/
Amazon Q Developer for GitHub (preview) https://aws.amazon.com/blogs/aws/amazon-q-developer-in-github-now-in-preview-with-code-generation-review-and-legacy-transformation-capabilities/

🙏 A big Thank You

Thank you to Community Builders team, especially Shafraz Rahim for allowing me to share my knowledge on container security to the group at Summit. And thank you to Stephen Sennett for being the Community Builder Community Advocate for the class of AWS Sydney Summit 2025!

Final Thoughts

Security shouldn’t slow developers down—it should empower them to ship with confidence.
With Amazon Inspector costing about the same as a few kilobytes of S3 storage, there’s no excuse not to give every container the green light before it heads to production.

See you at the next event, and happy (secure) building!

Amazon Q Developer: A Follow-up Experience with Code Transformation

Trent Hornibrook — Tue, 06 May 2025 05:32:03 +0000

I recently experimented with Amazon Q Developer for GitHub, testing its ability to transform code from one language to another. While Amazon Q Developer shows promise, my experience revealed some interesting limitations in its current preview state.

The Project: EC2 Underutilization Report Tool

My test case involved Alok Shankar's EC2 underutilization reporting tool - a clever Bash script that identifies idle EC2 instances to reduce AWS costs. The original script:

Collects 7-day average CPU usage from CloudWatch
Gathers memory metrics when CloudWatch Agent is configured
Captures EC2 metadata (ID, type, Name tag)
Generates downsizing recommendations
Sends HTML email reports with CSV attachments

This tool represented an ideal candidate for transformation - a useful utility written in Bash that could benefit from Python's improved maintainability, error handling, and testability.

My Experience with Amazon Q Developer

After forking the repository to my GitHub account, I created Issue #1 with detailed requirements for transforming the script to Python. My prompt was comprehensive, requesting:

Complete rewrite in Python for better reliability
Preservation of output format
Addition of pytest unit tests
Enhanced metrics collection beyond CPU
More actionable cost-saving recommendations
Adherence to Python best practices

I then added the "Amazon Q transform agent" label to engage the AI assistant.

Unexpected Results

What happened next was surprising. Instead of addressing my Python transformation request:

Amazon Q Developer immediately responded: "I'm getting ready to upgrade your code to Java 17"
It attempted to run a GitHub Actions workflow for a Java/Maven project
When this failed, it requested I configure a Java workflow configuration
The entire context of my transformation request was seemingly ignored

Amazon Q Developer: Key Limitations and Lessons

The Transform agent: Surprisingly, despite being labeled as a general "transform agent," Amazon Q Developer appears primarily designed for Java upgrades. The label "Amazon Q transform agent" should be updated to clearly indicate "Amazon Q Java transform agent" to avoid confusion.

Takeaways

The concept remains promising - automated code transformations via GitHub issues could dramatically improve developer productivity.

Hands-On with Amazon Q Developer in GitHub: Building an AWS SAM App from Scratch

Trent Hornibrook — Mon, 05 May 2025 22:27:55 +0000

Introduction

In mid-April, I blogged about leveraging cloud and generative AI to maximize developer productivity. Among other areas, I highlighted the potential of AI in the PR Review/Gitflow process, suggesting tools like Evolua.io or CodeRabbit to offload routine code reviews and low-value fixes to AI assistants.

Today, I'm excited to explore Amazon's latest offering in this space: Amazon Q Developer in GitHub, which has just been released in preview. As an AWS Community Builder, I've had early access to this tool for over a week, and I wanted to put it through its paces with a real-world test:

Can Amazon Q Developer build a complete AWS SAM application from scratch, based solely on requirements provided in GitHub issues?

How Amazon Q Developer for GitHub Works

Before diving into my experiment, let's quickly review how Amazon Q Developer integrates with GitHub:

Issue-based development: Create a GitHub issue describing your feature requirements, add the "Amazon Q development agent" label, and Q Developer will generate a complete implementation and submit it as a pull request.
PR-based collaboration: Add the Q Developer label to an existing PR, and it will review your code, suggest improvements, or address requested changes.

In both cases, Amazon Q analyzes the context of your repository and comments, then either generates new code or modifies existing code. The AWS blog post explains the current capabilities and limitations of this preview version in detail.

My Experiment: Building an AWS SAM App from a Blank Repository

To test Amazon Q Developer's capabilities, I created a blank repository with just a README file. My goal was to see if Amazon Q could build a serverless photo application with AWS SAM, complete with GitHub Actions pipeline, solely based on requirements provided in issues.

Lesson #1: Crafting Effective Prompts is Critical

Following best practices for working with generative AI, I spent time crafting a detailed issue description that specified all the requirements for my AWS SAM application. This included:

Application architecture details
Required AWS resources
Code structure
Testing requirements
GitHub Actions pipeline specifications

I submitted this as Issue #1, added the Amazon Q development agent label, and waited.

Lesson #2: Mind the Context Window

Within minutes, I received my first lesson in the limitations of Amazon Q Developer:

⚠️ The issue description is too long. I will only look at the first 1000 words.

Like most LLM-based tools, Amazon Q Developer has a context window limitation. My detailed prompt exceeded this limit, meaning it would only process part of my requirements.

Lesson #3: Concise Requirements Are More Effective

Taking this feedback, I used an LLM to help condense my requirements into a more focused version. I submitted this as Issue #2, focusing on just the essential specifications. While this issue acknowledged receipt of the task, it also encountered issues.

Lesson #4: Third Time's the Charm!

Not giving up, I created Issue #3 with an even more concise and structured requirements list. This time, success! Amazon Q Developer processed the issue and created Pull Request #4 with a complete implementation of the AWS SAM photo application.

Lesson #5: Amazon Q Developer Self-Checks Its Code

What happened next was less impressive than it should have been: Amazon Q Developer had to scan its own generated code for security vulnerabilities and other issues. Perhaps it should have simply written secure code from the start, rather than creating problems that required subsequent fixes.

However, it's valuable that Amazon Q Developer can perform an additional security scan on the changeset, providing an extra layer of protection to catch vulnerabilities before they're committed to the codebase.

Key Lessons from My Initial Testing

While my experiment hit some initial snags, the ultimate success revealed several valuable insights:

Master the art of concise prompting - Your issue descriptions must be detailed enough to guide Q Developer effectively while staying under 1000 words. This constraint forces you to prioritize the most critical requirements.
Start with focused, smaller tasks - Rather than requesting a complete application, begin with individual components or features to maximize success rate and learn the tool's capabilities.
Embrace an iterative workflow - Amazon Q Developer shines as a collaborative partner in an iterative development process, not as a one-shot solution. Be prepared to refine requirements and review generated code carefully.
Value the security scanning - The automatic security review of generated code is a standout feature that helps ensure you're not introducing vulnerabilities into your codebase.

Amazon Q Developer: Production-Ready or Preview Promise?

Despite being in preview, Amazon Q Developer shows remarkable potential for transforming development workflows. The GitHub integration feels natural, and the ability to generate code directly from issue descriptions could dramatically accelerate development cycles for teams willing to adapt their processes.

The automatic security scanning feature is particularly valuable, as it helps address one of the main concerns with AI-generated code: security and best practices. By actively scanning its own output, Amazon Q Developer demonstrates a commitment to both speed and quality.

That said, be prepared for the expected preview-stage limitations. Beyond the context window restriction, you might encounter occasional bugs or inconsistent results. The service may also experience capacity constraints since it's currently free to use—AWS might be throttling resources during peak times, leading to slower responses or temporary unavailability.

I Strongly Recommend Trying It Today

I encourage you to experiment with Amazon Q Developer in your GitHub repositories. It costs nothing during the preview period and requires no AWS account setup, making it the perfect time to explore its capabilities and limitations.

I'll be continuing my experiment by testing how well Amazon Q Developer handles iterations and revisions to the generated code. Watch for a follow-up post with more detailed results and practical tips for maximizing this tool's value for your team.

AWS Landing Zone Odyssey Part 2: Escaping Account Purgatory

Trent Hornibrook — Fri, 25 Apr 2025 06:50:46 +0000

The Saga Continues

In my previous post, I shared my harrowing experience trying to deploy AWS Landing Zone with the Trusted Enclaves pattern. I ended that post stuck in what I called "Account Purgatory" - unable to remove suspended accounts from my organization, blocking any further progress.

Well, good news! After much trial and error (and several more AWS support tickets), I've finally escaped! Here's how I managed to exorcise those stubborn accounts and get back on track.

The Solution: Root Access and The Magical Obscure Link

The key to removing accounts from an AWS Organization isn't documented prominently anywhere I could find. After days of frustration, here's what finally worked:

Step 1: Recover Root Access to Child Accounts

First, I needed to access each child account as the root user:

For each account, I needed the email address used during creation
I had to initiate password recovery for each root account
Set a new root password for each account

Step 2: The Obscure Link - The Only Thing You Really Need

Here's the crucial discovery: In the AWS documentation about removing member accounts, there's an easily missed link labeled simply "this link" buried in the text.

The link appears in this section:

We recommend that you sign in to the member account by choosing Copy link, and then pasting it into the address bar of a new incognito browser window. If you do not see Copy link, use this link to go the Sign up for AWS page and complete the missing registration steps.

This mysterious "this link" is all you actually need! When clicked while logged in as the root user of a child account, it takes you to a special page that will automatically prompt you for all required information, including:

Payment method details
Support plan selection (Basic is free)
Phone verification
Any other missing account verification steps

You don't need to manually navigate to the billing console or payment preferences first - this link will guide you through everything required to make the account eligible to leave the organization.

Step 3: Finally Leaving the Organization

After completing the steps via "the link," you can then:

From the child account (still logged in as root)
Navigate to AWS Organizations
Select "Leave Organization"
Confirm your choice

Step 4: Don't Forget to Close the Account!

Lastly, don't forget to close that account once it's disconnected from the organization. Now that it's a standalone account with your payment method attached, it will start accruing charges for any resources left running.

Why Is This So Complicated?

The process is designed this way for good reason - to ensure accounts have everything they need to operate independently before leaving an organization. But the documentation and user experience could certainly be improved.

The biggest issue is that AWS doesn't clearly indicate what's missing from an account. You're just left with cryptic error messages like "The account cannot be removed because it's missing required information."

Lessons Learned

Beyond the technical steps, here are the key takeaways from this experience:

AWS Organization account management is intricate - Understand the full lifecycle before creating or removing accounts.
Documentation has gaps - Sometimes the most crucial information is buried in obscure places or missing entirely.

Share Your Experiences

Have you gone through similar struggles with AWS Organizations or Landing Zone? I'd love to hear your stories and any additional tips you might have!

My AWS Landing Zone Odyssey: A Tale of Tears, Timeouts, and Suspended Accounts

Trent Hornibrook — Thu, 24 Apr 2025 04:46:46 +0000

Introduction

As an AWS Community Builder, I was thrilled to receive $500 of AWS credits to build something practical. My vision? Setting up a Trusted Enclaves landing zone pattern with Entra ID integration for AWS access management. Little did I know I was embarking on a journey that would test my patience, troubleshooting skills, and sanity.

Join me on this cautionary tale of what happens when AWS Landing Zone deployment goes sideways.

The Initial Plan

My approach seemed straightforward:

Use my personal AWS account + $500 Community Builders credit
Deploy AWS Landing Zone Accelerator with Control Tower as the account creation mechanism
Apply the Trusted Enclaves configuration
Connect everything to Entra ID for streamlined access
Document the process to help fellow builders

Simple, right? Oh, how naïve I was.

Day 1: The Innocent Beginnings

I started by following the AWS Landing Zone Accelerator documentation. First hurdle? Service quotas.

Dear AWS User,

Your service quota increase request for the number of accounts in Organizations
is being processed. This may take up to 12 hours.

Regards,
AWS Support

A 12-hour wait just to increase my account quota. Fine, I can be patient. Little did I know this was just the appetizer to a feast of frustration.

Day 2: Control Tower Dreams and SCP Nightmares

After quota increases cleared, I successfully deployed stage one of the landing zone and then applied the Trusted Enclaves configuration. That's when my troubles truly began.

The configuration attempted to create a new OU and apply a 6th Service Control Policy (SCP) to it. Problem? AWS only allows 5 SCPs per OU by default.

"No problem," I thought. "I'll just remove the direct all-access SCP on the OU to make room."

Narrator: That was, in fact, a problem.

The process progressed further but then became completely wedged. The newly created accounts lost their trust relationships to both the audit account and the master billing account. I spent hours digging through CloudWatch logs trying to understand what went wrong.

I even attempted heroic measures - manually applying new cross-account trust relationships to help reinduct these wayward accounts back into Control Tower. No luck.

Day 3-4: The Clean Slate Approach

After much hair-pulling, I decided to throw everything out and start fresh. But there was a catch - I needed to keep my master billing account to retain that precious $500 credit.

My plan:

Close all child accounts
Remove all resources (with help from bash scripts to hunt down and terminate everything)
Get the master biller account back to pristine condition
Suspend/close all other accounts
Try again

But when I attempted the new deployment, I ran into this issue - the Landing Zone Accelerator was detecting my suspended accounts as active accounts and refusing to deploy!

Day 5-6: Account Purgatory

Now I needed those suspended accounts to be unsuspended so I could properly remove them from the organization. Cue another support case and another 24-hour wait.

When the accounts were finally unsuspended, I logged into each one, set up billing information, and tried to leave the organization cleanly (to then close them properly).

The response? An unexplained error. No reason. Just failure.

And so here I am, with another AWS support case open, waiting to understand why these child accounts refuse to leave the organization - like adult children who keep returning to live in your basement.

Lessons Learned (The Hard Way)

Service Quotas Matter: Request quota increases well in advance of starting deployment.

SCPs Are Tricky: Understand the SCP limits and how they affect your architecture before modifying them.

Document Everything: Track every change, error message, and support response. You'll need it to piece together the story later.

Understand Account Lifecycle: AWS accounts have complex lifecycle states that can affect operations in non-obvious ways.

Allow More Time Than You Think: What I estimated would take a weekend has stretched into a multi-week saga.

A Question for Fellow Builders

Have you deployed AWS Landing Zone with enhanced security controls? What challenges did you face? I'd love to hear your experiences - misery loves company, after all!

Securing Your Container Pipeline: Using AWS Inspector with GitHub Actions

Trent Hornibrook — Sat, 15 Mar 2025 03:02:43 +0000

As an AWS Community Builder, I'm excited to share a practical approach to integrating security scanning into your container deployment pipeline. Today, I'll walk you through an example GitHub repository that demonstrates how to use the AWS Inspector Vulnerability Scan GitHub Action to scan Docker images before they're pushed to Amazon ECR.

The Container Security Challenge

Containers have revolutionised how we deploy applications, but they also introduce unique security challenges. A common misconception is that containerisation automatically guarantees security. In reality, containers can harbour vulnerabilities in their base images, dependencies, or application code.

Enter AWS Inspector and GitHub Actions

To address this challenge, I'd like to highlight this example repository that demonstrates a complete workflow for building, scanning, and deploying Docker containers with built-in security controls.

The repository implements a GitHub Actions workflow that:

Builds your Docker image
Scans it for vulnerabilities using AWS Inspector
Only pushes to ECR if the image meets your defined security thresholds

How the Workflow Works

At its core, the workflow uses the Vulnerability Scan GitHub Action for Amazon Inspector, which integrates with AWS Inspector to perform comprehensive vulnerability scanning on your container images.

Here's a key section from the workflow file that handles the scanning:

- name: Scan built image with Inspector
  uses: aws-actions/vulnerability-scan-github-action-for-amazon-inspector@v1
  id: inspector
  with:
    artifact_type: 'container'
    artifact_path: '${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}'
    critical_threshold: ${{ env.CRITICAL_THRESHOLD }}
    high_threshold: ${{ env.HIGH_THRESHOLD }}
    medium_threshold: ${{ env.MEDIUM_THRESHOLD }}
    low_threshold: ${{ env.LOW_THRESHOLD }}
    other_threshold: ${{ env.OTHER_THRESHOLD }}

The workflow includes configurable thresholds for different vulnerability severity levels, allowing you to define what constitutes an acceptable level of risk for your organisation:

env:
  CRITICAL_THRESHOLD: 0  # No critical vulnerabilities allowed
  HIGH_THRESHOLD: 0      # No high vulnerabilities allowed
  MEDIUM_THRESHOLD: 5    # Up to 5 medium vulnerabilities allowed
  LOW_THRESHOLD: 5       # Up to 5 low vulnerabilities allowed
  OTHER_THRESHOLD: 5     # Up to 5 other vulnerabilities allowed

Why You Should Implement Container Scanning

1. Catch Vulnerabilities Before Deployment

By scanning container images during the build process, you prevent vulnerable containers from ever being pushed to your registry. This provides a critical security checkpoint at the beginning of your deployment pipeline.

The example repository demonstrates a fail-fast approach:

- name: Fail job if vulnerability threshold is exceeded
  run: exit ${{ steps.inspector.outputs.vulnerability_threshold_exceeded }}

2. Regular Scanning Identifies New Vulnerabilities

New vulnerabilities are discovered constantly. By implementing scheduled builds of your container images (e.g., weekly), you can leverage this scanning mechanism to identify when previously secure images become vulnerable due to newly discovered CVEs.

This proactive approach means you'll discover vulnerabilities through your CI/CD pipeline rather than through a security incident.

3. Improved Security Posture

Implementing this scanning workflow significantly improves your overall security posture by:

Creating a Software Bill of Materials (SBOM) for each image
Establishing clear security standards through configurable thresholds
Providing audit trails of security scanning results
Integrating security directly into your development workflow

4. Streamlined Deployment Process

The workflow not only scans but also handles the complete deployment process to ECR, making it an all-in-one solution for secure container deployment.

Important Security Considerations

While this scanning approach significantly improves your container security, it's crucial to understand that it doesn't absolve you of all security responsibilities. Container scanning focuses on known vulnerabilities in the container image, but it doesn't:

Detect runtime security issues
Protect against misconfigurations in how the container is deployed
Replace the need for network security controls
Eliminate the need for regular patching of running containers

You should combine this approach with other security practices like runtime protection, network policies, and regular updates to running containers.

Cost Considerations

Before implementing this solution, it's important to understand the cost structure for AWS Inspector in your region. For the Sydney (ap-southeast-2) region, the pricing is:

ECR Container Image Scanning:

Initial scan on push to ECR: $0.09 per image
Automated rescans for continuous scanning: $0.01 per rescan

On-demand Container Image Scanning (including within CI/CD solutions):

$0.03 per image scanned

For most organisations, this cost is minimal compared to the potential cost of a security incident. For example, if you build and scan 100 container images per month with this workflow, your cost would be approximately $3.00 per month.

Setting Up the Solution

The example repository provides detailed instructions for setting up:

OIDC authentication between GitHub and AWS
Required IAM roles with appropriate permissions
GitHub Secrets configuration
Example Dockerfile with security best practices

The implementation uses role chaining for enhanced security, ensuring that your GitHub Actions have only the minimum permissions required.

Conclusion

The docker-ecr-github-action-inspector-scanner-example repository provides a production-ready solution for integrating container security scanning into your deployment workflow. By implementing this approach, you create a strong first line of defense against container vulnerabilities.

Remember that security is a continuous process. Using this scanning approach in combination with regular scheduled builds gives you a powerful mechanism for identifying and addressing new vulnerabilities before they impact your production environment.

Have you implemented container scanning in your workflows? I'd love to hear about your experiences in the comments below!

AWS Fargate Deep Dive: Key Takeaways from Melbourne User Group

Trent Hornibrook — Thu, 13 Mar 2025 21:43:04 +0000

Last night, I spoke at the AWS Melbourne User Group, providing a deep dive into AWS Fargate.

I began by recounting my first talk at the AWSUG in 2012

Talking at the AWSUG Aug 2012

Why Fargate?

I highlighted the key challenges Fargate aims to solve:

With the rise of 12-factor apps, teams want to focus on deploying containers without managing underlying infrastructure
Keeping operating systems up-to-date is often difficult and easily neglected

Fargate Architecture

AWS Fargate (Linux version) is powered by Firecracker VM technology, providing security isolation for Linux-based Fargate containers and Lambda functions. The compute resource appears in your AWS account and is shared via a network interface (ENI).

Pricing Considerations

Fargate pricing depends on several factors:

Spot vs. on-demand instances
ARM vs. X86 architecture (note: Windows Fargate doesn't yet support ARM)
Windows vs. Linux (Windows incurs additional licensing costs)
CPU shares and memory allocation from a predefined menu (custom configurations not available)

Container Scheduler Platforms

AWS offers two main container scheduler platforms:

Elastic Kubernetes Service (EKS)
Elastic Container Service (ECS)

Both platforms support:

Running containers on Fargate
Running containers on self-managed EC2 instances (or managed nodegroups in EKS)
Mixed deployment models

ECS vs. EKS: Key Differences

ECS:

Highly opinionated and simple
AWS-specific
Supports decentralized "you build it, you run it" operating models
Suited for multiple ECS clusters

EKS:

Highly flexible with a rich plugin ecosystem
Requires specialized skills to operate effectively
Better suited for centralized operations
Typically uses fewer, larger clusters

Choosing the Right Approach

Consider your organization's operating model:

For traditional SRE centralized operations, EKS might be preferable
For decentralized operations that empower teams, ECS's simplicity may be advantageous

Note: Regardless of platform choice, developer-focused golden path tooling remains critical!

Fargate Limitations at Scale

When operating at scale, Fargate on EKS has some limitations:

Cannot run daemonsets (requires sidecar pattern instead)
Risk of overprovisioning if pod requirements don't align with Fargate launch options

For a middle-ground approach, consider Bottlerocket as an AMI in EKS to reduce OS-level security risks. Additionally, running kube-scheduler on Fargate (including Karpenter) while using Karpenter to manage EC2-based nodes offers an excellent compromise.

This is the video of my talk: here