ডেটাবেসের নিরাপত্তা আর RDS Proxy

এই লেসন শেষে তুমি পারবে

• RDS আর Aurora-র encryption at rest কী কী ঢেকে রাখে, কখন বেছে নিতে হয়, আর read replica, snapshot ও অন্য Region-এ copy করার নিয়মগুলো বুঝিয়ে বলতে।
• চালু থাকা unencrypted database-কে encrypt করতে (snapshot → encrypted copy → restore), আর encrypted snapshot অন্য account-এর সাথে share করতে।
• সব engine-এ TLS বাধ্যতামূলক করতে, আর RDS-এর certificate authority আর ২০২৪ সালের CA বদলের ঘটনাটা ব্যাখ্যা করতে।
• Password, Secrets Manager, IAM database authentication আর Kerberos-এর মধ্যে ঠিকটা বাছতে, আর প্রত্যেকটার সীমা জানতে।
• Private subnet, DB subnet group আর app tier-এর security group-কে উৎস ধরা security group দিয়ে database-কে network-এ আটকে রাখতে।
• ঠিক audit tool বাছতে: CloudWatch Logs-এ database log, Database Activity Streams, নাকি CloudTrail।
• RDS Proxy বোঝাতে: Lambda-র জন্য connection pooling, multiplexing আর pinning, দ্রুত failover, IAM আর Secrets Manager, আর এর সীমাবদ্ধতা।
• Database security আর RDS Proxy নিয়ে পরীক্ষার প্রতিটা প্রশ্নের ধরন চিনে ফেলতে।

#স্তরে স্তরে নিরাপত্তা

লেসন ৭.১ থেকে ৭.৩-এ আমরা database বানিয়েছি। এই লেসনে সেগুলোতে তালা লাগাব, তারপর দেখব serverless application সবচেয়ে বেশি যেভাবে database-কে কাবু করে ফেলে, সেটা কীভাবে সারাতে হয়। AWS-এ database security হলো কয়েকটা আলাদা আলাদা স্তর; হামলাকারীকে সবগুলো পেরোতে হয়, আর পরীক্ষায় প্রতিটা স্তর নিয়ে আলাদা করে প্রশ্ন আসে।

আলাদা করে না বললে নিচের সবকিছু RDS আর Aurora দুটোর জন্যই খাটে।

#Encryption at rest

#কী কী encrypt হয়

Enable encryption-এ টিক দিলে (CLI-তে --storage-encrypted) RDS AWS KMS-এর একটা key দিয়ে AES-256 encryption চালায়, আর encrypt হয়:

• instance-এর storage volume,
• তার log,
• তার automated backup আর snapshot,
• তার read replica।

Engine আর তোমার application সাধারণ data-ই দেখে; নিচে বসে RDS encrypt আর decrypt করে, performance-এ খরচ খুবই সামান্য। এটা server-side encryption, ঠিক S3-এর SSE-KMS-এর মতো। লেসন ৫.২-এ দেখেছ EBS-এ KMS-এর envelope encryption কীভাবে চলে; RDS-ও প্রতিটা volume-এর জন্য একটা data key নিয়ে হুবহু তাই করে।

সব engine আর প্রায় সব বর্তমান instance class-এ encryption পাওয়া যায় (শুধু db.t2.micro, M1, M2-এর মতো খুব পুরনো কয়েকটা class-এ নেই)।

#Key: AWS managed নাকি customer managed

কোনো key-এর নাম না দিলে RDS aws/rds নেয়। Share করতে গিয়ে সবচেয়ে বেশি যে ঝামেলা হয়, তার মূলে এই default-টাই, নিচে দেখবে।

#নিয়মগুলো: বানানোর সময়ই বাছো, আর সেটাই থেকে যায়

• Encryption চালু করা যায় শুধু instance বানানোর সময়। চালু instance-কে encrypt করার কোনো modify option নেই।
• একবার চালু হলে আর বন্ধ করা যায় না, আর encrypted instance-এর KMS key-ও জায়গায় বসে বদলানো যায় না।
• Unencrypted instance-এর snapshot unencrypted; encrypted instance-এর snapshot একই key দিয়ে encrypted।
• Read replica primary-কে অনুসরণ করে: unencrypted primary-র encrypted replica হয় না, encrypted primary-র unencrypted replica-ও হয় না। একই Region-এ replica primary-র key-ই ব্যবহার করে।
• KMS key Region-ভিত্তিক। Encrypted database-এর cross-Region read replica বা অন্য Region-এ snapshot copy করতে গন্তব্য Region-এর একটা KMS key লাগে।
• Unencrypted snapshot থেকে সরাসরি encrypted RDS instance restore করা যায় না; encryption যোগ হয় snapshot copy করার সময়।
• Primary আর replica-র মধ্যে replication traffic, database unencrypted হলেও, পথে encrypted থাকে, Region পেরোলেও।

#চালু unencrypted database-কে encrypt করা

Note যেটাকে সবচেয়ে গুরুত্বপূর্ণ ট্রিক বলেছে: “তোমার একটা unencrypted database আছে, এখন এটাকে encrypt করতে হবে। কীভাবে?” জায়গায় বসে encrypt করা যায় না, তাই এর একটা encrypted কপি বানাতে হয়:

