Encrypt Data with AWS KMS: Keys, Policies, Rotation

By Kokil Thapa | Last reviewed: September 2026

Using AWS KMS to encrypt data is the standard way to protect database fields, uploaded documents, and API secrets without running your own hardware security modules. Plaintext PII in MySQL or S3 is a compliance failure waiting to happen, no matter how strong your firewall rules are. On production enterprise applications—legal-tech portals, booking systems, eCommerce backends—AWS Key Management Service gives you audited cryptography with policies you control. This guide walks through customer-managed keys, envelope encryption, least-privilege key policies, and automatic rotation for PHP and Laravel workloads on AWS.

How Do You Start Using AWS KMS to Encrypt Data With the Right Key Type?

Your first decision when using AWS KMS to encrypt data is symmetric versus asymmetric keys. Both exist in KMS, but they solve different problems in a web application stack.

Symmetric keys (AES-256-GCM) are the default for application encryption. One key encrypts and decrypts, which suits database columns, file blobs, and envelope encryption. I've used this pattern on legal-tech portals where client documents must stay encrypted at rest. Performance stays predictable, and KMS API costs remain manageable at scale.

Asymmetric keys (RSA or ECC) fit digital signatures, certificate workflows, or cases where an external party decrypts outside AWS. They are slower and costlier per operation. Unless you need non-repudiation or cross-party verification, stay with symmetric customer-managed keys (CMKs).

Creating a Customer-Managed Symmetric Key

AWS-managed keys cover basic service defaults. Production apps need CMKs for audit trails and policy control. Create one with the CLI in your target region—ap-south-1 (Mumbai) is common for Nepal-facing latency:

aws kms create-key \
  --key-usage ENCRYPT_DECRYPT \
  --key-spec SYMMETRIC_DEFAULT \
  --description "Production app data encryption key" \
  --tags TagKey=Environment,TagValue=Production \
  --region ap-south-1

Store the returned KeyId and ARN in AWS Secrets Manager or your deployment config. Never commit key ARNs to Git alongside ciphertext samples. Tag keys by environment so staging deployments cannot touch production CMKs—a mistake I've seen break production security posture during rushed releases.

AWS Managed Keys vs Customer Managed Keys

For application code that calls GenerateDataKey directly, CMKs are the right choice. Pair them with database encryption at rest on RDS for defence in depth.

What Is Envelope Encryption When Using AWS KMS to Encrypt Data?

Envelope encryption is why using AWS KMS to encrypt data scales in real applications. You do not call KMS for every row or file byte. Instead, KMS generates a data key; your app encrypts bulk data locally; KMS wraps only the small data key.

That pattern delivers three wins:

• Performance: OpenSSL or Sodium handles bulk AES locally; KMS sees one call per object or session
• Cost: KMS charges per API request—envelope encryption keeps the bill flat as data volume grows
• Isolation: Stolen ciphertext alone is useless without the KMS-protected data key

The dedicated walkthrough in our AWS KMS envelope encryption guide covers the same flow with S3 and RDS examples. The core idea stays identical for Laravel field encryption.

Laravel Implementation With the AWS SDK

Laravel 12 on PHP 8.3+ integrates cleanly with AWS SDK for PHP 3.x. Install the package and rely on EC2 instance profiles or ECS task roles—never long-lived access keys in .env:

composer require aws/aws-sdk-php-laravel

class DocumentEncryptionService
{
    public function encrypt(string $plaintext, string $keyId): array
    {
        $kms = app(\Aws\Kms\KmsClient::class);

        $result = $kms->generateDataKey([
            'KeyId' => $keyId,
            'KeySpec' => 'AES_256',
        ]);

        $iv = random_bytes(12);
        $tag = '';
        $ciphertext = openssl_encrypt(
            $plaintext,
            'aes-256-gcm',
            $result['Plaintext'],
            OPENSSL_RAW_DATA,
            $iv,
            $tag
        );

        return [
            'encrypted_key' => base64_encode($result['CiphertextBlob']),
            'iv' => base64_encode($iv),
            'tag' => base64_encode($tag),
            'ciphertext' => base64_encode($ciphertext),
        ];
    }
}

