Skip to main content
This guide covers security controls and best practices for Amazon Redshift (provisioned and serverless), Amazon DynamoDB, and DynamoDB Accelerator (DAX). It focuses on authentication/authorization, network isolation, encryption, logging/auditing, and approaches for tokenization and real-time processing. It does not address capacity or performance differences between Redshift modes. Amazon Redshift overview
  • Redshift is a managed data warehouse with tight S3 integration (Parquet/ORC/JSON), support for JDBC/ODBC and the Data API, and integrations with services such as SageMaker for ML workflows.
  • Two operational modes: provisioned (cluster-based with leader + compute nodes) and serverless. Security controls are consistent across both modes: network isolation (VPC, subnets, security groups), IAM for control plane/API access, encryption for data at rest and in transit, and audit logging.
A diagram showing Amazon Redshift's two modes—Serverless and Provisioned—illustrating a cloud-based serverless data warehouse alongside a cluster with a leader node and compute nodes. It also shows storage integration with Amazon S3 (Parquet/ORC/JSON), plus connections to operational databases, SageMaker, and client tools via JDBC/ODBC and the Data API.
Redshift cluster architecture (provisioned)
  • Provisioned Redshift uses a leader node (query coordination, planning) and one or more compute nodes (query execution). A single-node option exists for development/testing, but production deployments commonly separate leader and compute nodes.
  • Serverless Redshift abstracts compute provisioning and scaling; however, network, identity, encryption, and audit controls behave the same.
Question: Which statement best describes the primary cluster node type in Redshift?
  • Correct answer: the cluster is divided into a leader node and compute nodes, where the leader node manages query coordination and execution on compute nodes.
Authentication and database users
  • Redshift supports IAM-based authentication. When enabled, IAM can provide temporary database credentials (for example, via GetClusterCredentials) so users authenticate without managing long-lived DB passwords.
  • IAM authentication does not replace database-level access controls: you still must create database users and assign privileges (GRANTs) inside Redshift. IAM provides the authentication mechanism and can map identities to database users/groups.
  • If you use AWS Identity Center (formerly AWS SSO) or a SAML provider, map SAML attributes/groups to Redshift users and groups so that federated identities receive appropriate database permissions.
A diagram titled "Redshift and Redshift Serverless" showing how AWS Single Sign-On uses SAML attribute mapping to create a user identity and directory groups that map to Amazon Redshift database users and groups. It shows users authenticating via a browser SAML plugin and receiving granted access to Redshift.
Clarifying IAM authentication behavior
  • IAM authentication lets users obtain temporary DB credentials and maps identities to DB users/groups, but it does not implicitly grant schema/table privileges — those are enforced by database GRANTs.
  • Console credentials vs. DB credentials: a user’s AWS console credentials are distinct from database credentials; successful DB login depends on how authentication and mapping are configured.
Network controls for Redshift
  • Place clusters in a VPC and use security groups (stateful) to restrict inbound/outbound access. Clusters may be associated with multiple security groups.
  • Use Network ACLs (NACLs) at the subnet level as an additional stateless layer when required by your network design.
  • For cross-account access or data loading, use IAM roles and AssumeRole patterns rather than opening broad network access.
A three-panel AWS architecture diagram showing Amazon Redshift clusters in a Source and Target account and an EC2 instance in a DataLoading account, with security groups blocking port 5439 and arrows for cross-account roles/assume-role access. The caption notes that Redshift supports security groups.
VPC endpoints (PrivateLink / interface endpoints)
  • Use VPC interface endpoints (AWS PrivateLink) for Redshift control-plane APIs and Data API traffic to keep traffic on the AWS network and avoid public IPs.
  • Gateway endpoints are used for S3; use the appropriate endpoint type for each service. Interface endpoints are the right choice for Redshift and many other AWS-managed APIs.
  • Interface endpoints help ensure management and data-plane traffic remains private and auditable.
A slide titled "Redshift and Redshift Serverless" showing an AWS VPC diagram with a public subnet containing Amazon Redshift-managed VPC endpoints and a private subnet containing an Amazon Redshift cluster. Arrows and IP ranges illustrate connectivity between the endpoints and the cluster, with a note that Redshift supports VPC endpoints.
Logging, auditing, and detection
  • Enable Redshift audit logging (user activity, connection attempts, SQL operations) and publish logs to Amazon CloudWatch Logs and/or an S3 bucket. Use CloudTrail to capture management-plane API calls.
  • For compliance and retention, configure appropriate retention policies, lifecycle rules (S3), and alarms (CloudWatch) to detect suspicious activity or unexpected usage trends.
  • Note: Redshift Spectrum is for querying external S3 data and is unrelated to audit logging.