1. একটা manual snapshot নাও

   আগে application-এর লেখা থামাও (বা পরে সেগুলো ধরার পরিকল্পনা রাখো), তারপর unencrypted instance-এর একটা manual snapshot নাও। এই snapshot-টা unencrypted।

2. Encryption দিয়ে snapshot copy করো

   Snapshot-টা copy করো, আর copy-র সময় একটা KMS key দিয়ে Enable encryption বেছে নাও (aws rds copy-db-snapshot --kms-key-id …)। Encryption যোগ হয় ঠিক এই copy-র ধাপেই। Snapshot কখনো share করার সম্ভাবনা থাকলে customer managed key নাও।

3. Encrypted copy থেকে নতুন instance restore করো

   Restore হওয়া instance encrypted, আর এখন থেকে এর থেকে যা কিছু তৈরি হবে সবই encrypted: backup, snapshot, replica, log।

4. Application ঘুরিয়ে দাও, পুরনোটা গোছাও

   নতুন instance-এর endpoint নতুন। Application-কে সেখানে ঘুরিয়ে দাও (বা instance-গুলোর নাম বদলে পুরনো endpoint নামটা নতুনটায় নিয়ে আসো), যাচাই করো, দরকারি read replica আবার বানাও, তারপর পুরনো instance মুছে দাও।

দুটো বাস্তব কথা। Snapshot নেওয়ার পরের লেখাগুলো হারিয়ে যায় যদি না তুমি লেখা থামিয়ে থাকো; তাই হয় ছোট একটা maintenance window নাও, নয়তো AWS DMS দিয়ে cut-over পর্যন্ত পুরনো instance-এর পরিবর্তনগুলো নতুনটায় replicate করতে থাকো। আর encrypted database-এর KMS key বদলাতেও এই একই snapshot-copy পথ।

পাশের কথা (নতুন option): RDS Blue/Green deployment এখন green environment-টা encrypted (বা অন্য key দিয়ে) বানিয়ে মোটামুটি এক মিনিটে switch করতে পারে, আর Aurora-তে restore-এর সময় একটা KMS key-এর নাম দিলেই unencrypted cluster snapshot সরাসরি encrypted cluster-এ restore হয়। তবে পরীক্ষা এখনো ক্লাসিক উত্তরটাই চায়: snapshot → encryption দিয়ে copy → restore।

#Encrypted snapshot অন্য account-এর সাথে share করা

Snapshot share করা মানে (লেসন ৭.২) অন্য একটা account-কে সেটা copy বা restore করার অনুমতি দেওয়া। Encrypted snapshot-এর বেলায়:

1. AWS managed key aws/rds দিয়ে encrypt করা snapshot share করা যায় না, কারণ ওই key-এর policy-তে কেউ অন্য account যোগ করতে পারে না।
2. Snapshot-টা একটা customer managed key দিয়ে আবার copy করো, আর key policy-তে গন্তব্য account-কে অনুমতি দাও (kms:Decrypt, kms:DescribeKey, kms:CreateGrant)।
3. Snapshot share করো (modify-db-snapshot-attribute --attribute-name restore --values-to-add 444455556666)।
4. গন্তব্য account সেটা copy করে নেয়, ভালো হয় নিজের key দিয়ে আবার encrypt করে, তারপর restore করে। নইলে তার database তোমার key-এর ওপর নির্ভর করে থাকে: তুমি key বন্ধ করলে তার database-ও থেমে যায়।

Encrypted snapshot কখনো public করা যায় না।

#Key হারিয়ে গেলে

Key-ও database-এর availability-র অংশ। কেউ KMS key disable করে দিলে RDS আর সেটা ছুঁতে পারে না; প্রায় ২ ঘণ্টা পর instance inaccessible-encryption-credentials-recoverable অবস্থায় গিয়ে বন্ধ হয়ে যায়। ৭ দিনের মধ্যে key আবার enable করে instance start করলে সে ফিরে আসে; তারপর অবস্থাটা চূড়ান্ত, তখন শুধু backup থেকে restore ভরসা। যে instance বন্ধ করা যায় না (read replica, বা যার replica আছে), সে সরাসরি চূড়ান্ত অবস্থায় চলে যায়। যে key কোনো database এখনো ব্যবহার করছে, সেটা মোছার schedule কখনো দিও না: key মুছে গেলে ওই key দিয়ে encrypt করা প্রতিটা backup চিরতরে হারায়।

#Oracle আর SQL Server-এর TDE

Transparent Data Encryption (TDE) হলো database engine-এর নিজের করা encryption। RDS এটা সমর্থন করে Oracle-এ (Oracle Advanced Security-র একটা option) আর SQL Server-এ (Enterprise Edition আর নতুন Standard Edition version), চালু করতে হয় option group দিয়ে। RDS-এর storage encryption-এর সাথে একসাথেও TDE চালানো যায়, performance-এ সামান্য খরচে, দুটোর key আলাদা। কোনো compliance নিয়ম বা migrate করে আনা application যদি নির্দিষ্টভাবে engine-level encryption চায়, তখন এটা নাও; নইলে RDS-এর encryption at rest-ই সহজ উত্তর।

#Encryption in flight