Store the four-part bundle as JSON in your database column. Use the Base64 encoder tool during debugging to inspect structure—not plaintext. On document portals like client portals with file sharing, this pattern protects uploads before they reach S3-backed storage.

How Do Key Policies Control Access When Using AWS KMS to Encrypt Data?

KMS authorization is dual-layer: the key policy on the CMK and IAM policies on the caller. Both must allow an action. That design prevents a misconfigured IAM role alone from decrypting production data—a pattern aligned with AWS IAM least privilege.

Write key policies with these rules:

1. Keep the account root principal — removing it can lock out all administrators permanently
2. Name explicit IAM role ARNs — avoid "Principal": "*" on encryption actions
3. Grant only required actions — apps typically need kms:GenerateDataKey, kms:Decrypt, kms:DescribeKey
4. Add condition keys — restrict by VPC endpoint, source account, or kms:ViaService

Production Key Policy Template

{
    "Version": "2012-10-17",
    "Id": "app-data-key-policy",
    "Statement": [
        {
            "Sid": "EnableRootAccountAccess",
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "AllowAppEncryption",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/LaravelAppRole"
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:GenerateDataKey",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowDevOpsAdmin",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/DevOpsAdminRole"
            },
            "Action": [
                "kms:Create*", "kms:Describe*", "kms:Enable*",
                "kms:List*", "kms:Put*", "kms:Update*",
                "kms:Get*", "kms:TagResource", "kms:ScheduleKeyDeletion"
            ],
            "Resource": "*"
        }
    ]
}

Apply the policy after key creation:

aws kms put-key-policy \
  --key-id mrk-abc123def456 \
  --policy-name default \
  --policy file://key-policy.json

Official reference: the AWS KMS key policies documentation lists every condition key. Common production failures include missing DescribeKey, wrong region in kms:ViaService, and cross-account gaps where Account B's IAM allows decrypt but Account A's key policy does not.

Policy Mistakes That Break Decryption

• Granting kms:* to app roles — defeats CMK purpose; split read and write roles instead
• Omitting CloudWatch alarms on AccessDeniedException — silent auth drift goes unnoticed for weeks
• Using one CMK for staging and production — tag and isolate keys per environment
• Ignoring grant limits — legacy integrations sometimes use KMS grants; audit them quarterly

How Does Automatic Key Rotation Work for AWS KMS Encrypt Operations?

Automatic rotation is a core compliance control when using AWS KMS to encrypt data long-term. For symmetric CMKs, AWS generates new backing key material every 365 days. Your KeyId and ARN stay the same. Application code needs no changes.

What rotates: the internal backing key version. What stays fixed: key ID, ARN, aliases, and policies. KMS retains all previous backing versions so old ciphertext still decrypts. That behaviour is documented in the AWS KMS automatic key rotation guide.

Rotation Support by Key Type

Enable and Verify Rotation

aws kms enable-key-rotation --key-id mrk-abc123def456

aws kms get-key-rotation-status --key-id mrk-abc123def456

aws kms describe-key --key-id mrk-abc123def456 \
  --query 'KeyMetadata.KeyRotationEnabled'

Enable rotation immediately after CMK creation. There is no downside for symmetric keys. Disabling rotation later stops future rotations but keeps all prior backing versions available for decryption.

How Do You Deploy AWS KMS Encryption Safely in Production Laravel Apps?

Code is half the job. Infrastructure choices determine whether using AWS KMS to encrypt data actually protects you or adds friction without benefit. Teams comparing AWS cloud hosting against shared hosting in Nepal often choose AWS partly because KMS, IAM, and CloudTrail integrate natively.

Use IAM Roles, Not Static Access Keys

Attach an instance profile or ECS task role to your Laravel EC2 deployment:

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": ["kms:Decrypt", "kms:GenerateDataKey", "kms:DescribeKey"],
        "Resource": "arn:aws:kms:ap-south-1:123456789012:key/mrk-abc123def456"
    }]
}

Separate read-only and write-capable roles where possible. Queue workers that only decrypt inbound files should not hold kms:Encrypt permission. Align this with CI/CD secrets management so pipeline keys never share the production CMK.

Handle KMS Failures Explicitly

KMS APIs fail for real reasons. Build handlers for each case:

