<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Best AWS ingestion approach in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Best-AWS-ingestion-approach/m-p/551113#M91501</link>
    <description>&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;I am trying to settle on a new AWS event collection strategy.&amp;nbsp; We are currently collecting using the older pull (SQS/SNS) method, and would like to move to a more modern and flexible way of doing it.&amp;nbsp; Would like to collect AWS Config, CloudTrail, VPC Flow logs, CloudWatch, GuardDuty events from 100+ accounts into Splunk.&amp;nbsp; Also would like a filtering capability at the source where logs can be discarded based on some criteria (account or arn) and not sent to Splunk to be filtered.&amp;nbsp; &amp;nbsp;&lt;/P&gt;&lt;P&gt;Seems like Splunk has changed their recommendations in the last few years (lambda push, firehouse, etc)_, and I am not certain what is the recommended approach now to do this now with as little complexity as possible.&amp;nbsp; Project Trumpet seems like a good option, but&amp;nbsp; I am not seeing Splunk steer people to that.&amp;nbsp; &amp;nbsp;Also unclear what caveats are with each of these approaches.&amp;nbsp; If you go the Firehose route, how do you discard unwanted events?&amp;nbsp; Also there are cost considerations and it's unclear which approach is more cost effective.&lt;/P&gt;&lt;P&gt;Wondering what people have settled on in similar circumstances and why.&amp;nbsp; Thanks!&lt;/P&gt;</description>
    <pubDate>Mon, 10 May 2021 16:54:05 GMT</pubDate>
    <dc:creator>oleg106</dc:creator>
    <dc:date>2021-05-10T16:54:05Z</dc:date>
    <item>
      <title>Best AWS ingestion approach</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Best-AWS-ingestion-approach/m-p/551113#M91501</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;I am trying to settle on a new AWS event collection strategy.&amp;nbsp; We are currently collecting using the older pull (SQS/SNS) method, and would like to move to a more modern and flexible way of doing it.&amp;nbsp; Would like to collect AWS Config, CloudTrail, VPC Flow logs, CloudWatch, GuardDuty events from 100+ accounts into Splunk.&amp;nbsp; Also would like a filtering capability at the source where logs can be discarded based on some criteria (account or arn) and not sent to Splunk to be filtered.&amp;nbsp; &amp;nbsp;&lt;/P&gt;&lt;P&gt;Seems like Splunk has changed their recommendations in the last few years (lambda push, firehouse, etc)_, and I am not certain what is the recommended approach now to do this now with as little complexity as possible.&amp;nbsp; Project Trumpet seems like a good option, but&amp;nbsp; I am not seeing Splunk steer people to that.&amp;nbsp; &amp;nbsp;Also unclear what caveats are with each of these approaches.&amp;nbsp; If you go the Firehose route, how do you discard unwanted events?&amp;nbsp; Also there are cost considerations and it's unclear which approach is more cost effective.&lt;/P&gt;&lt;P&gt;Wondering what people have settled on in similar circumstances and why.&amp;nbsp; Thanks!&lt;/P&gt;</description>
      <pubDate>Mon, 10 May 2021 16:54:05 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Best-AWS-ingestion-approach/m-p/551113#M91501</guid>
      <dc:creator>oleg106</dc:creator>
      <dc:date>2021-05-10T16:54:05Z</dc:date>
    </item>
  </channel>
</rss>