#TLS আর RDS-এর certificate authority

Encryption in flight client আর database-এর মাঝের network-এ query আর result-কে রক্ষা করে। RDS আর Aurora-র সব engine TLS সমর্থন করে (লোকে এখনো SSL বলে)। Database একটা server certificate দেখায়, যেটা sign করেছে একটা RDS certificate authority (CA); client-এর উচিত ওই CA-কে বিশ্বাস করে certificate যাচাই করা, যাতে সে নিশ্চিত হয় আসল database-এর সাথেই কথা বলছে, মাঝখানে বসা কারো সাথে না।

• Client certificate bundle নামিয়ে নেয় (global-bundle.pem, বা প্রতি Region-এর bundle), আর পুরো যাচাই সহ connect করে, যেমন PostgreSQL client-এ sslmode=verify-full, MySQL client-এ --ssl-mode=VERIFY_IDENTITY।
• এই CA-গুলোতে মেয়াদ ফুরানোর আগেই RDS server certificate নিজে থেকে rotate করে। তোমার application-এ শুধু root CA-কে বিশ্বাস করো, intermediate certificate কখনো না।
• ২০২৪-এর CA বদল: পুরনো rds-ca-2019 CA-র মেয়াদ শেষ হয়েছে আগস্ট ২০২৪-এ। প্রতিটা instance-কে নতুন একটা CA-তে যেতে হয়েছিল, আর certificate যাচাই করে এমন প্রতিটা client-কে নতুন bundle-এ বিশ্বাস রাখতে হয়েছিল; যারা পুরনো certificate আঁকড়ে ধরে ছিল, সেই application-গুলো ঠিক সেদিনই ভেঙে পড়ে। পরীক্ষার প্রশ্নে এটাই আসতে পারে “CA বদলানোর পর connection fail করছে” রূপে।
• RDS Proxy এর বদলে ACM-এর certificate ব্যবহার করে, তাই proxy-র client-দের RDS bundle লাগে না।

Note নিয়ে একটা কথা: database traffic সাধারণত VPC-র ভেতরেই থাকে, internet-এ যায় না, তবু সেটা ভাগাভাগি করা network-এর ওপর দিয়েই যায়, আর compliance-এর নিয়ম (PCI DSS, HIPAA) একে encrypt করতেই বলে।

#TLS বাধ্যতামূলক করা

Default-এ বেশিরভাগ engine TLS নেয়, কিন্তু চায় না। Plain-text connection ফিরিয়ে দিতে DB parameter group-এ (Aurora-তে DB cluster parameter group) একটা parameter সেট করো:

Note-এর একটা সংশোধন: MySQL-এর জন্য note-এ লেখা REQUIRE SSL। ওটা CREATE USER / ALTER USER-এর একজন user-এর clause, parameter না। PostgreSQL-এর rds.force_ssl-এর মতো পুরো instance-এর সুইচ হলো require_secure_transport। প্রশ্ন একজন user নিয়ে হলে দুটোই চলে; “সব connection” বললে parameter-টা বাছো।

#Authentication: কে login করতে পারবে

#Master user আর password

প্রতিটা instance বানানো হয় একটা master user দিয়ে, যার অধিকার অনেক বেশি (তবে superuser না): RDS-এ engine-এর আসল root কখনো পাও না। Application-এর জন্য আলাদা, কম অধিকারের database user বানানো উচিত। Login-এর default উপায় password, আর তার দুর্বলতা চোখের সামনেই: config file, environment variable আর Git history-তে পড়ে থাকে, কেউ বদলায় না।

Secrets Manager integration (২০২২-এর শেষ থেকে)। Manage master credentials in AWS Secrets Manager-এ টিক দিলে (CLI-তে --manage-master-user-password) RDS নিজেই master password বানায়, secret হিসেবে রাখে, আর default-এ প্রতি ৭ দিনে rotate করে। কারো সেটা জানারই দরকার নেই; application আর মানুষ IAM অনুমতি দিয়ে Secrets Manager থেকে তুলে নেয়, আর প্রতিটা পড়া CloudTrail-এ থাকে। Application user-দের জন্যও Secrets Manager-এর rotation function দিয়ে একই কাজ করা যায়।

#IAM database authentication

IAM database authentication-এ application কোনো password ছাড়াই login করে। তার বদলে ব্যবহার করে নিজের IAM পরিচয়:

1. Instance-এ IAM authentication চালু করো, আর এমন একটা database user বানাও যে IAM দিয়ে ঢোকে: MySQL-এ CREATE USER app_user IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';, PostgreSQL-এ CREATE USER app_user; GRANT rds_iam TO app_user;।
2. একটা IAM policy arn:aws:rds-db:us-east-1:111122223333:dbuser:db-ABCDEFGHIJKL01234/app_user-এর ওপর rds-db:connect অনুমতি দেয় (instance-এর resource ID আর database user)।
3. Application চলে EC2 instance role, Lambda execution role বা ECS task role নিয়ে, আর SDK-র কাছে একটা authentication token চায় (aws rds generate-db-auth-token)। SDK role-এর অস্থায়ী credential দিয়ে নিজের মেশিনেই সেটা sign করে (SigV4); কোনো API call হয় না।
4. সে TLS দিয়ে connect করে, password-এর জায়গায় token পাঠায়। RDS signature আর অনুমতি IAM-এর সাথে মিলিয়ে দেখে।

