This year as part of my role I work more often with Rails apps running on AWS ECS. We aim to follow the 12‑factor app principles, loading configuration (including secrets) via environment variables to keep apps portable, stateless, and deployment‑friendly.

AWS ECS supports passing Secrets Manager secrets through environment variables, which injects secrets into containers at startup. While Secrets Manager provides excellent security and rotation capabilities, its pricing model adds up quickly with many secrets.

Our apps have on average 20–40 secrets per application stored in AWS Secrets Manager. Since we load secrets at container startup, storage costs dominate over API call costs, even with daily deployments.

I recently explored further spec-driven development using GitHub's Spec Kit with Amazon Q Developer. This became possible after the Amazon Q Developer team merged PR #2799 (custom prompt support) and the Spec Kit team merged PR #600 (Q Developer integration).

Here's what I discovered along the way - the good, the quirks, and the gotchas.

As outlined in GitHub's official announcement, developers can now use their AI tool of choice (Claude, Gemini, Cursor, Copilot, etc) for spec-driven development with GitHub's open source Spec Kit, but Q Developer users are left out of this unified experience.

We can address this missing piece with local stdio MCP server bridge while we wait for native support to land in Spec Kit.

With the recent announcement of OpenIddict 6 and AWS Aurora Serverless v2's new scaling to zero capability, we have a perfect opportunity to build a cost-effective, serverless OAuth2/OpenID Connect server.

This setup will leverage AWS Lambda for compute and Aurora v2 PostgreSQL for storage, providing enterprise-grade security and scalability while maintaining optimal cost efficiency and only incurring cost when actually in use.

Let's start by creating a new solution for our OAuth2/OIDC server.

Today my application for AWS Community Builders 2024 program has been approved.

Currently, the program covers the following technology areas: Containers, Data (databases, analytics), Developer Tools, Front-End Web and Mobile, Cloud Ops, Machine Learning, Network Content & Delivery, Security & Identity, and Serverless.

I've been selected in category - Containers. Looking forward to the journey ahead of me, and all the new experiences.

A big thanks to Maksim Skutin who motivated me to work on blog posts and submit this application.

After succesfully running ASP.NET 8 Minimal API with Lambda Container image it's time to run something real.

And just in December 2023 Kévin Chalet announced new version of OpenIddict, the library to build your own OAuth2 / OpenID Connect server in .NET.

Officially OpenIddict supports two implementations for persistance layer:

• Relation databases using EntityFramework Core
• NoSQL with MongoDb

This time we will explore how to implement fully serverless OAuth2 server using OpenIddict 5 with Lambda Container image and persistance layer backed by AWS DynamoDB

First let's review OpenIddict concepts and components.

.NET 8 is finally here, since its release over a month ago.

Probably one of the much anticipated feature was Native AOT and its support for ASP.NET Core. Benefits coming along with it (such as minimized disk footprint, reduced startup time, and reduced memory demand) will lead to exploration how to run ASP.NET Core 8 apps in AWS Lambda.

Last year AWS gave us only two options to run .NET 7 Lambda functions: either container image or custom runtime. Now, in a twist for 2024, AWS is throwing its full support behind .NET 8 runtime, set to drop officially sometime in January. I think it's due to the fact that .NET 8 is an LTS release with a solid 3-year support plan.

And today I will show you the simplest way to run ASP.NET Core 8 in AWS Lambda without tearing everything apart!

First let's see what kind of objectives ASP.NET Core developers might have prior to investing their time and efforts into AWS serverless technology.

Docusaurus v3 is out, but official docs are still lacking deployment to AWS as option.

Let me fix this and guide you how to create most secure and up to date approach with AWS S3 and Cloudfront.

Docusaurus is static website generator, so let's review options AWS offers us to serve it.

Quite often I need to create AWS ACM certificate and do DNS validation using Pulumi.

Pulumi aws.acm.CertificateValidation DNS example only show basic and naive implementation:

• hardcoded single domain validation ¯_(ツ)_/¯
• will fail if you try to validated wildcard and apex domain simultaneously

* creating Route 53 Record: InvalidChangeBatch: [Tried to create resource record set [name='_f22110437fea5500aa0f8bf286aed7c7.howto.ahanoff.dev.', type='CNAME'] but it already exists]

Today I'll show how to create validation that works for any domain

I will create AWS ACM certificate with the following conditions:

• multi domain certificate
• validates wildcard domain: *.howto.ahanoff.dev
• validates apex domain: howto.ahanoff.dev

Recently with team members we discovered https://www.allero.io/ that does CI/CD security validation:

• identify plain text passwords
• identify potentially malicious code execution
• etc

Despite me being quite sceptical about it initially it found one issue using default rules