Secrets-Manager

Right, so you’ve got a secret in one account and something in another account that desperately needs it. Welcome to the multi-account reality, where we wall things off for security and then immediately have to poke a bunch of carefully controlled holes in those walls to get anything done. It’s the cloud’s version of “we need to have a talk” with your infrastructure. The first thing to get straight is that neither Secrets Manager nor Parameter Store has a magical “replicate this to Timbuktu” button. AWS would love to sell you a solution that involves Step Functions, EventBridge, Lambda, and a few dozen IAM roles (and honestly, it’s not a terrible idea for complex setups), but for most of us, the goal is something simpler, more robust, and less likely to fail in a way that requires a 3 AM page.

Right, let’s get your code talking to the vault. Because hardcoding secrets is for amateurs and hello-world tutorials, and you’re neither. Whether you’re in a serverless Lambda, a container in ECS, or on a crusty old EC2 instance, the principle is the same: your code needs permission to ask for the secret, and then it needs to know how to ask. I’ll show you the patterns, and then we’ll gripe about the weird bits.

Right, let’s talk about SecureString parameters. This is the part where I have to give you some good news and some bad news. The good news is that they are a way to store secrets directly in Parameter Store, encrypted at rest by a KMS key. The bad news? AWS themselves will tell you they are basically a legacy feature at this point, and you should probably be using Secrets Manager instead. But since you’re here, and because you’ll inevitably run into them in the wild (or in a legacy system you’ve inherited), we need to dig in.

Alright, let’s talk about the two flavors of SSM Parameter Store: Standard and Advanced. Think of them as the difference between a reliable, no-frills sedan and a souped-up performance model with all the bells and whistles. One gets you from A to B just fine for most trips, while the other is for when you’re hauling something sensitive or need to go really, really fast. The core distinction boils down to three things: storage size, cost, and advanced features. Let’s cut through the marketing-speak.

Alright, let’s cut through the marketing fluff and get to the brass tacks. You’ve got secrets and configuration data. AWS gives you two main vaults to put them in: Secrets Manager and the SSM Parameter Store. They look similar on the surface—both hold strings you don’t want hardcoded—but the devil, and your bill, is in the details. Choosing the wrong one is like using a diamond-tipped drill to hang a picture frame; it’ll work, but your accountant will weep.

Right, let’s talk about automatic rotation. You’ve got a database credential in Secrets Manager, and you’re not a masochist, so you’d rather not manually change this password every 90 days. Good call. The magic wand here is a Lambda function that Secrets Manager will invoke for you on a schedule to handle the whole tedious process. But here’s the thing you need to internalize right now: you are responsible for writing most of that magic. AWS provides the framework and the invocation; you provide the logic. It’s a partnership, and like most partnerships, it works great until you forget an important detail.

Alright, let’s talk about Secrets Manager, the service that finally lets you stop committing database passwords to your GitHub repo where they’ll live forever, mocked by Russian bots. This isn’t just a secure locker for your most sensitive data; it’s a full-blown credential management system with a party trick: automatic rotation. It’s for the stuff that would cause a real, “oh we’re on the news” level of disaster if it leaked: database credentials, API keys (especially the ones that cost money), and OAuth tokens.