মনে রাখার মতো কথা:

• Token-এর মেয়াদ ১৫ মিনিট, আর দেখা হয় শুধু login-এর সময়: token-এর মেয়াদ ফুরালেও খোলা connection চলতে থাকে, কিন্তু প্রতিটা নতুন connection-এ নতুন token লাগে।
• Engine: MySQL, MariaDB আর PostgreSQL (RDS আর Aurora)। Oracle, SQL Server বা Db2-তে না; ওরা Kerberos ব্যবহার করে।
• IAM connection-এ TLS বাধ্যতামূলক।
• Access সামলানো হয় এক জায়গা থেকে, IAM-এ: role-এর অনুমতি তুলে নিলে কোথাও আর নতুন connection খোলে না।
• সীমা। IAM authentication-এ database-এর CPU আর memory খরচ হয় (AWS ৩০০ থেকে ১,০০০ MiB বাড়তি memory রাখতে বলে), আর এটা মাঝারি হারে connection খোলার জন্য। AWS আগে বলত মোটামুটি প্রতি সেকেন্ডে ২০০টার কম নতুন connection হলে এটা নাও; এখনকার documentation সংখ্যাটা তুলে দিয়েছে, সতর্কবাণীটা রেখেছে। Connection খোলার হার বেশি হলে সামনে RDS Proxy বসাও: client IAM দিয়ে proxy-তে ঢোকে, আর proxy অনেকক্ষণ টিকে থাকা connection ধরে রাখে।
• Token বানানো CloudTrail-এ লেখা হয় না (এটা নিজের মেশিনে করা একটা signature মাত্র)।

#Kerberos আর Microsoft Active Directory

যে কোম্পানি আগে থেকেই Active Directory-তে user সামলায়, তাদের জন্য RDS Kerberos authentication দেয় AWS Directory Service for Microsoft Active Directory দিয়ে (AWS Managed Microsoft AD, যেটা on-premises AD-কে trust করতে পারে)। User-রা কোম্পানির account দিয়ে single sign-on-এ login করে। চলে SQL Server, Oracle, MySQL, PostgreSQL আর Db2-তে (আর Aurora MySQL/PostgreSQL-এ)। প্রশ্নে “Windows authentication”, “বিদ্যমান Active Directory account ব্যবহার করো” থাকলে, বা SQL Server বা Oracle-এর সাথে কেন্দ্রীয় পরিচয়ের কথা থাকলে, এটাই উত্তর।

#Network: কে database পর্যন্ত পৌঁছাতে পারে

Packet database পর্যন্ত পৌঁছালে তবেই authentication-এর প্রশ্ন। VPC আর security group-এর লেসনে (Ch03–04) tool-গুলো শেখা হয়ে গেছে; database-এর জন্য সেগুলো এভাবে কাজে লাগে:

• Private subnet। Database থাকে private subnet-এ, যেখানে internet gateway থেকে কোনো route নেই।
• DB subnet group। তুমি যে DB subnet group দাও, RDS তার subnet-এ instance (আর Multi-AZ standby) বসায়; এতে অন্তত দুটো AZ-এর private subnet দাও।
• Publicly accessible = No। No থাকলে endpoint শুধু private address-এ resolve হয়। Yes দিলে RDS একটা public IP দেয়; তখনও security group আর subnet-এর route ঠিক করে কেউ পৌঁছাতে পারবে কি না। Production-এ No-ই রাখো।
• App tier-এর security group-কে উৎস ধরা। Database-এর security group database-এর port খোলে শুধু application-এর security group-এর জন্য:

Note ঠিক এই কথাটাই বলেছে: 10.0.0.5/32-এর মতো নির্দিষ্ট IP-কে অনুমতি দিও না। EC2 instance-গুলোর security group ID উৎস হিসেবে দাও, তাহলে Auto Scaling ওই group দিয়ে যে নতুন instance-ই চালু করুক, সে নিজে থেকেই অনুমতি পায়, আর VPC-র বাকি কেউ পায় না। Default port: MySQL/MariaDB/Aurora MySQL 3306, PostgreSQL 5432, SQL Server 1433, Oracle 1521। Port বদলানো কোনো নিরাপত্তা না; নিরাপত্তা দেয় security group।

• NACL দিয়ে subnet পর্যায়ে একটা deny বাড়তি যোগ করা যায়, তবে আসল কাজ করে security group।
• VPC endpoint। RDS-এর management API (create, modify, snapshot) একটা interface VPC endpoint দিয়ে (com.amazonaws.<region>.rds) private ভাবে ডাকা যায়। এতে শুধু API call যায়; database connection সবসময় VPC-র ভেতরে সরাসরি instance-এর endpoint-এ যায়।
• মানুষ কীভাবে ঢুকবে। Developer-রা private database-এ পৌঁছায় AWS Client VPN, Site-to-Site VPN, বা VPC-র ভেতরের একটা instance-এ Session Manager port-forwarding session দিয়ে, database-কে public করে কখনো না।

#SSH নেই, শুধু RDS Custom ছাড়া

