DEV Community: Aref Nozarpour

AWS Secrets Manager in .NET: How To Load Your Secrets Straight into IConfiguration

Aref Nozarpour — Fri, 19 Jun 2026 20:39:16 +0000

If you build .NET apps that run on AWS, you have probably lived this moment. A connection string, an API key, maybe a signing secret, all sitting in appsettings.json where they really should not be. So you move them to AWS Secrets Manager, which is the right call, and then you notice the boring part. Now you have to write code to fetch the secret, parse it, and feed every value into the rest of your app.

I built a small NuGet package to make that last part disappear, which is exactly what you want from secrets handling. It is called RF.AWSSecretsManager.Configuration, and it connects AWS Secrets Manager to the standard .NET configuration system. The rest of your code does not change at all.

Here is the whole idea in one sentence. Your secret lives in AWS as JSON, the package reads it once at startup, and every value shows up in IConfiguration as if it had always been there.

The problem with the usual approach

Most teams start by reading the secret by hand. You create an AWS SDK client, call GetSecretValue, deserialize the JSON, and then copy values into your options classes. It works, but it spreads AWS specific code across your startup, it usually ends up logging things it should not, and it does not play nicely with the configuration system that the rest of .NET already uses.

The cleaner pattern is to treat Secrets Manager as just another configuration source, the same way appsettings.json and environment variables are sources. That is what this package does.

Installing it

dotnet add package RF.AWSSecretsManager.Configuration

It targets net8.0 and net10.0, and it uses System.Text.Json under the hood. There is no Newtonsoft.Json dependency to drag along.

The simplest possible example

Store your secret in AWS as JSON, for example a secret named my/app/secrets that contains this:

{
  "MySetting": "Some value"
}

Then add one line when you build configuration:

using Microsoft.Extensions.Configuration;
using RF.AWSSecretsManager.Configuration;

var configuration = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json", optional: true)
    .AddAWSSecretsManager("my/app/secrets")
    .Build();

var value = configuration["MySetting"]; // "Some value"

That is the entire integration. Credentials and region come from the default AWS SDK chain, so environment variables, a shared credentials file, or an IAM role all work without extra setup.

How the JSON becomes configuration keys

Configuration in .NET is flat, with keys like ConnectionStrings:Default. Secrets are often nested. The package bridges that gap by flattening nested objects with a colon, which is the same separator the configuration system already uses.

So a secret like this:

{
  "ConnectionStrings": {
    "Default": "Server=db;Database=app;User Id=svc;Password=p"
  },
  "Feature": {
    "Timeout": 30
  }
}

turns into these keys:

ConnectionStrings:Default
Feature:Timeout

Which means your existing GetConnectionString("Default") call and your bound options classes keep working without any changes. One note worth knowing up front: in this version, JSON arrays are skipped on purpose. They do not create keys and they do not throw. Keep your secrets as flat or nested objects and you are good.

Store the secret as a JSON object

A quick word on how to shape the secret, because it matters. AWS Secrets Manager stores a single string per secret, and the console gives you two editors for it. The Key/value editor writes a JSON object for you, so if you use that you are already set. The Plaintext editor stores exactly what you type, which might be JSON or might be a single raw value like one password.

This package expects that string to be a JSON object, and there is a good reason. IConfiguration is a set of keys and values, and a JSON object is the thing that carries both the key names and their values together. A bare value like p@ssw0rd has a value but no key, so there would be nothing to file it under. That is exactly the gap this package fills: your JSON keys become your configuration keys, with no glue code in between.

Two things follow from that:

A single raw value is not loaded in this version. If your secret is just one string, wrap it as one JSON property and you are good:

{
  "Db:Password": "p@ssw0rd"
}

If the secret is not valid JSON at all, startup fails fast with a clear message rather than guessing what you meant. That is on purpose.

Loading a single raw value keyed by the secret name is on the roadmap. For now, JSON objects are the format that keeps every value addressable by name, which is what the configuration system wants.

Using it in ASP.NET Core

In a minimal hosting app you can call the extension right on the configuration builder:

var builder = WebApplication.CreateBuilder(args);

builder.Configuration.AddAWSSecretsManager("my/app/secrets");

var app = builder.Build();

From here, anything that reads IConfiguration, including the options pattern, sees the values from Secrets Manager merged in with your other sources.

It is careful with your secrets

This is the part I care about most, because a config helper that leaks secrets is worse than no helper at all.

The package never writes secret values to logs. Not on success, not on failure. The only thing it will log is the secret name and error details, and even the name can be masked if you want an extra layer of caution:

