Jeff’s Note (Contextual Hook) #
Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For AWS DVA-C02 candidates, the confusion often lies in choosing between Lambda event filtering vs SNS subscription filter policies. In production, this boils down to knowing exactly which service-level filtering reduces effort, error surface, and improves event fan-out efficiency without code changes. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
A team at BrightWave Solutions is building a notification processing system where updates from their CRM are pushed as messages to an SNS topic. These messages cover various updates such as phone number changes, email address changes, and mailing address changes. BrightWave wants their Lambda function to process only the messages about email address changes, while other subscribers will handle all other kinds of messages.
The Requirement: #
Implement the message filtering solution that ensures the Lambda function reacts only to email address change events with the least amount of development effort.
The Options #
- A) Use Lambda event filtering to allow only messages related to email address changes to invoke the Lambda function.
- B) Use an SNS filter policy on the Lambda function subscription to allow only messages related to email address changes to invoke the Lambda function.
- C) Subscribe an Amazon SQS queue to the SNS topic. Configure the SQS queue with a filter policy to allow only messages related to email address changes. Connect the SQS queue to the Lambda function.
- D) Configure the Lambda code to check the received message. If the message is not related to email address changes, have the Lambda function publish the message back to the SNS topic for the other subscribers to process.
Google adsense #
leave a comment:
Correct Answer #
B) Use an SNS filter policy on the Lambda function subscription to allow only messages related to email address changes to invoke the Lambda function.
Quick Insight: The Developer Imperative #
- Lambda event filtering (Option A) is great but is a relatively newer feature and might have certain limitations depending on runtimes and configurations.
- SNS filter policies (Option B) are native to the SNS subscription model and provide the simplest, most efficient way to filter at the message routing layer — reducing Lambda cold starts and unnecessary invocations.
- SQS filtering (Option C) adds unnecessary complexity and latency for this use case.
- Filtering in Lambda code (Option D) wastes compute resources and complicates business logic.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option B
The Winning Logic #
Option B leverages SNS subscription filter policies, which allow SNS to inspect message attributes at the routing layer and deliver only those messages that meet the filter criteria to the Lambda subscriber. This means:
- Filtering happens before Lambda invocation, reducing execution costs and avoiding unnecessary Lambda cold starts.
- No changes are required to Lambda code for filtering logic, minimizing development effort.
- SNS fully manages the filtering lifecycle, making operations simpler and more reliable.
- This method provides clean message fan-out and allows other subscribers to process other events.
The Trap (Distractor Analysis) #
- Option A (Lambda event filtering): While Lambda event filtering supports message attribute-based filtering, it is relatively newer and might not be available or mature for all languages or configurations. Also, event filtering occurs after Lambda is triggered, causing a slight inefficiency despite dropping the event early.
- Option C (SQS with filter policy): SNS supports filter policies on SQS subscriptions, but adding SQS as an intermediary introduces more components and maintenance overhead, plus added latency, contradicting the “least development effort” goal.
- Option D (Filtering in Lambda code): This is the least efficient. It invokes the Lambda for all messages, consuming compute and adding complexity by republishing messages, which risks message loops, duplication, and increased SNS costs.
The Technical Blueprint #
# Example CLI command to add SNS filter policy on Lambda subscription
SUBSCRIPTION_ARN=$(aws sns list-subscriptions-by-topic --topic-arn arn:aws:sns:region:account-id:topicName \
--query 'Subscriptions[?Endpoint==`arn:aws:lambda:region:account-id:function:functionName`].SubscriptionArn' --output text)
aws sns set-subscription-attributes \
--subscription-arn $SUBSCRIPTION_ARN \
--attribute-name FilterPolicy \
--attribute-value '{"eventType": ["email_address_change"]}'
The Comparative Analysis #
| Option | API Complexity | Performance Impact | Use Case Suitability | Dev Effort | Latency |
|---|---|---|---|---|---|
| A) Lambda Event Filtering | Low-Medium (per Lambda config) | Moderate (invocation occurs) | Good if runtime supports fully | Low | Low |
| B) SNS Filter Policy | Low (SNS CLI/API config) | High (no Lambda invoke if filtered) | Ideal for pure routing filter | Very Low | Lowest |
| C) SQS + SNS Filter Policy | Medium-High (multi-service) | Medium (extra queue latency) | Complex workflows needing buffering | High | Medium |
| D) Lambda Code Filtering | Medium (custom code) | Low (wastes Lambda runtime) | Only if no other options | High | High |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For AWS Lambda triggered by SNS, always prefer SNS filter policies to minimize unnecessary Lambda invocations.”
Real World #
“In production systems, using SNS filter policies improves cost efficiency and operational simplicity. Lambda event filtering is emerging but not universally supported.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.