From Local Environment Variables to AWS Secrets Manager: Decoupling Application Secrets for SREs

Move beyond `.env` files and static secrets. Learn how AWS Secrets Manager, IAM, and identity-driven access help SREs securely manage application credentials, reduce manual rotation, and build more secure, production-ready AWS architectures.

MD. Gyasuddin Mansuri

Published Oct 5, 2026

Last modified Oct 5, 2026

When you are developing locally, managing secrets often starts innocently enough.

You create a .env file:

1
2
3
4
DB_HOST=localhost
DB_USER=admin
DB_PASSWORD=supersecret
API_KEY=abc123

Your application reads the variables, everything works, and you move on.

For a local development environment, that may be acceptable.

But once the same workload moves into AWS, the question changes.

It is no longer:

How do I give my application a password?

It becomes:

How do I allow my application to retrieve sensitive credentials securely without embedding them into source code, container images, deployment manifests, or long-lived environment variables?

This is where AWS Secrets Manager becomes useful.

For SREs moving from local infrastructure toward AWS-managed architectures, this represents another important paradigm shift:

1
2
3
4
5
6
7
8
9
10
11
Local .env files
        ↓
Static secrets
        ↓
Application configuration
        ↓
AWS Secrets Manager
        ↓
IAM-authorized retrieval
        ↓
Managed secret lifecycle

The secret still exists.

What changes is who stores it, how applications retrieve it, and how access is controlled.

The Local Pattern: `.env` Files Everywhere

A simple application might read its database credentials from environment variables.

For example:

1
2
3
4
import os

db_user = os.getenv("DB_USER")
db_password = os.getenv("DB_PASSWORD")

And locally:

1
2
export DB_USER=admin
export DB_PASSWORD=my-password

Or perhaps Docker Compose injects them:

1
2
3
4
5
6
services:
  app:
    image: my-app
    environment:
      DB_USER: admin
      DB_PASSWORD: my-password

Technically, this works.

Operationally, however, several problems appear as the environment grows.

Who knows the password?

Where is it stored?

Was it accidentally committed to Git?

Is it inside a CI/CD variable?

Is it copied into multiple Kubernetes Secrets?

When was it last rotated?

Which application is actually allowed to retrieve it?

Static secret distribution quickly becomes difficult to manage.

The Cloud Pattern: Centralize the Secret

AWS Secrets Manager provides a managed service for storing sensitive values such as:

database passwords
API tokens
application credentials
third-party service keys
connection strings

Instead of embedding the secret into the application deployment, the application retrieves it when needed.

Conceptually:

1
2
3
4
5
6
7
8
9
Application
     |
     | AWS API request
     v
AWS Secrets Manager
     |
     | IAM authorization
     v
Return Secret

This changes secret management from a file distribution problem into an identity and authorization problem.

That is a much more scalable model.

Step 1: Create a Secret

Using the AWS CLI:

1
2
3
4
5
6
aws secretsmanager create-secret \
  --name production/myapp/database \
  --secret-string '{
    "username":"appuser",
    "password":"change-me"
  }'

AWS returns information about the newly created secret.

You can confirm it exists:

1
2
aws secretsmanager describe-secret \
  --secret-id production/myapp/database

The important difference is that your application credentials are no longer living inside your deployment manifest.

Step 2: Retrieve the Secret

You can test retrieval with:

1
2
aws secretsmanager get-secret-value \
  --secret-id production/myapp/database

The application can perform the same operation through an AWS SDK.

For example, using Python and boto3:

1
2
3
4
5
6
7
8
9
10
11
12
13
import boto3
import json

client = boto3.client("secretsmanager")

response = client.get_secret_value(
    SecretId="production/myapp/database"
)

secret = json.loads(response["SecretString"])

username = secret["username"]
password = secret["password"]

Notice what is missing.

There is no AWS access key in the application code.

There should not be one.

The workload should receive permissions through an AWS identity such as:

an EC2 IAM role
an ECS task role
a Lambda execution role
an EKS Pod Identity role

The application proves who it is, and IAM determines what it is allowed to retrieve.

