DocumentDB Support for Bike4Mind
This document explains how to configure Bike4Mind to use AWS DocumentDB instead of MongoDB Atlas.
Overview
Bike4Mind now supports both MongoDB Atlas and AWS DocumentDB as database backends. This is controlled via a feature flag that can be set during deployment.
How It Works
-
Certificate Management: DocumentDB requires a TLS certificate for secure connections. The certificate is embedded in the codebase as a base64-encoded string and written to
/tmp/certs/rds-ca-bundle.pem
at runtime. -
Automatic Detection: The system can automatically detect DocumentDB connections based on the connection string, or you can explicitly set the database type via environment variable.
-
Connection String Modification: When DocumentDB is detected, the connection string is automatically modified to include the certificate path.
Configuration
Method 1: Environment Variable (Recommended)
Set the MAIN_DB_TYPE
environment variable when deploying:
MAIN_DB_TYPE=DocumentDB npx sst deploy --stage twinspires-staging
Valid values:
MongoAtlas
(default)DocumentDB
Method 2: Automatic Detection
If MAIN_DB_TYPE
is not set, the system will automatically detect DocumentDB based on the connection string containing:
docdb
documentdb
.rds.amazonaws.com
Method 3: Certificate via Environment Variable
For security reasons, you can also provide the certificate via environment variable instead of embedding it:
# Download and convert the certificate
./scripts/update-documentdb-cert.sh
# Set the environment variable with the certificate content
export DOCUMENTDB_CA_BUNDLE_BASE64=$(cat global-bundle-base64.txt)
# Deploy with the certificate
npx sst deploy --stage twinspires-staging
Setting Up DocumentDB
-
Create DocumentDB Cluster: Create a DocumentDB cluster in your AWS account with the desired configuration.
-
Security Group: Ensure the security group allows connections from your Lambda functions (typically the VPC where your Lambdas run).
-
Connection String: Your DocumentDB connection string should look like:
mongodb://username:password@docdb-cluster-name.cluster-xxxxx.region.rds.amazonaws.com:27017/database?ssl=true&replicaSet=rs0&readPreference=secondaryPreferred&retryWrites=false
-
Store in SST Secrets: Store the connection string as an SST secret:
npx sst secrets set MONGODB_URI "your-documentdb-connection-string" --stage twinspires-staging
Implementation Details
The implementation consists of:
-
Certificate Manager (
documentdb-cert-manager.ts
):- Writes the AWS certificate to
/tmp/certs/rds-ca-bundle.pem
on Lambda cold start - Automatically detects DocumentDB connections
- Modifies connection strings to include the certificate path and required parameters
- Writes the AWS certificate to
-
MongoDB Connection (
mongo.ts
):- Enhanced to detect and handle DocumentDB connections
- Automatically applies certificate configuration
- Maintains backward compatibility with MongoDB Atlas
-
Environment Variables:
MAIN_DB_TYPE
: Controls database type (MongoAtlas or DocumentDB)DOCUMENTDB_CA_BUNDLE_BASE64
: Optional certificate override
Important Notes
-
Certificate Updates: The embedded certificate is AWS's global certificate bundle. If AWS updates this certificate, you'll need to update the base64-encoded certificate in
documentdb-cert-manager.ts
. -
Performance: The certificate file is written once per Lambda cold start to
/tmp
. Subsequent requests reuse the existing file. -
Compatibility: DocumentDB has some MongoDB feature limitations. Ensure your application's MongoDB usage is compatible with DocumentDB.
-
No Breaking Changes: This implementation is feature-flagged and won't affect existing MongoDB Atlas deployments.
-
VPC Requirements: Unlike MongoDB Atlas, DocumentDB requires your Lambda functions to be in a VPC. Ensure your SST configuration includes VPC settings.
Troubleshooting
Common Errors
"Unsupported mechanism [ -301 ]"
This error indicates an authentication mechanism mismatch. DocumentDB only supports SCRAM-SHA-1.
Solution: The certificate manager now automatically adds these required parameters:
authMechanism=SCRAM-SHA-1
authSource=admin
retryWrites=false
If you're still seeing this error, ensure your connection string doesn't already have a conflicting authMechanism
parameter.
Certificate Not Found
If you see certificate path errors, the certificate manager may not have run yet.
Solution: The certificate is written on first connection attempt. Check Lambda logs for certificate creation messages.
Connection Timeouts
Ensure your Lambda functions are in the same VPC as your DocumentDB cluster and security groups allow the connection.
Testing Your Connection
You can test your DocumentDB connection using mongosh:
mongosh "mongodb://username:password@cluster.region.docdb.amazonaws.com:27017/dbname?authSource=admin&authMechanism=SCRAM-SHA-1&tls=true&tlsCAFile=/path/to/global-bundle.pem&retryWrites=false"
Testing
To test locally with DocumentDB:
- Set up an SSH tunnel to your DocumentDB cluster
- Set
MAIN_DB_TYPE=DocumentDB
in your.env
file - Use the tunneled connection string
Example SSH tunnel:
ssh -i your-key.pem -L 27017:docdb-cluster.cluster-xxxxx.region.rds.amazonaws.com:27017 ec2-user@your-bastion-host
Then use mongodb://username:password@localhost:27017/database
as your connection string.
Future Improvements
- Certificate Rotation: Implement automatic certificate rotation when AWS updates certificates.
- Multi-Region Support: Add region-specific certificate bundles for optimized performance.
- Connection Pooling: Optimize connection pooling settings for DocumentDB's specific characteristics.