11 C
Canberra
Monday, April 13, 2026

Proactive monitoring for Amazon Redshift Serverless utilizing AWS Lambda and Slack alerts


Efficiency points in analytics environments usually stay invisible till they disrupt dashboards, delay ETL jobs, or affect enterprise selections. For groups working Amazon Redshift Serverless, unmonitored question queues, long-running queries, or surprising spikes in compute capability can degrade efficiency and improve prices if left undetected.

Amazon Redshift Serverless streamlines working analytics at scale by eradicating the necessity to provision or handle infrastructure. Nonetheless, even in a serverless setting, sustaining visibility into efficiency and utilization is important for environment friendly operation and predictable prices. Whereas Amazon Redshift Serverless supplies superior built-in dashboards for monitoring efficiency metrics, delivering notifications on to platforms like Slack, brings one other degree of agility. Actual-time alerts within the group’s workflow allow quicker response instances and extra knowledgeable decision-making with out requiring fixed dashboard monitoring.

On this publish, we present you methods to construct a serverless, low-cost monitoring answer for Amazon Redshift Serverless that proactively detects efficiency anomalies and sends actionable alerts on to your chosen Slack channels. This strategy helps your analytics group establish and handle points early, usually earlier than your customers discover an issue.

The answer offered on this publish makes use of AWS providers to gather key efficiency metrics from Amazon Redshift Serverless, consider them towards thresholds that you could flexibly configure, and notify you when anomalies are detected.

scope of solution

The workflow operates as follows:

  1. Scheduled execution – An Amazon EventBridge rule triggers an AWS Lambda operate on a configurable schedule (by default, each quarter-hour throughout enterprise hours).
  2. Metric assortment – The AWS Lambda operate gathers metrics together with queued queries, working queries, compute capability (RPUs), knowledge storage utilization, desk depend, database connections, and slow-running queries utilizing Amazon CloudWatch and the Amazon Redshift Knowledge API.
  3. Threshold analysis – Collected metrics are in contrast towards your predefined thresholds that mirror acceptable efficiency and utilization limits.
  4. Alerting – When a threshold is exceeded, the Lambda operate publishes a notification to an Amazon SNS matter.
  5. Slack notification – Amazon Q Developer in Chat purposes (previously AWS Chatbot) delivers the alert to your designated Slack channel.
  6. Observability – Lambda execution logs are saved in Amazon CloudWatch Logs for troubleshooting and auditing.

This structure is totally serverless and requires no modifications to your current Amazon Redshift Serverless workloads. To simplify deployment, we offer an AWS CloudFormation template that provisions all required sources.

Conditions

Earlier than deploying this answer, it’s essential to gather details about your current Amazon Redshift Serverless workgroup and namespace that you just wish to monitor. To establish your Amazon Redshift Serverless sources:

  1. Open the Amazon Redshift console.
  2. Within the navigation pane, select Serverless dashboard.
  3. Word down your workgroup and namespace names. You’ll use these values when launching this weblog’s AWS CloudFormation template.

Deploy the answer

You’ll be able to launch the CloudFormation stack and deploy the answer by way of the supplied hyperlink.

GitHub Repo

When launching the CloudFormation stack, full the next steps within the AWS CloudFormation Console:

  1. For Stack title, enter a descriptive title reminiscent of redshift-serverless-monitoring.
  2. Assessment and modify the parameters as wanted on your setting.
  3. Acknowledge that AWS CloudFormation could create IAM sources with customized names.
  4. Select Submit.

CloudFormation parameters

Amazon Redshift Serverless Workgroup configuration

Present particulars on your current Amazon Redshift Serverless setting. These values join the monitoring answer to your Redshift setting. Some parameters include the default values that you could substitute together with your precise configuration.

Parameter Default worth Description
Amazon Redshift Workgroup Identify Your Amazon Redshift Serverless workgroup title.
Amazon Redshift Namespace Identify Your Amazon Redshift Serverless namespace title.
Amazon Redshift Workgroup ID Workgroup ID (UUID) of the Amazon Redshift Serverless workgroup to observe. Should observe the UUID format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (lowercase hexadecimal with hyphens).
Namespace ID (UUID) of the Amazon Redshift Serverless namespace. Should observe the UUID format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (lowercase hexadecimal with hyphens).
Database Identify dev Goal Amazon Redshift database for SQL-based diagnostic and monitoring queries.

Monitoring schedule