RDS একটা managed service: operating system চালায় AWS, তাই host-এ SSH নেই, remote desktop-ও নেই। আচরণ বদলাও parameter group আর option group দিয়ে, log পড়ো console বা CloudWatch-এ, আর OS metric দেখো Enhanced Monitoring-এ।

Note-এর পরীক্ষার ট্রিক: প্রশ্নে যদি থাকে “OS-level access লাগবে”, “database host-এ একটা custom agent install করতে হবে” বা “host-এ custom script চালাতে হবে”, তাহলে সাধারণ RDS ভুল উত্তর। বাছো RDS Custom (Oracle আর SQL Server, যেখানে host-এ ঢোকা যায়; লেসন ৭.২) অথবা EC2-তে database চালাও।

#Audit আর monitoring

#Database log → CloudWatch Logs

প্রতিটা engine log লেখে: MySQL-এ error log, slow query log আর general log, PostgreSQL-এ postgresql log, Oracle-এর alert আর audit file, SQL Server-এর error আর agent log। কে কোন statement চালাল, তার আসল audit-এর জন্য engine-এর audit feature চালু করতে হয়:

Instance-এর ভেতরে রাখা log-এর আকার আর বয়স দুটোই সীমিত। CloudWatch Logs-এ publish করো (--cloudwatch-logs-export-configuration), তাহলে পাবে:

• তোমার পছন্দের লম্বা retention (এক দিন থেকে ১০ বছর, বা কখনো মুছবে না), slide যেমন বলে, “আরও বেশি দিন রাখার জন্য”;
• Logs Insights দিয়ে প্রায় real time-এ খোঁজা, metric filter আর alarm (ব্যর্থ login, DROP statement);
• S3 বা কোনো security analytics tool-এ export।

“Compliance-এর জন্য audit log অনেক দিন রাখো” আর “database log প্রায় real time-এ monitor করো”, দুই প্রশ্নেরই note-এর উত্তর এটা।

#Database Activity Streams

Database Activity Streams database-এর কাজকর্মের একটা প্রায় real-time ধারা পাঠায় Amazon Kinesis data stream-এ, তোমার KMS key দিয়ে encrypted। চলে Aurora PostgreSQL আর Aurora MySQL, RDS for Oracle আর RDS for SQL Server-এ। আসল গুণ: stream-টা সেট আর নিয়ন্ত্রণ হয় database-এর বাইরে থেকে, তাই database administrator-রাও চুপিচুপি বন্ধ বা বদলাতে পারে না। Regulated data-র জন্য auditor-রা ঠিক এই দায়িত্ব ভাগাভাগিটাই চায়। Kinesis থেকে Firehose event-গুলো S3-এ রাখে, আর security tool সেগুলো বিশ্লেষণ করে। Feature-টা নিজে ফ্রি; টাকা লাগে Kinesis-এর।

#CloudTrail API call-এর জন্য, SQL-এর জন্য না

CloudTrail লিখে রাখে RDS API-তে করা call: কে instance বা snapshot বানাল, বদলাল, মুছল বা share করল, কোথা থেকে। Database-এর ভেতরে চলা SQL সে দেখে না। “Snapshot কে মুছল?” → CloudTrail। “Row-গুলো কে মুছল?” → database-এর audit log বা activity stream।

#Performance monitoring, সংক্ষেপে

• CloudWatch metric: CPU, DatabaseConnections, ফাঁকা memory, IOPS, replica lag।
• Enhanced Monitoring: host-এর একটা agent থেকে OS-level metric, ১ সেকেন্ড পর্যন্ত সূক্ষ্ম।
• Performance Insights → CloudWatch Database Insights। Performance Insights দেখাত wait event আর SQL ধরে database-এর load। ২০২৫–২৬-এ AWS এটাকে CloudWatch Database Insights-এর (Standard আর Advanced mode) ভেতরে নিয়ে এসেছে; পুরনো Performance Insights console-এর মেয়াদ শেষ হয়েছে ৩১ জুলাই ২০২৬-এ। আগে লেখা পরীক্ষার প্রশ্নে এখনো “database load বাড়াচ্ছে কোন SQL খুঁজে বের করো”-র উত্তরে “Performance Insights” থাকে; একই tool-এর পরিবার।

#RDS Proxy

#সমস্যা: connection দামি জিনিস

Relational database প্রতিটা connection-এর জন্য আসল খাটুনি খাটে: TCP আর TLS handshake, authentication, session-এর জন্য memory। PostgreSQL তো প্রতিটা connection-এর জন্য আলাদা একটা backend process-ই চালু করে। তাই প্রতিটা instance-এর একটা ছাদ আছে, max_connections, যেটা RDS default-এ memory দেখে ঠিক করে: PostgreSQL-এ মোটামুটি RAM ÷ 9.5 MB (সর্বোচ্চ ৫,০০০), MySQL-এ RAM ÷ 12 MB। মানে 4 GiB-এর একটা instance-এ PostgreSQL connection চলে মোটামুটি ৪০০টা।

অনেকক্ষণ চলা server এই সমস্যা সামলায় application-এর ভেতরে একটা connection pool দিয়ে: ১০টা server × ২০টা pool-এর connection = ২০০, স্থায়ীভাবে। Lambda এই ছক ভেঙে দেয়:

