AWS Secrets Manager: Features, Pricing, And How To Use It

Managing credentials for healthcare integrations isn't optional, it's a compliance requirement. When your application connects to EHR systems like Epic or Cerner, you're handling OAuth tokens, API keys, and database passwords that protect patient data. AWS Secrets Manager provides a centralized service for storing, retrieving, and automatically rotating these sensitive credentials, removing the risk of hardcoded secrets scattered across your codebase.

For teams building SMART on FHIR applications, secrets management directly impacts both security posture and HIPAA compliance. At SoFaaS, we've seen firsthand how proper credential handling accelerates integration timelines while satisfying enterprise security requirements. Whether you're storing EHR connection strings or managing service account credentials, understanding how AWS Secrets Manager works gives you a foundation for secure application architecture.

This guide covers everything you need to know about AWS Secrets Manager: its core features, current pricing structure, and step-by-step instructions for implementation. You'll learn how automatic rotation works, when to use Secrets Manager versus other AWS services, and practical patterns for healthcare applications that demand both security and reliability.

What AWS Secrets Manager is and what it solves

AWS Secrets Manager is a managed service that stores and retrieves sensitive credentials through an encrypted, centralized repository. Instead of embedding database passwords, API keys, or OAuth tokens directly in your application code or configuration files, you store them in Secrets Manager and retrieve them programmatically at runtime. This approach eliminates hardcoded credentials while providing audit trails that document every access request.

The credential sprawl problem

Healthcare applications typically connect to multiple systems: EHR APIs, patient portals, lab interfaces, and internal databases. Each connection requires credentials, and development teams often distribute these secrets across environment variables, configuration files, and even source code repositories. When a credential needs rotation, you face the challenge of updating every location where it appears, creating downtime risks and security gaps.

Worse, hardcoded secrets in code repositories create permanent exposure risks. Even after you rotate compromised credentials, the old values remain visible in version control history. Teams building SMART on FHIR applications deal with this complexity multiplied by the number of EHR systems they integrate with, each requiring separate authentication tokens and connection strings.

How Secrets Manager centralizes access

AWS Secrets Manager gives you a single source of truth for all credentials. Your application makes API calls to retrieve secrets when needed, and you control access through IAM policies that specify which services or users can read specific secrets. This architecture means you can rotate credentials without redeploying applications, since the retrieval mechanism stays constant even when secret values change.

"Centralized secret storage transforms credential rotation from a deployment event into a background operation."

The service automatically encrypts secrets using AWS KMS keys and maintains a complete audit log through CloudTrail. For healthcare applications subject to HIPAA requirements, these features provide the documentation necessary to demonstrate compliance during audits. You can prove exactly who accessed which credentials and when, meeting the access control standards that healthcare organizations demand.

Real impact on healthcare applications

When you integrate with Epic or Cerner using SMART on FHIR, your OAuth client secrets and refresh tokens represent direct access to protected health information. Storing these in aws secrets manager ensures they never appear in application logs, error messages, or debugging output. The automatic rotation capabilities let you implement time-limited credentials that align with your organization's security policies without manual intervention.

Beyond security, Secrets Manager reduces operational overhead. Your team no longer coordinates credential updates across multiple deployment environments or worries about secrets expiring during off-hours. The service handles the complexity while your application simply requests current credentials through a consistent API interface.

Core concepts: secrets, versions, and rotation

AWS Secrets Manager organizes credentials around three fundamental concepts that determine how your applications access and update sensitive data. Understanding secrets as structured objects, version tracking mechanisms, and automated rotation workflows gives you the foundation for implementing secure credential management in healthcare applications.

Understanding secret structure

Each secret in AWS Secrets Manager contains key-value pairs stored as JSON or plain text strings. For SMART on FHIR integrations, you typically store OAuth client IDs, client secrets, and refresh tokens as separate keys within a single secret object. This structure lets you retrieve all credentials for a specific EHR connection through one API call rather than managing multiple separate secrets.

Secret names follow a hierarchical naming convention that you define, such as /production/epic/oauth-credentials or /staging/cerner/api-keys. This approach helps you organize secrets by environment and system, making it easier to apply IAM policies that restrict access based on deployment context.