The default schedule runs diagnostic SQL queries each quarter-hour throughout enterprise hours, balancing responsiveness and value effectivity. Operating extra steadily may improve prices, whereas much less frequent monitoring may delay detection of efficiency points. You’ll be able to regulate this schedule to your precise want.

Parameter Default worth Description
Schedule Expression cron(0/15 8-17 ? * MON-FRI *) EventBridge schedule expression for Lambda operate execution. Default runs each quarter-hour, Monday by Friday, 8 AM to five PM UTC.

Threshold configuration

Thresholds ought to be tuned primarily based in your workload traits.

Parameter Default worth Description
Queries Queued Threshold 20 Alerts threshold for queued queries.
Queries Operating Threshold 20 Alerts threshold for working queries.
Compute Capability Threshold (RPUs) 64 Alert threshold for compute capability (RPUs).
Knowledge Storage Threshold (MB) 5242880 Threshold for knowledge storage in MB (default 5 TB).
Desk Depend Threshold (MB) 1000 Alerts threshold for complete desk depend.
Database Connections Threshold 50 Alert threshold for database connections.
Gradual Question Threshold (seconds) 10 Thresholds in seconds for sluggish question detection.
Question Timeout (Seconds) 30 Timeout for SQL diagnostics queries.

Tip: Begin with conservative thresholds and refine them after observing baseline habits for one to 2 weeks.

Lambda configuration

Configure the AWS Lambda operate settings. The chosen default values are applicable for many monitoring situations. It’s possible you’ll wish to change them solely in case of troubleshooting.

Parameter Default worth Description
Lambda Reminiscence Measurement (MB) 256 Lambda operate reminiscence dimension in MB.
Lambda Time Out (Seconds) 240 Lambda operate timeout in seconds.

Safety Configuration – Amazon Digital Personal Cloud (VPC)

In case your group has community isolation necessities, you’ll be able to optionally allow VPC deployment for the Lambda operate. When enabled, the Lambda operate runs inside your specified VPC subnets, offering community isolation and permitting entry to VPC-only sources.

Parameter Default worth Description
VPC ID VPC ID for Lambda deployment (required if EnableVPC is true). The Lambda operate shall be deployed on this VPC. Be certain that the VPC has applicable routing (NAT Gateway or VPC Endpoints) to permit Lambda to entry AWS providers like CloudWatch, Amazon Redshift, and Amazon SNS.
VPC Subnet IDs Comma-separated record of subnet IDs for Lambda deployment (required if EnableVPC is true).
Safety Group IDs Comma-separated record of safety group IDs for Lambda (elective). If not supplied and EnableVPC is true, a default safety group shall be created with outbound HTTPS entry. Customized safety teams should enable outbound HTTPS (port 443) to AWS service endpoints.

Word that VPC deployment may improve chilly begin instances and requires an NAT Gateway or VPC endpoints for AWS service entry. We advocate provisioning interface VPC endpoints (by AWS PrivateLink) for the 5 providers the Lambda operate calls which retains all site visitors personal with out the recurring price of a NAT Gateway.

Safety configuration – Encryption

In case your group requires encryption of knowledge at relaxation, you’ll be able to optionally allow AWS Key Administration Service (AWS KMS) encryption for the Lambda operate’s setting variables, CloudWatch Logs, and SNS matter. When enabled, the template encrypts every useful resource utilizing the AWS KMS keys that you just present, both a single shared key for all three providers, or particular person keys for granular key administration and audit separation.

Parameter Default worth Description
Shared KMS Key ARN AWS KMS key ARN to make use of for all encryption (Lambda, Logs, and SNS) except service-specific keys are supplied. This streamlines key administration through the use of a single key for all providers. The important thing coverage should grant encrypt/decrypt permissions to Lambda, CloudWatch Logs, and SNS.
Lambda KMS Key ARN AWS KMS key ARN for Lambda setting variable encryption (elective, overrides SharedKMSKeyArn). Use this for separate key administration per service. The important thing coverage should grant decrypt permissions to the Lambda execution position. If not supplied, SharedKMSKeyArn shall be used when EnableKMSEncryption is true.
CloudWatch Logs KMS Key ARN AWS KMS key ARN for CloudWatch Logs encryption (elective, overrides SharedKMSKeyArn). Use this for separate key administration per service. The important thing coverage should grant encrypt/decrypt permissions to the CloudWatch Logs service. If not supplied, SharedKMSKeyArn shall be used when EnableKMSEncryption is true.
SNS Matter KMS Key ARN AWS KMS key ARN for SNS matter encryption (elective, overrides SharedKMSKeyArn). Use this for separate key administration per service. The important thing coverage should grant encrypt/decrypt permissions to SNS service and the Lambda execution position. If not supplied, SharedKMSKeyArn shall be used when EnableKMSEncryption is true.
Allow Lifeless Letter Queue False Optionally allow Lifeless Letter Queue (DLQ) for failed Lambda invocations to enhance reliability and safety monitoring. When enabled, occasions that fail in any case retry makes an attempt shall be despatched to an SQS queue for investigation and potential replay. This helps forestall knowledge loss, supplies visibility into failures, and allows safety audit trails for monitoring anomalies. The DLQ retains messages for 14 days.