.AddAWSSecretsManager("my/app/secrets", options =>
{
    options.MaskSecretNameInLogs = true;
    // "my/app/secrets" shows up as "my/***ts"
});

Pair that with a least privilege IAM policy so the app can read only the secrets it actually needs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["secretsmanager:GetSecretValue"],
      "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my/app/secrets-*"
    }
  ]
}

When you need more control over the client

Most apps are happy with the default client. When you need a specific region or a client you built yourself, pass it in:

using Amazon;
using Amazon.SecretsManager;

IAmazonSecretsManager client = new AmazonSecretsManagerClient(RegionEndpoint.USEast1);

var configuration = new ConfigurationBuilder()
    .AddAWSSecretsManager("my/app/secrets", client)
    .Build();

When you supply the client, the package leaves it alone and does not dispose it, since you own its lifetime. There are also overloads that accept an ILogger or an ILoggerFactory with a category name, which fit nicely into dependency injection.

What actually happens at startup

A few behaviors are worth knowing so there are no surprises in production.

The secret is read once, while configuration is being built. If the secret is missing or the payload is not valid JSON, startup fails fast with a clear error instead of letting your app run in a half configured state. Transient AWS issues like throttling or a brief 5xx are retried with exponential backoff, three attempts with a growing delay, before giving up. And because the values flow through the normal configuration pipeline, your secret never has to be passed around by hand.

Loading once at startup is the right default for most services, and it keeps the behavior predictable.

When this is a good fit, and when it is not

It fits well when you have one JSON secret per app or per environment, you want those values in IConfiguration with no custom plumbing, and you care about not leaking secrets into logs.

It is not trying to be everything yet. If you need automatic refresh when a secret rotates, or you want to merge many secrets at once, those are on the roadmap rather than in the box today. More on that next.

What is coming next

The current version is intentionally small and focused. The features I am looking at for upcoming releases include an optional mode so startup can continue when a secret is absent, refresh support so rotated secrets reload without a restart, a key prefix option for scoping, array handling, and loading more than one secret. If one of these matters to you, that is genuinely useful feedback, and the issue tracker is the best place to say so.

Try it

If this saves you from writing the same Secrets Manager glue code again, that is the goal.

NuGet: dotnet add package RF.AWSSecretsManager.Configuration
Source and issues: https://github.com/arefLA/RF.AWSSecretsManager.Configuration

A star on the repo helps other people find it, and any feedback, bug report, or feature request is welcome. Thanks for reading, and happy shipping.

Strongly-Typed Redis Caching in ASP.NET Core (Without the Boilerplate)

Aref Nozarpour — Thu, 18 Jun 2026 18:52:10 +0000

If you've added Redis to an ASP.NET Core app, you've probably met IDistributedCache. It does the job, but it only speaks in byte[] and string keys. So every read or write turns into the same little ritual: serialize, null-check, deserialize. Do that in one place and it's fine. Do it in twenty, and you've got a pile of nearly identical caching code that's surprisingly easy to get wrong.

This post keeps Redis as your store but caches typed objects instead of byte arrays, using a small open-source package called CacheManager.Redis. We'll look at the boilerplate problem, write a clean cache-aside method, prefix keys for shared Redis, and figure out when you'd actually want to reach for something else.

The boilerplate problem with IDistributedCache

Here's the usual cache-aside read with the raw IDistributedCache:

public async Task<Weather?> GetForecastAsync(string city, CancellationToken ct)
{
    var key = $"forecast:{city}";

    var bytes = await _cache.GetAsync(key, ct);
    if (bytes is not null)
        return JsonSerializer.Deserialize<Weather>(bytes);

    var forecast = await _api.LoadForecastAsync(city, ct);

    await _cache.SetAsync(
        key,
        JsonSerializer.SerializeToUtf8Bytes(forecast),
        new DistributedCacheEntryOptions { SlidingExpiration = TimeSpan.FromMinutes(10) },
        ct);

    return forecast;
}

None of this is hard. But the serialization, the null handling, and the expiration options all live in your business logic, and they get copy-pasted into every service that touches the cache.

A typed wrapper over the same Redis

CacheManager.Redis is a thin layer over Microsoft.Extensions.Caching.StackExchangeRedis. It doesn't replace Redis or StackExchange.Redis. It just wraps the distributed cache so you work with T instead of byte[], and it handles System.Text.Json for you.

Install it:

dotnet add package CacheManager.Redis