• প্রতিটা execution environment নিজেই একটা ছোট্ট process, তার নিজের connection। Lambda-র default concurrency প্রতি Region-এ ১,০০০।
• Traffic হঠাৎ বাড়লে কয়েক সেকেন্ডে Lambda ১০ থেকে ১,০০০ environment-এ পৌঁছায়, ফলে একসাথে ১,০০০টা connection আসে। ৪০০-তে পৌঁছে database বলে “too many connections”, আর ৬০০টা invocation fail করে।
• ঝড়ের পর অলস environment-গুলো freeze হয়, বন্ধ হয় না, তাই তাদের connection খোলা থেকে জায়গা দখল করে রাখে।
• সীমায় না পৌঁছালেও দ্রুত দ্রুত connection খোলা-বন্ধ করতে database-এর CPU পুড়ে।

শুধু বেশি connection ধরার জন্য database বড় করা হলো দামি, ভুল সমাধান।

#RDS Proxy কী

Amazon RDS Proxy হলো একটা fully managed database proxy, যে application আর database-এর মাঝখানে বসে, আর অনেক client মিলে ভাগাভাগি করে ব্যবহার করে এমন একটা database connection-এর pool রাখে।

• Serverless আর highly available: load অনুযায়ী নিজে scale করে, কয়েকটা AZ জুড়ে চলে, সামলানোর মতো কোনো instance নেই।
• শুধু VPC: database-এর একই VPC-তে থাকতে হয়, আর কখনো publicly accessible না।
• Engine: RDS for MySQL, PostgreSQL, MariaDB আর SQL Server, আর Aurora MySQL ও PostgreSQL। Oracle না, Db2 না, RDS Custom for SQL Server-ও না।
• বেশিরভাগ application-এ code বদলাতে হয় না: connection string-এ শুধু endpoint বদলাও। Proxy শোনে 3306 (MySQL/MariaDB), 5432 (PostgreSQL) বা 1433 (SQL Server) port-এ।

#Pool কীভাবে কাজ করে: multiplexing, লাইন, pinning

• Multiplexing। একজন client একটা database connection ধরে রাখে শুধু একটা transaction চলার সময়টুকু, তারপর proxy সেটা আরেকজনকে দেয়। একটা Lambda run যদি ২০০ ms নেয় আর তার ২০ ms কাটে transaction-এ, তাহলে একসাথে চলা ১,০০০ function-এর লাগে মোটামুটি ১,০০০ × ২০ ÷ ২০০ = ১০০টা database connection।
• তোমার দেওয়া সীমা: MaxConnectionsPercent (default max_connections-এর ১০০%) ঠিক করে proxy সর্বোচ্চ কয়টা খুলবে, যাতে অন্য application আর admin-দের জন্য কিছু জায়গা থাকে; MaxIdleConnectionsPercent ঠিক করে কয়টা অলস connection গরম রাখবে।
• Fail না করে লাইনে দাঁড় করানো। Pool ব্যস্ত থাকলে client একটা ফাঁকা connection-এর জন্য অপেক্ষা করে, সর্বোচ্চ ConnectionBorrowTimeout পর্যন্ত (default ১২০ সেকেন্ড)। Latency বাড়ে, কিন্তু request ফেরত যায় না; সীমা পেরোলে proxy গুছিয়ে load ছাঁটে।
• Pinning। কোনো session যদি connection-এ নিজের state রেখে যায় (session-level SET, temporary table, user variable, কিছু prepared statement, ১৬ KB-র বড় statement), proxy সেই connection আর ভাগ করতে পারে না, session শেষ না হওয়া পর্যন্ত সেটা ওই client-এর সাথে pin করে রাখে। খুব বেশি pinning হলে proxy আবার এক client-এ এক connection-এ ফিরে যায়। pinned session-এর metric metric নজরে রাখো, আর এমন setting proxy-র initialization query-তে সরিয়ে দাও।
• অলস client connection বন্ধ হয় IdleClientTimeout-এর পর (default ৩০ মিনিট)।

#দ্রুত failover

Multi-AZ-এর primary নষ্ট হলে (লেসন ৭.১) RDS standby-কে promote করে আর endpoint-এর DNS record বদলে দেয়; একটা failover সাধারণত ৬০ থেকে ১২০ সেকেন্ড নেয়। Proxy না থাকলে application-এর সব connection ভেঙে যায়, আর যে client DNS cache করে রাখে, সে আরও বেশিক্ষণ মৃত address-এ চেষ্টা চালায়, শেষে সবাই একসাথে reconnect করে।

RDS Proxy থাকলে application-এর connection শেষ হয় proxy-তে, তাই সেগুলো খোলাই থাকে। Proxy DNS-এর অপেক্ষায় না থেকে নিজেই database instance-গুলোর ওপর নজর রাখে, নতুন primary তৈরি হওয়ামাত্র সেখানে connect করে, আর অপেক্ষায় থাকা query-গুলো চালিয়ে দেয়। AWS বলছে এতে RDS আর Aurora Multi-AZ database-এর failover-এর সময় সর্বোচ্চ ৬৬% কমে। নষ্ট হওয়ার মুহূর্তে যে transaction চলছিল সেটা তবুও rollback হয়, তাই application-এ retry-র ব্যবস্থা লাগবেই।