Version management in practice

Every time you update a secret's value, AWS Secrets Manager creates a new version with a unique identifier while preserving previous versions. Your application can request the current version using the AWSCURRENT staging label, or retrieve specific historical versions when needed. This versioning system prevents the race condition where an application reads a credential mid-rotation and receives an inconsistent or incomplete value.

"Version staging labels eliminate the coordination overhead of credential updates across distributed applications."

Automatic rotation mechanics

Rotation occurs through Lambda functions that AWS Secrets Manager invokes on your defined schedule. The rotation function retrieves the current secret, creates new credentials in your target system (like an RDS database), updates the secret with new values, and verifies the new credentials work before marking the rotation complete. You configure rotation intervals from 1 to 365 days, and the service handles all timing and retry logic automatically.

Security basics: IAM, KMS, and VPC endpoints

AWS Secrets Manager implements three layers of security that control who accesses your credentials, how the service encrypts stored values, and where network traffic flows. You configure access policies through IAM, protect data at rest with KMS encryption keys, and isolate network traffic using VPC endpoints. Together, these mechanisms create the defense-in-depth approach that healthcare applications require for HIPAA compliance.

IAM permissions model

You control access to secrets through IAM policies attached to users, roles, or services. A policy specifies which principals can perform actions like secretsmanager:GetSecretValue or secretsmanager:UpdateSecret on specific secret ARNs. For SMART on FHIR applications, you typically grant your application's EC2 instance role permission to read EHR credentials while restricting rotation privileges to dedicated automation roles.

Resource-based policies attached directly to secrets provide an additional control layer. These policies let you grant cross-account access or enforce conditions like requiring MFA for manual secret retrieval. You combine identity-based and resource-based policies to implement least-privilege access that limits exposure if any single credential becomes compromised.

Encryption with KMS

AWS Secrets Manager encrypts all secrets using AWS KMS customer master keys that you specify or accepts a default AWS-managed key. The service encrypts secret values before storing them and decrypts them only when authorized requests arrive. For healthcare data environments, you should use customer-managed CMKs that give you control over key rotation policies and audit trails showing every encryption operation.

"Customer-managed KMS keys transform encryption from a background process into an auditable compliance control."

VPC endpoint isolation

VPC endpoints let your applications access aws secrets manager without routing traffic through the public internet. You create an interface endpoint in your VPC that provides a private IP address for the Secrets Manager API, ensuring all credential retrieval requests stay within your AWS network perimeter. This configuration satisfies security requirements that prohibit protected health information from traversing public networks, even in encrypted form.

Features that matter for real deployments

AWS Secrets Manager provides capabilities that extend beyond basic credential storage when you deploy healthcare applications at scale. You need automatic rotation without application downtime, cross-region replication for disaster recovery, and native integrations with common application frameworks. These features transform Secrets Manager from a credential vault into an operational component that actively maintains security posture while your applications run.

Automatic rotation with minimal downtime

Rotation functions execute on schedules you define while keeping your application connections active. The service maintains both old and new secret versions during transition periods, letting your application continue using existing credentials while rotation completes. You configure rotation intervals based on your security policies, and aws secrets manager handles all coordination with target systems like RDS databases or OAuth providers.

Built-in rotation templates exist for Amazon RDS, Redshift, and DocumentDB, requiring minimal configuration beyond specifying database connection details. For custom systems like EHR APIs, you write Lambda functions that implement your specific rotation logic. The service automatically retries failed rotations and sends CloudWatch Events when rotation succeeds or encounters errors.

"Rotation transparency means your application never knows when credentials change, only that current values always work."

Cross-region replication

You replicate secrets to multiple AWS regions for disaster recovery and low-latency access across geographic deployments. Replication occurs automatically when you update the primary secret, maintaining consistency across all configured regions. Healthcare applications serving multiple facilities benefit from reduced latency when each region reads from local replicas rather than making cross-region API calls.

Native framework integrations

