Skip to main content
In this lesson we focus on hardening two specialized AWS database services: Amazon QLDB (a centralized ledger database with an append‑only journal and cryptographic verification) and Amazon Timestream (a serverless time-series database optimized for high-ingest, time-ordered telemetry). You’ll learn what makes each service different, recommended security controls, and which observability and encryption features to expect. QLDB (Amazon Quantum Ledger Database) Amazon QLDB is a centralized, cryptographically verifiable ledger that records every change in an append-only journal while exposing a current-state view for application queries. It supports PartiQL for SQL-compatible queries and provides ACID guarantees for transactions that occur within a ledger.
A slide titled "QLDB" with three security design points on the left and a diagram on the right. The diagram shows application data flowing into Amazon Quantum Ledger Database, which stores an append-only journal and current state while providing full change history access and cryptographic verification.
What QLDB is (and is not)
  • QLDB is a centralized ledger service managed by AWS that provides an append-only journal and cryptographic verification primitives.
  • QLDB is not a decentralized blockchain with multiple independent validators. If you require a decentralized network, evaluate Amazon Managed Blockchain.
  • The journal preserves the full history of changes (who, when, what) while allowing updates to the current state; cryptographic digests enable integrity verification of the journal.
QLDB access control and IAM QLDB integrates tightly with AWS Identity and Access Management (IAM). Use policies and roles to grant fine-grained permissions to ledgers and ledger operations. Typical role patterns:
  • qldb-writer — permissions to insert and modify ledger table rows and perform write operations.
  • qldb-reader — permissions to run PartiQL queries and read current-state or historical data.
Best practices:
  • Use least privilege IAM policies scoped to specific ledgers and actions.
  • Prefer IAM roles for EC2, Lambda, or containers rather than long-lived credentials.
  • Audit access with CloudTrail and alert on unusual API activity.
A slide titled "QLDB" showing an AWS architecture diagram where a QLDB user and IAM roles (qldb-writer, qldb-reader) access a ledger named MyExampleLedger. The ledger contains private and public tables and a shell/CLI icon represents the access point.
Network placement and VPC integration QLDB is a regional AWS service accessible through service endpoints. To keep traffic private:
  • Use PrivateLink interface VPC endpoints so traffic between your VPC and QLDB remains off the public internet.
  • Apply security groups to the VPC endpoint (not directly to QLDB); these control network-level access (ingress/egress rules) for clients in your VPC.
Architecture and integration examples: QLDB often appears alongside application tiers (Elastic Beanstalk, Lambda), caches (ElastiCache), and relational databases (RDS) for hybrid workloads — apply standard VPC, firewall, and subnet best practices to these components.
A slide-sized architecture diagram titled "QLDB" showing users connecting to an AWS setup including Elastic Beanstalk, ElastiCache (Memcached), Amazon Quantum Ledger Database (QLDB), and Amazon RDS (PostgreSQL) with arrows for transaction writes and caching. A caption on the left notes that standard VPC, firewall, and security group rules apply.
Encryption, logging, and verification Encryption and integrity features:
  • At-rest: QLDB uses AWS KMS for encryption at rest by default. You can provide a custom KMS key to control key rotation and access.
  • In-transit: TLS protects data transferred between clients and QLDB endpoints.
  • Integrity: QLDB exposes digest and verification APIs that let you cryptographically verify the journal’s integrity.
Observability:
  • CloudWatch for metrics and alarms (throughput, latency, errors).
  • CloudTrail for API logging and auditing.
