Reputation: 118
The Firehose docs clearly state:
If your Amazon Redshift cluster is in a virtual private cloud (VPC), it must be publicly accessible with a public IP address.
It goes on to provide a CIDR range so you can allow it through a Security Group. The RedShift docs go on to explain you need to have routes to 0.0.0.0 and an internet gateway to bring a cluster up with the publicly accessible setting enabled.
However, putting a database or data warehouse in a public subnet is widely regarded as bad practice. In fact, if you do this AWS Security Hub will throw a critical finding:
aws-foundational-security-best-practices/v/1.0.0/Redshift.1
Redshift.1 Amazon Redshift clusters should prohibit public access
Suggested remediation:
- Choose Actions, then choose Modify publicly accessible setting.
- Under Allow instances and devices outside the VPC to connect to your database through the cluster endpoint, choose No.
Given the requirements of Kinesis Firehose and AWS's own security best practices are in conflict, what is the best way to allow Kinesis to do its job without putting the whole cluster on the edge?
Upvotes: 1
Views: 525
Reputation: 1398
As mentioned in the doc here and here, you cannot ingest data directly from firehose to private redshift. One thing I can think of is to have Firehose target S3. Then setup a private link access to S3 from the private VPC and setup an event to copy the data into the Redshift cluster on an acceptable cadence. That would definitely add a bit of latency.
Upvotes: 0