AWS provides SDKs and extensions that cache retrieved secrets within your application runtime. Parameter Store integration lets you reference Secrets Manager values alongside standard configuration, creating unified access patterns. The caching layer reduces API calls and associated costs while maintaining security through configurable refresh intervals.

Pricing and cost controls

AWS Secrets Manager charges based on two primary metrics: the number of secrets you store and the volume of API calls your applications make to retrieve them. You pay $0.40 per secret per month (prorated for partial months), plus $0.05 per 10,000 API calls. These costs accumulate quickly in production environments where multiple applications retrieve credentials frequently, making cost optimization an important consideration for teams managing dozens of EHR integrations.

Per-secret storage charges

The monthly fee applies to each active secret regardless of size or complexity. If you store OAuth credentials for 50 different EHR connections, you pay $20 per month for storage alone. Deleted secrets stop incurring charges immediately, but aws secrets manager retains them for a seven-day recovery window before permanent deletion. You can reduce storage costs by consolidating related credentials into single JSON objects rather than creating separate secrets for each component.

API call costs and caching

Every GetSecretValue request counts toward your API call usage, which becomes significant when applications retrieve credentials on each request or function invocation. You control these costs through client-side caching that stores retrieved secrets in memory for configurable intervals. The AWS SDK provides built-in caching libraries that reduce API calls by 90% or more while maintaining security through automatic cache expiration.

"Caching transforms per-request retrieval costs into per-deployment charges without sacrificing credential freshness."

Practical cost management

You monitor spending through AWS Cost Explorer tags applied to secrets, letting you track expenses by application, environment, or business unit. Setting up CloudWatch alarms for unexpected API call spikes helps you detect misconfigured applications before costs escalate. For high-volume production systems, consider Parameter Store as a lower-cost alternative for non-sensitive configuration data, reserving Secrets Manager for credentials that require rotation capabilities.

How to use AWS Secrets Manager end to end

You implement aws secrets manager through a four-step workflow that moves from initial secret creation to automated rotation. This process takes less than an hour for basic implementations but establishes production-ready credential management that scales with your healthcare application. You work primarily through the AWS Console for initial setup, then transition to SDK-based retrieval in your application code.

Creating your first secret

You navigate to the Secrets Manager console and click "Store a new secret" to begin. Select the secret type based on your use case: choose "Credentials for RDS database" for managed database connections or "Other type of secret" for EHR OAuth tokens and API keys. Enter your credential values as key-value pairs, then specify a KMS encryption key and assign a descriptive name like /production/epic/oauth-client.

The console guides you through optional rotation configuration during creation, but you can skip this initially and configure it later once your basic integration works.

Retrieving secrets in code

Your application retrieves secrets through the AWS SDK using the GetSecretValue API call. You provide the secret name or ARN, and the SDK returns the current secret value along with version metadata. Install the Secrets Manager caching library to reduce API calls and costs while maintaining automatic cache invalidation when secrets rotate.

"Client-side caching reduces retrieval latency from 50ms to under 1ms while cutting API costs by 95%."

Configuring automatic rotation

You enable rotation from the secret details page by selecting a rotation interval and specifying the Lambda function that performs credential updates. AWS provides pre-built rotation functions for RDS, or you write custom functions for systems like EHR APIs that follow their specific authentication workflows.

Final thoughts

AWS Secrets Manager eliminates the credential management burden that slows healthcare application development. You gain centralized storage, automatic rotation, and enterprise-grade encryption without building these capabilities yourself. The service handles operational complexity while providing the audit trails and access controls that HIPAA compliance requires.

The costs remain predictable when you implement client-side caching and consolidate related credentials into single secret objects. For teams building SMART on FHIR integrations, the time savings from automated rotation and the security improvements from eliminating hardcoded credentials justify the monthly expenses. You reduce deployment risks while maintaining the credential hygiene that healthcare organizations demand.

When you build healthcare integrations, credential management represents just one component of a secure, compliant architecture. OAuth workflows, EHR connectivity, and data synchronization add complexity that extends beyond secrets alone. VectorCare's SoFaaS platform handles the entire SMART on FHIR integration stack, letting you focus on application features rather than infrastructure while we manage the underlying complexity.