The disable_subscription_filter currently defaults to false, which automatically subscribes the log group to the cloudwatch-to-splunk lambda function. With this value false, three SSM variables are added to manage the Splunk HEC token, endpoint URI, and sourcetype.

Because SSM doesn't support empty parameters, the bogus value *** NO VALUE SET *** is pre-populated when Terraform creates the cloudwatch-to-splunk SSM. @kwessel suggests that the default for disable_subscription_filter be changed to true so that the lambda function doesn't attempt to handle logging traffic from a CloudWatch log group lacking meaningful data used to authenticate to Splunk. This creates log traffic in the lambda's own log, which doesn't bother me. However, the unsuccessful attempt to run the Splunk code produces an error that is considered a failure of the lambda function. When we start issuing alarms based on this lambda function's failure rate, this will result in false positives.

The ideal solution is for the lambda function to ignore the pre-populated bogus value and not generate an error.

My opinion is that logging is an important enough function that the infrastructure designer should have to make an explicit choice on whether he/she wants Splunk logging, alternate external logging, or no external logging other than CloudWatch itself.

It'd be best if we could stage everything for logging to Splunk but have the actual sending of logs enabled or disabled with a parameter.

Add comment to ssm_prefix variable definition to refer to terraform-aws-cloudwatch-log-group module that defines same variable, in order that both modules use default values consistent with one another. See /pull/7.

variable "ssm_prefix" {
  description = "Prefix string to be applied to look up runtime SSM variables)"
  default     = "/cloudwatch_to_splunk"
}

Please add documentation!