using CacheManager.Redis.Extensions;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRedisCacheManager(
    builder.Configuration.GetConnectionString("Redis"),
    options =>
    {
        options.InstanceName = "myapp:"; // optional key prefix
        options.DefaultCacheOptions = new DistributedCacheEntryOptions
        {
            SlidingExpiration = TimeSpan.FromMinutes(10)
        };
    });

That one call sets up AddStackExchangeRedisCache for you and registers IRedisCacheManager<T> so you can inject it anywhere.

Cache-aside, now strongly typed

Inject IRedisCacheManager<T> and that same read gets a lot shorter:

public sealed class ForecastService
{
    private readonly IRedisCacheManager<Weather> _cache;
    private readonly WeatherApi _api;

    public ForecastService(IRedisCacheManager<Weather> cache, WeatherApi api)
    {
        _cache = cache;
        _api = api;
    }

    public async Task<Weather> GetForecastAsync(string city, CancellationToken ct)
    {
        var key = $"forecast:{city}";

        var cached = await _cache.GetAsync(key, ct);
        if (cached is not null)
            return cached;

        var forecast = await _api.LoadForecastAsync(city, ct);
        await _cache.SetAsync(key, forecast, ct); // uses the default expiration from registration
        return forecast;
    }
}

No serializer calls, no byte[], no casting. GetAsync gives you back a Weather? (null on a miss), and SetAsync stores the object using the JSON settings you set once at startup.

If you'd rather not throw on bad keys, there are best-effort TryGet and TrySet overloads that return false for null or whitespace keys instead of throwing. One thing worth knowing: TryGet is synchronous, so the async read path is GetAsync.

Key prefixing for shared or multi-tenant Redis

A single Redis instance often gets shared across apps or tenants. The InstanceName option prefixes every key this manager writes, so myapp:forecast:london won't collide with some other service's forecast:london:

options.InstanceName = "myapp:";

You set it once, and your call sites stay clean with logical keys like forecast:london.

Consistent serialization across the app

Because the System.Text.Json options live in your registration, every cached type serializes the same way (camelCase, enums as strings, whatever you pick) without each caller passing settings around:

options.SerializerOptions = new JsonSerializerOptions
{
    PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
    Converters = { new JsonStringEnumConverter() }
};

Adding logging or metrics with a decorator

Cross-cutting stuff stays out of your core code. Implement IRedisCacheManager<T>, hand off to an inner instance, and register it with Scrutor:

public sealed class LoggingCacheManager<T> : IRedisCacheManager<T> where T : class
{
    private readonly IRedisCacheManager<T> _inner;
    private readonly ILogger<LoggingCacheManager<T>> _logger;

    public LoggingCacheManager(IRedisCacheManager<T> inner, ILogger<LoggingCacheManager<T>> logger)
    {
        _inner = inner;
        _logger = logger;
    }

    public bool TryGet(string key, out T? response)
    {
        var hit = _inner.TryGet(key, out response);
        _logger.LogDebug("Cache {Result} for {Key}", hit ? "hit" : "miss", key);
        return hit;
    }

    // Delegate the remaining IRedisCacheManager<T> members to _inner.
}

builder.Services.AddRedisCacheManager(connectionString);
builder.Services.Decorate(typeof(IRedisCacheManager<>), typeof(LoggingCacheManager<>));

That's how you add hit/miss metrics or structured logging today, without touching the caching logic itself.

When to use it

A quick gut check, because picking the wrong tool just wastes your afternoon.

Reach for CacheManager.Redis when you want typed, low-ceremony cache-aside over Redis in an ASP.NET Core app, you're already happy with how IDistributedCache behaves, and you'd rather not rebuild a serialization wrapper in every project.

CacheManager.Redis stays small on purpose. A few things on its public roadmap (a one-call GetOrSet, async Try variants, and opt-in instrumentation) are planned but not shipped yet, so think of them as where it's headed rather than what's in the box today.

Give it a try

Distributed caching in ASP.NET Core doesn't have to mean byte arrays and copy-pasted JSON. A typed wrapper like CacheManager.Redis lets you keep Redis and IDistributedCache underneath while your code works with real objects, one serialization setup, and one place to handle expiration and key prefixes.

It targets net8.0 and net10.0. If you want to give it a spin:

📦 NuGet: nuget.org/packages/CacheManager.Redis
⭐ Source and issues: github.com/arefLA/CacheManager.Redis

Hit a rough edge, or want GetOrSet sooner? Open an issue. Feature requests really do shape what gets built next.

Got a caching pattern you keep rewriting? Drop it in the comments. It might just be the next feature.