#Security: সামনে IAM, পেছনে Secrets Manager

• IAM authentication বাধ্যতামূলক করা যায়: client-কে IAM token দিয়ে proxy-তে ঢুকতে হবে (TLS বাধ্যতামূলক), তাই Lambda-র code বা environment-এ কোনো database password থাকে না। Execution role-এ proxy-র ওপর rds-db:connect লাগে।
• Credential থাকে Secrets Manager-এ: proxy database-এ login করে AWS Secrets Manager থেকে পড়া user name আর password দিয়ে (প্রতি proxy-তে সর্বোচ্চ ২০০টা secret)। Rotation হলে application না বদলেই proxy নতুনটা তুলে নেয়।
• End-to-end IAM (২০২৫-এর পাশের কথা): proxy এখন database-এও IAM database authentication দিয়ে ঢুকতে পারে, Secrets Manager secret ছাড়াই (SQL Server-এ না)।
• Client আর proxy-র মাঝে TLS বাধ্যতামূলক করা যায় (RequireTLS); proxy ACM-এর certificate ব্যবহার করে।

“Serverless function-কে নিরাপদে RDS-এ connect করো, code-এ credential না লিখে, secret এক জায়গায় সামলে, আর connection ফুরিয়ে না ফেলে”, এর জন্য note-এর পুরো উত্তর: Lambda + RDS Proxy + Secrets Manager + IAM authentication।

#Endpoint, quota আর দাম

#কখন দরকার নেই

অনেকক্ষণ চলা server-এ application, ভালো built-in connection pool আছে, traffic স্থির, failover-এর সময় নিয়ে মাথাব্যথা নেই: এদের লাভ সামান্য। যে workload প্রায় প্রতিটা session pin করে, তাদেরও লাভ কম। RDS Proxy সবচেয়ে কাজে লাগে Lambda আর অন্য স্বল্পায়ু client, হঠাৎ লাফানো traffic, এক database ভাগাভাগি করা অনেক ছোট service, আর failover-এ স্পর্শকাতর application-এর জন্য।

#System design-এ কীভাবে খাপ খায়

• স্তরে স্তরে প্রতিরক্ষা: আগে private subnet আর app tier-এর security group, তারপর জমা password ছাড়া authentication (IAM বা Secrets Manager), parameter দিয়ে TLS বাধ্যতামূলক, customer managed key দিয়ে encryption at rest, আর CloudWatch Logs বা activity stream-এ audit।
• Encryption-এর সিদ্ধান্ত প্রথম দিনেই। প্রতিটা production database encrypted অবস্থায় বানাও, আর snapshot কখনো account পেরোবে মনে হলে (DR copy, আলাদা backup account, partner-এর সাথে share) customer managed key নাও।
• Key-ও একটা নির্ভরতা। KMS key-কে কড়া key policy দিয়ে রক্ষা করো, আর CloudTrail-এ DisableKey আর ScheduleKeyDeletion দেখলে alarm বাজাও।
• Serverless data access: Lambda → RDS Proxy (IAM auth) → database, secret থাকে Secrets Manager-এ। একই proxy বাকি সবার failover-ও ছোট করে।
• যে সামলায় আর যে পড়ে, তাদের আলাদা রাখো: RDS API নিয়ন্ত্রণ করে IAM, SQL নিয়ন্ত্রণ করে database user; প্রথমটার audit CloudTrail, দ্বিতীয়টার database audit log বা activity stream।

#নিজে করে দেখো

# 1. Is this instance encrypted, and with which key?
aws rds describe-db-instances --db-instance-identifier shop-db \
  --query "DBInstances[0].[StorageEncrypted,KmsKeyId,CACertificateIdentifier,PubliclyAccessible]"

# 2. Encrypt an unencrypted instance: snapshot → encrypted copy → restore
aws rds create-db-snapshot --db-instance-identifier shop-db \
  --db-snapshot-identifier shop-db-plain
aws rds wait db-snapshot-available --db-snapshot-identifier shop-db-plain
aws rds copy-db-snapshot --source-db-snapshot-identifier shop-db-plain \
  --target-db-snapshot-identifier shop-db-enc \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab
aws rds wait db-snapshot-available --db-snapshot-identifier shop-db-enc
aws rds restore-db-instance-from-db-snapshot --db-instance-identifier shop-db-encrypted \
  --db-snapshot-identifier shop-db-enc --db-subnet-group-name private-db-subnets \
  --vpc-security-group-ids sg-0db1234567890abcd --no-publicly-accessible

# 3. Share the encrypted snapshot (works only with a customer managed key)
aws rds modify-db-snapshot-attribute --db-snapshot-identifier shop-db-enc \
  --attribute-name restore --values-to-add 444455556666

# 4. Require TLS (PostgreSQL) and use the default CA
aws rds modify-db-parameter-group --db-parameter-group-name pg16-secure \
  --parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=immediate"
aws rds modify-db-instance --db-instance-identifier shop-db-encrypted \
  --ca-certificate-identifier rds-ca-rsa2048-g1 --apply-immediately