IAM Becomes the Security Boundary

Suppose our application only needs one secret.

We do not want to grant:

1
2
3
4
5
{
  "Effect": "Allow",
  "Action": "secretsmanager:*",
  "Resource": "*"
}

That gives far more access than necessary.

Instead, we can create a least-privilege policy:

1
2
3
4
5
6
7
8
9
10
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:REGION:ACCOUNT_ID:secret:production/myapp/database-*"
    }
  ]
}

Now the workload can retrieve only the secret it actually needs.

This is a recurring AWS architecture principle:

1
2
3
4
5
Identity
   +
Least-Privilege Policy
   +
Specific Resource

Instead of distributing credentials broadly, we grant narrowly scoped access.

Connecting This to EKS Pod Identity

This becomes particularly interesting when running Kubernetes on Amazon EKS.

In a previous architecture, we might have something dangerous like:

1
2
3
4
5
6
7
8
9
10
11
12
env:
  - name: AWS_ACCESS_KEY_ID
    valueFrom:
      secretKeyRef:
        name: aws-credentials
        key: access-key

  - name: AWS_SECRET_ACCESS_KEY
    valueFrom:
      secretKeyRef:
        name: aws-credentials
        key: secret-key

Now we have AWS credentials stored inside Kubernetes.

That creates another credential lifecycle problem.

With EKS Pod Identity, the pod can receive an IAM identity dynamically.

The architecture becomes:

1
2
3
4
5
6
7
8
9
10
11
12
Pod
 |
 | EKS Pod Identity
 v
IAM Role
 |
 | GetSecretValue permission
 v
AWS Secrets Manager
 |
 v
Database credentials

There are now two separate identities:

1
2
3
4
5
AWS Identity
    → determines whether the workload may access Secrets Manager

Application Secret
    → authenticates the application to the database

Neither one needs to be hardcoded inside the container.

That is a much cleaner architecture.

What About Kubernetes Secrets?

Kubernetes Secrets are still useful.

But it is important to understand what they are.

A Kubernetes Secret is primarily a Kubernetes API object for storing sensitive configuration.

It does not automatically solve:

centralized secret governance
cross-service secret management
automatic database credential rotation
IAM authorization
organization-wide auditing

Many production environments therefore combine Kubernetes with external secret systems.

For example:

1
2
3
4
5
6
7
8
9
10
AWS Secrets Manager
        |
        v
External Secrets Operator
        |
        v
Kubernetes Secret
        |
        v
Pod

Another pattern is for the application to retrieve the secret directly through the AWS SDK.

Each design has trade-offs.

The important architectural question is not:

Can Kubernetes store a password?

It can.

The better question is:

Where should the source of truth for this secret live?

Secret Rotation Changes the Operational Model

One of the biggest differences between static secrets and managed secrets is rotation.

With a traditional .env approach:

1
2
3
4
5
6
7
8
9
Change password
      ↓
Update CI/CD variable
      ↓
Update Kubernetes Secret
      ↓
Restart application
      ↓
Hope nothing was missed

With managed secret rotation, AWS Secrets Manager can integrate with supported services and rotation workflows.

Conceptually:

1
2
3
4
5
6
7
8
9
Current Credential
      ↓
Generate New Credential
      ↓
Update Target Service
      ↓
Update Stored Secret
      ↓
Applications retrieve new value

The goal is not simply storing secrets more securely.

The goal is reducing the operational burden of maintaining them.

Encryption Is Only Part of the Story

Secrets Manager encrypts secrets at rest using AWS KMS.

That is important.

But encryption alone does not make a system secure.

You also need to ask:

1
2
3
4
5
6
Who can retrieve the secret?
Who can modify the secret?
Who can rotate it?
Who can change the IAM policy?
Who can decrypt it?
Who accessed it?

This is why AWS security architecture frequently involves several services together:

1
2
3
4
5
6
7
8
9
10
11
IAM
  → authorization

Secrets Manager
  → secret lifecycle

KMS
  → encryption

CloudTrail
  → API auditing

AWS architecture is rarely about one isolated service.