An infographic asking which statement correctly describes Amazon QLDB’s encryption features for a legal firm’s sensitive case files. It shows four numbered answer options describing different claims about client-side encryption, AWS KMS/key management, encryption at rest, and encryption in transit.
ACID clarification: ACID stands for Atomicity, Consistency, Isolation, and Durability. QLDB provides ACID guarantees for transactions within a ledger, but it is not a direct replacement for a full-featured multi-model RDBMS in every transactional use case.
A presentation slide showing AWS QLDB architecture with a client and web API on the left and a QLDB box on the right containing the PartiQL engine, an immutable journal, and current state. A caption and icons note that QLDB uses Amazon CloudWatch for metrics and CloudTrail for API call tracking.
Timestream (Amazon Timestream) Amazon Timestream is a serverless time-series database optimized for ingesting, storing, and querying large volumes of timestamped data — for example, IoT telemetry, application metrics, and operational logs. It is designed to be cost-efficient for high-ingest, time-ordered workloads with tiered storage and configurable retention.
A slide titled "TimeStream" with the note "TimeStream is built to be immutable around time-captured data." It shows an AWS architecture diagram where IoT devices send time-series data via AWS IoT Greengrass/IoT Core and Amazon Kinesis through AWS Lambda/Kinesis Data Analytics into Amazon Timestream, with outputs to visualization and ML tools like QuickSight, SageMaker, and Grafana.
Important distinction about immutability
  • Timestream optimizes for time-ordered data and enforces retention and tiering policies, but it is not an immutable, append-only ledger like QLDB. Data can be expired or moved between memory and magnetic tiers based on retention rules; it does not provide cryptographic append-only guarantees.
Key characteristics and security controls for Timestream
  • Use cases: high-volume telemetry, real-time metrics, observability pipelines, and lightweight analytics.
  • IAM: Supports fine-grained identity and access control for roles assigned to EC2, Lambda, IoT devices, or other AWS services.
  • Networking: Supports interface VPC endpoints (PrivateLink) so you can keep service traffic private and apply security groups at the endpoint level.
  • Retention & tiering: Configure retention policies and data tiering to balance cost and performance.
An infographic quiz asking which statement about Amazon TimeStream and VPC endpoints is true, framed by a smart-city IoT scenario. Four numbered answer boxes list options about VPC endpoint support, public internet use, Direct Connect, and regional availability.
Encryption and observability Timestream’s defaults and options:
  • At-rest encryption: Uses AWS KMS-managed keys by default; you may specify a customer-managed KMS key to control access and rotation.
  • In-transit encryption: TLS is used to protect data in transit.
  • Observability: Emits metrics to Amazon CloudWatch and records API calls in AWS CloudTrail for auditing and anomaly detection.
A styled slide showing a question about encryption in Amazon TimeStream for a renewable energy company, with four numbered answer options. The second option is highlighted, stating TimeStream supports encryption at rest using AWS KMS and encryption in transit using TLS.
Monitoring write throughput for Timestream Focus telemetry and alerts on the metrics that reflect ingestion volume and backpressure:
  • Prioritize monitoring of write input records / write requests — these indicate ingestion load and help size and tune producers.
  • Use query duration and memory usage for troubleshooting query performance and resource constraints.
  • Active connections is a weaker signal for write volume because persistent connections do not necessarily mean high ingestion throughput.
An infographic asking which Amazon TimeStream metrics a manufacturing company should monitor for incoming data. It lists four priorities: write input records, query duration, memory usage, and active connections.
Feature comparison: QLDB vs Timestream Summary and recommended controls
  • Choose the right specialized datastore: QLDB for tamper-evident ledgers and full history, Timestream for cost-effective, high-throughput time-series workloads.
  • Enforce least-privilege IAM roles and policies, and prefer short-lived credentials or IAM roles for compute resources.
  • Keep traffic private by using interface VPC endpoints (PrivateLink) and apply security groups to endpoints.
  • Use AWS KMS for key management; consider customer-managed keys when you need strict key control and auditability.
  • Monitor both services with CloudWatch metrics and CloudTrail logs; tune alerts for ingestion rates (Timestream) and API/audit anomalies (QLDB).
A slide titled "Summary" with four colorful numbered points summarizing AWS datastore topics. The points mention datastore services, a range from SQL to NoSQL, encryption at rest and in transit, and logging via CloudWatch/CloudTrail.
Links and references Thanks for reading.

Watch Video