Word that AWS KMS encryption requires the important thing coverage to grant applicable permissions to every consuming service (Lambda, CloudWatch Logs, and SNS).

  1. On the evaluate web page, choose I acknowledge that AWS CloudFormation may create IAM sources with customized names.
  2. Select Submit.

Assets created

The CloudFormation stack creates the next sources:

  • EventBridge rule for scheduled execution
  • AWS Lambda operate (Python 3.12 runtime)
  • Amazon SNS matter for alerts
  • IAM position with permissions for CloudWatch, Amazon Redshift Knowledge API, and SNS
  • CloudWatch Log Group for Lambda logs

Word: CloudFormation deployment usually takes 10–quarter-hour to finish. You’ll be able to monitor progress in actual time below the Occasions tab of your CloudFormation stack.

Put up-deployment configuration

After the CloudFormation stack has been efficiently created, full the next steps.

Step 1: File CloudFormation outputs

  1. Navigate to the AWS CloudFormation console.
  2. Choose your stack and select the Outputs tab.
  3. Word the values for LambdaRoleArn and SNSTopicArn. You will have these in subsequent steps.

Step 2: Grant Amazon Redshift permissions

Grant permissions to the Lambda operate to question Amazon Redshift system tables for monitoring knowledge. Full the next steps to grant the required entry:

  1. Navigate to the Amazon Redshift console.
  2. Within the left navigation pane, select Question Editor V2.
  3. Hook up with your Amazon Redshift Serverless workgroup.
  4. Execute the next SQL instructions, changing with the LambdaRoleArn worth out of your CloudFormation outputs:
CREATE USER "IAMR:" WITH PASSWORD DISABLE;

GRANT ROLE "sys:monitor" TO "IAMR:";

RedshiftSQL-DBD-5612

These instructions create an AmazonRedshift person related to the Lambda IAM position and grant it the sys:monitor Amazon Redshift position. This position supplies read-only entry to catalog and system tables with out granting permissions to person knowledge tables.

Step 3: Configure Slack notifications

Amazon Q Developer in chat purposes supplies native AWS integration and managed authentication, eradicating customized webhook code and decreasing setup complexity. To obtain alerts in Slack, configure Amazon Q Developer in Chat Purposes to attach your SNS matter to your most popular Slack channel:

  1. Navigate to Amazon Q Developer in chat purposes (previously AWS Chatbot) within the AWS console.
  2. Observe the directions within the Slack integration documentation to authorize AWS entry to your Slack workspace.
  3. When configuring the Slack channel, be certain that you choose the proper AWS Area the place you deployed the CloudFormation stack.
  4. Within the Notifications part, choose the SNS matter created by your CloudFormation stack (consult with the SNSTopicArn output worth).
  5. Preserve the default IAM read-only permissions for the channel configuration.

SNS topic

After configured, alerts robotically seem in Slack at any time when thresholds are exceeded.

result-upon-success

Price issues

With the default configuration, this answer incurs minimal ongoing prices. The Lambda operate executes roughly 693 instances monthly (each quarter-hour throughout an 8-hour enterprise day, Monday by Friday), leading to a month-to-month price of roughly $0.33 USD. This contains Lambda compute prices ($0.26) and CloudWatch GetMetricData API calls ($0.07). All different providers (EventBridge, SNS, CloudWatch Logs, and Amazon Redshift Knowledge API). The Amazon Redshift Knowledge API has no further costs past the minimal Amazon Redshift Serverless RPU consumption for the Amazon Redshift Serverless system desk question execution. You’ll be able to scale back prices by lowering the monitoring frequency (reminiscent of, each half-hour) or improve responsiveness by working extra steadily (reminiscent of, each 5 minutes) with a proportional price improve.