• Throttling (LimitExceededException): Exponential backoff with jitter; request quota increases for high-volume batch jobs
• Disabled key: Alert ops immediately—usually indicates a security incident or misclick
• Scheduled deletion: CloudWatch alarm on ScheduleKeyDeletion events; data is unrecoverable after the waiting period
• Access denied: Run aws sts get-caller-identity on the instance to confirm the assumed role matches policy expectations

For traffic spikes, cache decrypted data keys in Redis 8.x with a short TTL—minutes, not hours. Encrypt cached keys with a separate local secret from Secrets Manager. This mirrors patterns in Redis caching for web apps but with tighter expiry.

Nepal Compliance and Data Residency Notes

Nepal's data privacy requirements for web apps push teams toward encryption at rest, access logging, and breach readiness. KMS CloudTrail events provide the audit trail regulators expect. Store ciphertext in ap-south-1 unless contract terms require another region. Document which fields are encrypted, which CMK protects them, and who can decrypt—auditors ask for this mapping on every API-driven system review.

Testing and Backup Considerations

Never run integration tests against production CMKs. Create a dedicated test key with a permissive policy scoped to CI runner roles. Validate envelope logic offline with sample payloads before deploy.

Backups need the same key access as production. If you restore a database snapshot to a new account, the CMK policy must grant the restored environment decrypt rights—or re-encrypt data under a new key during migration. Plan this before an incident; our cloud backup and disaster recovery guide covers the wider playbook.

For automation outside PHP, Boto3 scripts can rotate aliases, audit key policies, and report unrotated CMKs across accounts. Larger teams sometimes compare KMS with multi-cloud secrets management approaches, but on AWS-native stacks, KMS plus Secrets Manager remains the straightforward path.

Key Takeaways

• Use symmetric customer-managed keys and envelope encryption when using AWS KMS to encrypt data at application scale
• Both the CMK key policy and the caller IAM policy must allow each action—test with CloudTrail, not assumptions
• Enable automatic rotation on every eligible symmetric CMK the day you create it; old ciphertext keeps decrypting
• Attach IAM roles to EC2/ECS/Lambda—never store AWS access keys in Laravel .env files for KMS access
• Store encrypted_key, IV, tag, and ciphertext together; handle throttling and key-disable errors explicitly in code
• Document which fields are encrypted and which CMK protects them before your first compliance audit

People Also Ask

What is the difference between aws kms encrypt and GenerateDataKey?

Encrypt wraps small payloads (up to 4 KB) directly with the CMK. GenerateDataKey returns a plaintext data key plus a KMS-wrapped copy—the standard entry point for envelope encryption on larger files or database columns. Most Laravel apps should call GenerateDataKey, encrypt locally, and discard the plaintext key from memory.

Does AWS KMS encryption affect application performance?

KMS API latency is typically single-digit milliseconds per call. Envelope encryption avoids per-row KMS calls, so bulk operations stay fast. The local AES step dominates CPU time. Bottlenecks appear only when you call Encrypt directly on large volumes or skip caching during sustained traffic spikes.

Can I use AWS KMS to encrypt data outside of AWS?

Yes. Any environment with valid AWS credentials and network access to the KMS endpoint can call the API. Hybrid setups use IAM roles, STS temporary credentials, or VPC endpoints. Ciphertext remains portable—decryption requires KMS access to the same CMK regardless of where encryption ran.

How much does AWS KMS cost for a typical web application?

Each CMK costs about USD 1 per month (~Rs 135). API requests add roughly USD 0.03 per 10,000 calls. Envelope encryption keeps request counts low—a Laravel portal encrypting thousands of documents daily often stays under USD 5/month (~Rs 675) total for KMS, excluding data transfer.

Build Encryption Into Your Architecture From Day One

Using AWS KMS to encrypt data is not a launch-week afterthought—it belongs in your schema design, deployment roles, and audit checklist from the start. Symmetric CMKs, envelope encryption, tight key policies, and automatic rotation give you defensible cryptography without HSM operations overhead. If you are shipping a compliance-sensitive platform and want help wiring KMS into Laravel, S3, or RDS, contact us to discuss your architecture or reach out directly about encryption requirements.