An informational slide asking how a financial institution can send and retain Amazon Redshift logs in Amazon CloudWatch Logs to meet compliance. It shows four numbered options (enable Redshift audit logging to CloudWatch, use Redshift Spectrum, use AWS Lambda to pull logs, or export logs to S3 and monitor with CloudWatch).
Encryption and tokenization
  • Data at rest: use AWS KMS customer-managed keys (CMKs) for Redshift encryption; where required, choose KMS keys backed by CloudHSM for hardware-backed protection. You can also use AWS-managed keys, but CMKs give you control over rotation and access.
  • Data in transit: enforce TLS/SSL for client connections and use secure control-plane access (PrivateLink) to keep management traffic private.
  • Best practice: enable KMS-backed encryption early (at cluster creation) rather than implementing ad-hoc application-level encryption—unless compliance mandates custom approaches.
  • Redshift does not provide native tokenization. For field-level tokenization (e.g., patient identifiers), integrate a vetted third-party tokenization service at ETL time or via UDFs/external calls. Tokenization should be auditable and integrated into your data lifecycle.
A presentation slide titled "Redshift and Redshift Serverless" showing screenshots of account configuration dialogs for AWS KMS encryption and encryption options (Default Redshift key, use current account key, HSM, etc.). The slide notes encryption choices for data-at-rest with buttons to save/configure the account.
An infographic-style multiple-choice question about migrating a financial institution's data warehouse to Amazon Redshift and ensuring data is encrypted at rest and in transit. Four numbered answer options are shown (e.g., enable Redshift encryption and SSL, use AWS KMS, rely on S3 server-side encryption, or disable encryption).
Tokenization integration example
  • For sensitive domains (healthcare, payments), perform tokenization either:
    • Before loading (ETL-time tokenization), so no PII plaintext lands in Redshift; or
    • At query time by calling a secure tokenization/de-tokenization service that applies strict access controls.
  • Ensure tokenization services are covered by audit logs, key management controls, and least-privilege network access.
A diagram titled "Redshift and Redshift Serverless" showing an architecture for tokenization and data-in-transit encryption using AWS services (IAM, KMS, Lambda, Amazon Redshift) and a customer-managed network with a directory and Protegrity. It also depicts two users (Alice and Bob) and indicates that Alice is authorized to see plaintext while Bob is not.
An infographic presenting a healthcare scenario asking how to implement tokenization with Amazon Redshift. It lists four numbered options — use built‑in tokenization, integrate a third‑party tokenization tool, rely on Redshift encryption, or use AWS Lambda for real‑time tokenization.
Designing for NoSQL: Amazon DynamoDB Overview
  • DynamoDB is a fully managed NoSQL database (key-value and document) with minimal operational overhead. It integrates tightly with AWS services and provides encryption, fine-grained IAM control, and streaming for real-time processing.
Why choose DynamoDB?
  • No server/OS patching or node management.
  • Built-in point-in-time recovery (PITR) and on-demand backups.
  • Flexible capacity models: provisioned with auto-scaling or on-demand mode.
Access control
  • DynamoDB uses AWS IAM for both authentication and authorization—there are no native database users. Grant access via IAM users, groups, and roles with policies that scope actions to specific tables and operations.
  • Use IAM policy conditions (for example, aws:SourceVpc) to restrict access to requests originating from a particular VPC/subnet or VPC endpoint.
A network diagram showing Amazon DynamoDB accessed from an app tier inside a VPC via a VPC endpoint, with EC2 instances (App1 and App2) and security groups. It highlights that access to DynamoDB tables and rows is controlled using IAM policies.
Example IAM policy condition
  • Deny requests that do not originate from a specific VPC:
VPC endpoints for DynamoDB
  • DynamoDB has long-supported gateway VPC endpoints; many regions also support interface endpoints. Choose the endpoint type supported in your region and add the endpoint to your route tables (gateway) or create an interface endpoint as applicable.
  • VPC endpoints keep DynamoDB traffic inside the AWS network and avoid public internet egress.
DynamoDB Streams and real-time processing
  • Streams capture item-level changes in time order (before and after images). Common pattern: DynamoDB Streams -> AWS Lambda (or Kinesis) -> downstream processing (fraud detection, caching, analytics).
  • Use CloudWatch metrics and CloudWatch Logs for operational visibility. For higher-level tracing across services, consider AWS X-Ray where needed.
