Understanding premium tier limitations for cloudquery sync features

CloudQuery Plugins
1

Hello, can someone help me understand the “premium” CloudQuery tier?

I am looking at the AWS source plugin tables and the majority of them have the “premium table” message for sync. I did a count and only 73 tables are non-premium or free.

I work for an x company and they have a custom local CloudQuery setup that is not logging/using your premium tier. Does the premium tier limit the sync feature in this case? I mean, will executing CloudQuery without the ‘login’ actually retrieve/query the tables that are “premium”?

2

We made a change to the AWS, GCP, and Azure plugins that changed which tables were free/premium. Users are welcome to continue to use the old versions of the AWS Plugin, but those versions will not be getting any more updates. More information on those changes can be found here: CloudQuery Pricing Changes

3

Also happy to support extended free trials for the newest versions. Feel free to pick a slot here calendly.com/yevgenyp or let me know the team you registered with on CloudQuery Cloud so I can enable a trial (signup should be with corporate email).

4

I’ve read the post, but it wasn’t clear to me which “old” plugin versions will still be able to query paid tables. We are currently using V16.2.0 of the AWS plugin. Will this version still be able to query the premium tables that were compatible?

I still do not get how I can communicate this to upper management to consider the possibility of upgrading to your premium tier.

5

We will NOT be touching or changing any previously released versions, so if your organization is alright with the version that you are on, there is no need to upgrade.

That being said, there has been a LOT of improvement in the AWS plugin since it was released nearly a year ago (nearly double the number of supported resources, massive improvements in memory usage) as well as the ecosystem as a whole in terms of source and destination plugins.

If you book some time on the calendar linked above, we would be happy to discuss the changes that have been implemented and how they can help your organization.

6

Thanks for the clarification:

I have an additional question: How can we identify tables that might be leaking or logging sensitive data?

Is there a compiled list of such tables?

There is a concern that enabling all tables using wildcards (*) could result in the logging of sensitive values from sources such as AWS or others.

This question hasn’t been addressed in your security documentation, available at CloudQuery Security Documentation.

7

I think this all depends on what your organization considers sensitive. In general, we do not recommend using

table: ["*"]

We recommend specifying the exact tables you want after you have identified that the data is valuable to your organization.