Self-implemented IFTTT Pro's RSS feed notification feature with AWS serverless architecture

This article is a translation of https://masutaka.net/2025-07-20-1/.

For casual information gathering, I've been running a serverless application called masutaka-feed since 2020.

• Post GitHub private feeds to Mastodon

  • Example: https://github.com/masutaka.private.atom?token=xxxx

  • Star and follow notifications are also sent to Pushover

• Post Hatena Bookmark favorites feeds to Mastodon

  • Example: https://b.hatena.ne.jp/masutaka26/favorite.rss?key=xxxx

These are pieces of information that aren't worth subscribing to seriously with a feed reader, but I want to keep them in my field of view.

※ Mastodon posts are made to the private account @masutakafeed@mstdn.love

Previous Architecture Diagram

Previously, I used IFTTT's RSS Feed Integration to detect new items and call Lambda functions via API Gateway.

However, starting in 2024, RSS Feed Integration became available only with paid IFTTT Pro, so I was reluctantly paying the annual fee of $34.99.

GitHub:

Hatena Bookmark:

Current Architecture Diagram

Since I wasn't using IFTTT anywhere else, I really didn't want to continue paying the annual $34.99, so I completely migrated to an AWS serverless architecture this time.

The architecture uses EventBridge Scheduler to periodically check feeds and DynamoDB for read state management. Dependencies on external services have been eliminated, and processing is now completed entirely within AWS.

GitHub:

Hatena Bookmark:

Current Architecture

In the new architecture, the following components work together:

Periodic execution with EventBridge Scheduler

GitHub private feeds are checked every 5 minutes, and Hatena Bookmark favorites feeds every 15 minutes, executing the Lambda Subscriber functions shown below.

Lambda function responsibility separation

Each feed is separated into 2 Lambda functions:

1. Subscriber function: Feed retrieval and new item detection

   • Retrieve RSS/Atom feeds and parse with rss-parser

   • Manage read state with DynamoDB

   • Call Notifier function if there are new items

2. Notifier function: Execute notification processing

   • Filtering processing (GitHub only notifies specific events)

   • Post to Mastodon

   • Send notifications to Pushover (GitHub only)

Duplicate prevention with DynamoDB

• Create tables for each feed

  • GitHub: masutaka-feed-github-state

  • Hatena Bookmark: masutaka-feed-hatebu-state

• Set partition keys

  • GitHub: Atom feed, each entry's id

  • Hatena Bookmark: RSS 1.0 feed, each item's rdf:about

• Set TTL to automatically delete old records after 30 days

Configuration management with SAM continues

As before, I use AWS SAM to manage the configuration of added components.

• samconfig.toml

• template.yaml

Environment variables continue to be managed with GitHub Actions Secrets/Variables, and automatic deployment occurs when commits are added to the main branch.

• .github/workflows/deploy.yml

After the migration

• Despite increased responsibilities, the code became unexpectedly cleaner

• rss-parser was more convenient than expected - by just defining feed types like GitHubFeedItem and HatebuFeedItem, parsing became simple

  • As a result, I was able to abandon HTML extraction using regular expressions

• No longer need to pay IFTTT Pro's annual $34.99

  • AWS costs stay within the free tier

• Running error-free for about 2 weeks

Implemented with Claude Code

After starting to pay for IFTTT Pro, I had the concept in my head, but since it was essentially refactoring, I couldn't get motivated and left it alone.

Claude Code helped me overcome that lack of motivation, and I made great use of it.

1. Migration from JavaScript to TypeScript

   • https://github.com/masutaka/masutaka-feed/pull/74

2. Migration from IFTTT Pro to AWS self-implementation

   • https://github.com/masutaka/masutaka-feed/pull/77

:bulb: Each commit message in the pull requests contains Claude Code prompts.

Resource definitions in template.yaml are tedious to research, but Claude Code wrote them in one shot. Of course, I verified them afterwards.

• EventBridge Schedulers definition

• DynamoDB Tables definition

• IAM Role settings for each resource

• CloudWatch Alarm monitoring definitions

Conclusion

By self-implementing IFTTT Pro's feed notification feature with AWS serverless architecture, I was able to gain the following benefits:

• Cost reduction: Annual fixed cost of $34.99 became essentially zero

• Transparency gained: Full control over what items are added to feeds and what items have been marked as read

• Enhanced monitoring: Can set up monitoring for feed subscriptions and detect failures immediately

• Code optimization: Optimized feed parsing using rss-parser

Additionally, by utilizing Claude Code, I was able to significantly lower the motivation barrier for tasks like migrating from JavaScript to TypeScript and creating SAM templates.

I will continue to operate masutaka-feed at a low altitude going forward.