The value comes from how the services interact.

The SRE Perspective

From an SRE perspective, the biggest benefit is reducing hidden operational dependencies.

With manually managed credentials, someone eventually becomes responsible for:

1
2
3
4
5
6
copying
rotating
distributing
revoking
documenting
synchronizing

those credentials.

That is operational toil.

A managed secret architecture moves more of that responsibility into controlled APIs and automation.

The SRE workflow changes from:

1
"Which server has the new password?"

to:

1
"Which identity has permission to retrieve this secret?"

That is a much better question.

The Solutions Architect Perspective

For AWS Solutions Architect Associate candidates, this topic connects several important exam concepts.

AWS Secrets Manager

Use it when you need managed storage and lifecycle management for sensitive credentials.

AWS Systems Manager Parameter Store

Another option for configuration values and secrets.

Not every parameter needs Secrets Manager.

You should understand why an architecture might choose one over the other.

IAM Roles

Applications running on AWS should generally obtain temporary credentials through IAM roles instead of storing long-lived access keys.

AWS KMS

Used throughout AWS for encryption key management.

AWS CloudTrail

Provides visibility into API activity, including actions involving IAM and Secrets Manager.

Least Privilege

Grant only the actions and resources a workload actually requires.

This principle appears constantly in architecture questions.

Local Thinking vs AWS Thinking

The broader shift looks like this:

Local Infrastructure	AWS Architecture
.env file	Secrets Manager
Static configuration	Managed secret
Shared credentials	IAM-authorized access
Manual rotation	Automated rotation capability
Credentials copied between systems	Central source of truth
Long-lived AWS keys	Temporary IAM credentials
Application-level trust	Identity-driven authorization

The AWS-native approach is not simply:

Put the .env file somewhere else.

It is:

Redesign how applications obtain sensitive information.

That distinction matters.

The Bigger Pattern

This is the same architectural transformation we see repeatedly when moving from local infrastructure to AWS.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Local Docker Registry
        ↓
Amazon ECR

Local Kubernetes Control Plane
        ↓
Amazon EKS

Local HAProxy
        ↓
Application Load Balancer

Static AWS Credentials
        ↓
EKS Pod Identity

Local .env Secrets
        ↓
AWS Secrets Manager

Each transition removes a piece of infrastructure or security responsibility that we previously had to manage manually.

That is one of the core ideas behind cloud architecture.

It is not just moving servers somewhere else.

It is deciding which responsibilities you should continue operating yourself and which responsibilities should be delegated to managed services.

Final Thoughts

A .env file is perfectly reasonable when you are experimenting locally.

The problem begins when the same operational model follows your application into production.

Production systems need clearer answers to questions around:

ownership
authorization
rotation
encryption
auditing
credential lifecycle

AWS Secrets Manager gives us a managed foundation for solving those problems.

But the most important architectural improvement is not Secrets Manager itself.

It is the shift toward identity-driven access.

Instead of asking:

1
Where did we store the password?

we can design systems around:

1
2
Which workload is requesting the secret,
and should that workload be allowed to retrieve it?

For SREs moving deeper into AWS, that shift—from static configuration toward managed identity and controlled access—is one of the most important changes to understand.

# sre # devops # solutions-architect # iam # amazon-eks

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

From Local Environment Variables to AWS Secrets Manager: Decoupling Application Secrets for SREs

MD. Gyasuddin Mansuri

The Local Pattern: .env Files Everywhere

The Cloud Pattern: Centralize the Secret

Step 1: Create a Secret

Step 2: Retrieve the Secret

IAM Becomes the Security Boundary

Connecting This to EKS Pod Identity

What About Kubernetes Secrets?

Secret Rotation Changes the Operational Model

Encryption Is Only Part of the Story

The SRE Perspective

The Solutions Architect Perspective

AWS Secrets Manager

AWS Systems Manager Parameter Store

IAM Roles

AWS KMS

AWS CloudTrail

Least Privilege

Local Thinking vs AWS Thinking

The Bigger Pattern

Final Thoughts

The Local Pattern: `.env` Files Everywhere