An infographic about Amazon DynamoDB showing a four-step flow: 01 modifies data in a DynamoDB table, 02 DynamoDB Streams captures a time-ordered sequence, 03 a stream record contains info about the modification, and 04 develop a Lambda function to handle stream events. Icons and short captions illustrate each step.
Monitoring and encryption
  • Monitor capacity, throttling, latency, and errors via CloudWatch metrics. CloudTrail records management API calls.
  • DynamoDB encrypts data at rest using AWS KMS and protects in-transit traffic with TLS. Use IAM policies to restrict access to tables and operations.
A DynamoDB diagram showing encryption-at-rest: AWS KMS with a customer master key generates table/data keys which are used to encrypt data encryption keys and the table. The slide notes DynamoDB already encrypts data locally at rest and uses TLS 1.2 for client-side signing in transit.
DynamoDB Accelerator (DAX) Overview
  • DAX is an in-memory cache for DynamoDB that provides microsecond reads for cached items and reduces read pressure on your tables.
  • It is a managed cluster with its own access and security model; applications use a DAX client to communicate with the DAX cluster.
Architecture and security considerations
  • DAX clusters require careful IAM and network configuration. Ensure the DAX cluster role has least privilege to DynamoDB and that the application’s role trusts only the necessary resources.
  • DAX is typically deployed inside your VPC and should be secured with security groups and subnet design consistent with your network policies.
A simple architecture diagram of Amazon DynamoDB Accelerator (DAX) showing an EC2 instance with your application and a DAX client connecting to a DAX cache cluster, which in turn connects to Amazon DynamoDB inside a VPC. The caption notes DAX acts as a frontend index/cache/proxy for DynamoDB.
IAM integration with DAX
  • DAX supports IAM for management and API actions. Apply least-privilege policies to both the DAX cluster role and the application role. Avoid granting broad DynamoDB permissions to DAX unless required.
  • Use CloudWatch metrics and logs for cluster health; X-Ray can surface traces that include DAX interactions but CloudWatch is the primary monitoring tool.
An infographic showing a quiz question about a retail company integrating Amazon DynamoDB Accelerator (DAX) and asking which statement correctly describes IAM integration with DAX. Four numbered answer options are displayed, summarizing different IAM access-control possibilities for DAX (fine‑grained policies, no IAM support, IAM grants/denies, or a separate authentication system).
Monitoring and logging for DAX
  • Use CloudWatch for cluster metrics and CloudWatch Logs for diagnostic logs. Set alarms for node health, CPU/memory, latency, and cache hit rate.
  • Tracing can be added via X-Ray where cross-service tracing is required.
Encryption in DAX
  • DAX supports encryption in transit (TLS) and encryption at rest (KMS). Note: encryption at rest must be enabled during cluster creation and cannot be toggled afterward.
  • Performance impact is generally minimal—enable encryption by default unless you have an explicit reason not to.
A screenshot of the DynamoDB Accelerator (DAX) Encryption settings showing checkboxes enabled for "Enable encryption at rest" and "Enable encryption in transit." The notes mention these protections come at no additional cost and cannot be changed after the cluster is created.
An infographic asking how a global e-commerce platform can ensure encryption for Amazon DAX clusters, with four numbered options. The options include enabling server-side encryption on the DynamoDB table, using AWS KMS to apply a custom key to DAX, relying on DAX's default encryption and SSL/TLS, or manually encrypting data before storing it.
Comparison summary Practical hardening checklist
  • Network: deploy clusters/caches in private subnets, restrict inbound access with security groups, and prefer VPC interface endpoints (PrivateLink) for control-plane/API access.
  • Authentication/Authorization:
    • Redshift: use IAM- or SAML-based authentication mapped to DB users and apply database GRANTs for least privilege.
    • DynamoDB: enforce least-privilege IAM policies with conditions (VPC, source IP, etc.).
  • Logging & detection: enable Redshift audit logging to CloudWatch and/or S3; use CloudTrail for API auditing; create CloudWatch alarms for anomalous metrics.
  • Encryption: enable KMS-managed keys for data at rest and enforce TLS for in-transit protection. For DAX, enable encryption at creation time.
  • Tokenization: integrate vetted third-party tokenization solutions for field-level protection; perform tokenization at ETL or via a secure de-tokenization service rather than relying on built-in DB features.
Enable audit logging and encryption (KMS) as early steps when provisioning Redshift, DynamoDB, or DAX. These settings form the foundation for compliance, monitoring, and secure operations.
References and further reading

Watch Video