Redshift production | Data For Dummies

Picture it this way

Production is the lock, the spare key, and the window. The lock is encryption, network, and who may see which rows. The spare key is a snapshot you have restored once. The window is the history of queries, so you hear trouble before a user does.

Security you can explain

Encrypt the warehouse. Keep it in a private subnet unless you have a reason you can write down. Use IAM roles for COPY and Spectrum. Use security groups that name the clients. Turn on audit logging to S3 or CloudWatch when the data is sensitive enough that you will be asked who ran a query.

Row-level security and dynamic data masking are how you keep one table and still hide rows or columns from a group. They are not a substitute for a separate account when two companies must not share a failure domain. Test with a user who must see nothing. An admin query is not that test.

Control	Stops	Does not stop
Private VPC	Casual internet connections	A bad query from an allowed host
IAM role	Keys pasted into SQL	A role that is allowed to read too much
Row-level security	Rows outside the policy	A share you granted by mistake
Masking	A sensitive column for a group	A person who is allowed to see it

Snapshots, patches, and signals

Automated snapshots are the spare key for provisioned clusters. Know the retention and whether a cross-region copy exists. Serverless recovery uses the namespace's recovery points. Either way, restore once into a scratch warehouse and run a count. A snapshot you have never opened is a rumor.

Maintenance windows patch the engine. Read the current maintenance notes before you schedule a load through that window. For signals, keep a short dashboard on SYS_QUERY_HISTORY: failed queries, queue time, and the longest scans. CloudWatch covers cluster health such as CPU and disk on the shapes that publish those metrics. Alert on queue time and failed loads, not only on CPU.

SELECT COUNT(*) AS failed_queries
FROM sys_query_history
WHERE status = 'failed'
  AND start_time > DATEADD(hour, -24, GETDATE());

Data sharing is not a backup

A consumer can see current tables. It does not give you yesterday after someone deletes the producer. Snapshots do that.

Lock, spare key, window

Limit access, keep restorable snapshots, and watch the right signals.

AccessRoles and least privilege
SnapshotsYour spare key
SignalsAlarms and maintenance window

Step 1 of 3Give each team a role with only what it needs, and keep the cluster encrypted and off the public internet.

CREATE ROLE analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ROLE analyst;

Leave a runbook

Write who can pause the warehouse, where snapshots go, and which query shows the last failed COPY. The split lessons on this hub are the course. The long single-page notes are the older copy of the same subject.

Knowledge check

What proves a snapshot works?

Who should you use to test row-level security?

Which signal catches a bad night of loads?

Official sources

Checked against vendor documentation in October 2026. Screens and plan names still change, so confirm the control in your own instance.