All prices are estimates and will fluctuate primarily based in your setting. Variations usually happen as a result of queries scanning system tables could take longer or require further sources relying on the system complexity

Safety greatest practices

This answer implements the next safety controls:

  • IAM insurance policies scoped to particular useful resource ARNs for the Amazon Redshift workgroup, namespace, SNS matter, and log group.
  • Knowledge API assertion entry restricted to the Lambda operate’s personal IAM person ID.
  • Learn-only sys:monitor database position for operational metadata entry. Restrict to the position created by the CloudFormation template.
  • Reserved concurrent executions capped at 5.

To additional strengthen your safety posture, contemplate the next enhancements:

  • Allow EnableKMSEncryption to encrypt setting variables, logs, and SNS messages at relaxation.
  • Allow EnableVPC to deploy the operate inside a VPC for community isolation.
  • Audit entry by AWS CloudTrail.

Necessary: That is pattern code for non-production utilization. Work together with your safety and authorized groups to fulfill your organizational safety, regulatory, and compliance necessities earlier than deployment. This answer demonstrates monitoring capabilities however requires further safety hardening for manufacturing environments, together with encryption configuration, IAM coverage scoping, VPC deployment, and complete testing.

Clear up

To take away all sources and keep away from ongoing costs in the event you don’t wish to use the answer anymore:

  1. Delete the CloudFormation stack.
  2. Take away the Slack integration from Amazon Q Developer in chat purposes.

Troubleshooting

  • If no metrics or incomplete SQL diagnostics are returned, confirm that the Amazon Redshift Serverless workgroup is lively with current question exercise, and make sure the database person has the sys:monitor position (GRANT ROLE sys:monitor TO ) within the question editor. With out this position, queries execute efficiently however solely return knowledge seen to that person’s permissions somewhat than the complete cluster exercise.
  • For VPC-deployed features that fail to achieve AWS providers, verify that VPC endpoints or a NAT Gateway are configured for CloudWatch, Amazon Redshift Knowledge API, Amazon Redshift Serverless, SNS, and CloudWatch Logs.
  • If the Lambda operate instances out, improve the LambdaTimeout and QueryTimeoutSeconds parameters. The default timeout of 240 seconds accommodates most workloads, however clusters with many lively queries could require further time for SQL diagnostics to finish.

Conclusion

On this publish, we confirmed how one can construct a proactive monitoring answer for Amazon Redshift Serverless utilizing AWS Lambda, Amazon CloudWatch, and Amazon SNS with Slack integration. By robotically accumulating metrics, evaluating thresholds, and delivering alerts in close to actual time to Slack or your most popular collaborative platform, this answer helps detect efficiency and value points early. As a result of the answer itself is serverless, it aligns with the operational simplicity targets of Amazon Redshift Serverless—scaling robotically, requiring minimal upkeep, and delivering excessive worth at low price. You’ll be able to prolong this basis with further metrics, diagnostic logic, or different notification channels to fulfill your group’s wants.

To be taught extra, see the Amazon Redshift documentation on monitoring and efficiency optimization.


In regards to the authors

Headhost author 1

Cristian Restrepo Lopez

Cristian is a Options Architect at AWS, serving to prospects construct fashionable knowledge purposes with a concentrate on analytics. Outdoors of labor, he enjoys exploring rising applied sciences and connecting with the info group.

Satesh Sonti

Satesh is a Principal Analytics Specialist Options Architect primarily based out of Atlanta, specializing in constructing enterprise knowledge platforms, knowledge warehousing, and analytics options. He has over 19 years of expertise in constructing knowledge property and main advanced knowledge platform packages for banking and insurance coverage purchasers throughout the globe.

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

[td_block_social_counter facebook="tagdiv" twitter="tagdivofficial" youtube="tagdiv" style="style8 td-social-boxed td-social-font-icons" tdc_css="eyJhbGwiOnsibWFyZ2luLWJvdHRvbSI6IjM4IiwiZGlzcGxheSI6IiJ9LCJwb3J0cmFpdCI6eyJtYXJnaW4tYm90dG9tIjoiMzAiLCJkaXNwbGF5IjoiIn0sInBvcnRyYWl0X21heF93aWR0aCI6MTAxOCwicG9ydHJhaXRfbWluX3dpZHRoIjo3Njh9" custom_title="Stay Connected" block_template_id="td_block_template_8" f_header_font_family="712" f_header_font_transform="uppercase" f_header_font_weight="500" f_header_font_size="17" border_color="#dd3333"]
- Advertisement -spot_img

Latest Articles