# 5. Managed master password in Secrets Manager, and IAM authentication on
aws rds modify-db-instance --db-instance-identifier shop-db-encrypted \
  --manage-master-user-password --enable-iam-database-authentication --apply-immediately

# 6. Log in with an IAM token over TLS (token valid 15 minutes)
curl -sO https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem
TOKEN=$(aws rds generate-db-auth-token --hostname shop-db-encrypted.abcdefgh1234.us-east-1.rds.amazonaws.com \
  --port 5432 --username app_user --region us-east-1)
PGPASSWORD="$TOKEN" psql "host=shop-db-encrypted.abcdefgh1234.us-east-1.rds.amazonaws.com port=5432 \
  dbname=shop user=app_user sslmode=verify-full sslrootcert=global-bundle.pem"

# 7. Publish logs to CloudWatch Logs and keep them for 7 years
aws rds modify-db-instance --db-instance-identifier shop-db-encrypted \
  --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql"]}' --apply-immediately
aws logs put-retention-policy \
  --log-group-name /aws/rds/instance/shop-db-encrypted/postgresql --retention-in-days 2557

# 8. RDS Proxy with IAM required and the secret from Secrets Manager
aws rds create-db-proxy --db-proxy-name shop-proxy --engine-family POSTGRESQL \
  --auth '[{"AuthScheme":"SECRETS","SecretArn":"arn:aws:secretsmanager:us-east-1:111122223333:secret:shop-app-AbCdEf","IAMAuth":"REQUIRED"}]' \
  --role-arn arn:aws:iam::111122223333:role/rds-proxy-secrets \
  --vpc-subnet-ids subnet-0aaa1111 subnet-0bbb2222 --vpc-security-group-ids sg-0proxy12345678 \
  --require-tls
aws rds register-db-proxy-targets --db-proxy-name shop-proxy \
  --db-instance-identifiers shop-db-encrypted
aws rds describe-db-proxies --db-proxy-name shop-proxy --query "DBProxies[0].Endpoint"

-- PostgreSQL: who is connected, and is each session encrypted?
SELECT a.usename, a.client_addr, s.ssl, s.version
FROM pg_stat_activity a JOIN pg_stat_ssl s USING (pid)
WHERE a.backend_type = 'client backend';

-- How close are we to the limit?
SHOW max_connections;
SELECT count(*) FROM pg_stat_activity;

-- An application user for IAM authentication
CREATE USER app_user;
GRANT rds_iam TO app_user;

#সারসংক্ষেপ

মূল কথাগুলো

• Encryption at rest চলে KMS (AES-256) দিয়ে, আর ঢাকে storage, log, automated backup, snapshot আর read replica। বাছতে হয় বানানোর সময়; পরে বন্ধ করা যায় না, key-ও জায়গায় বসে বদলানো যায় না।
• Unencrypted database encrypt করা: snapshot → encryption দিয়ে copy → restore → switch (Blue/Green আর Aurora-র key দিয়ে restore নতুন শর্টকাট)।
• Replica primary-র encryption মানে; cross-Region replica আর copy-তে লাগে গন্তব্য Region-এর key। aws/rds দিয়ে encrypt করা snapshot share করা যায় না: customer managed key আর তার key policy নাও। Key disable হলে database থেমে যায় (ফেরানোর জন্য ৭ দিন)।
• TDE হলো Oracle আর SQL Server-এর engine-level encryption।
• In flight: RDS CA দিয়ে TLS (default rds-ca-rsa2048-g1; rds-ca-2019-এর মেয়াদ গেছে ২০২৪-এ)। বাধ্যতামূলক করো parameter group-এ rds.force_ssl=1 (PostgreSQL, SQL Server) বা require_secure_transport=ON (MySQL/MariaDB) দিয়ে; MySQL-এর REQUIRE SSL শুধু একজন user-এর জন্য।
• IAM database authentication: MySQL, MariaDB, PostgreSQL; ১৫ মিনিটের token, দেখা হয় login-এর সময়, TLS বাধ্যতামূলক, জমা password নেই। Secrets Manager password rotate করে (managed master password, ৭ দিন)। SQL Server, Oracle আর অন্যদের জন্য Managed Microsoft AD সহ Kerberos।
• Network: private subnet, দুই AZ-এর DB subnet group, Publicly accessible = No, database-এর security group port খোলে app tier-এর security group থেকে।
• SSH নেই, শুধু RDS Custom-এ আছে; নইলে EC2।
• Audit: engine-এর audit log → CloudWatch Logs (retention, alarm); কেউ বদলাতে পারবে না এমন audit-এর জন্য Database Activity Streams → Kinesis; CloudTrail API call-এর জন্য, SQL-এর জন্য না।
• RDS Proxy: managed, serverless, Multi-AZ connection pool, শুধু VPC; MySQL, PostgreSQL, MariaDB, SQL Server আর Aurora। Lambda-র “too many connections” সারায়, failover-এর সময় সর্বোচ্চ ৬৬% কমায়, Secrets Manager-এ credential রেখে IAM auth বাধ্যতামূলক করে। Pinning-এ চোখ রাখো; দাম vCPU বা ACU ধরে।

নিজেকে যাচাই করো: database security আর RDS Proxy৩০টি প্রশ্ন