When a file lands in a folder you're watching, Files.com publishes a tidy message to your SNS Topic — or one a partner or another team owns — and SNS sends it to every Lambda, SQS queue, HTTPS endpoint, and subscriber. No Lambda sitting there watching a bucket to build or babysit.
SNS is great at one thing: publish a message to a Topic once, and it reaches every subscriber. What SNS doesn’t do is the file part — taking files in from partners over SFTP and FTPS, controlling who can touch which folder, and keeping an audit trail. Files.com does that part, and publishes a message to your Topic the moment a file lands. Your existing SNS fan-out kicks off, and there’s no Lambda watching a bucket to get the event going.
When something happens in a folder you’re watching, Files.com publishes a message to your SNS Topic — yours, or one a partner or another team owns — and SNS delivers it to everything subscribed. Files.com hands the message to SNS, and SNS takes it from there.
The message says what happened, where, by whom, from what address, over which protocol, and the file's name, type, and size. That's enough for a Lambda or SQS consumer to route and process the file without opening it first.
Instead of running a Lambda that polls a bucket to find out a partner's file showed up, let Files.com be the front door that takes the file in and publishes the event itself — with the access controls and audit trail a raw bucket path doesn't give you.
A lot of teams pay for Transfer Family thinking it's the only managed-transfer product that can send SNS notifications. Files.com publishes the same structured SNS events on its own, so you can drop Transfer Family and your event-driven pipeline keeps running.
A single SNS notification can publish to several Topics at once, so one folder's activity can kick off several downstream pipelines from one place.
Files.com publishes to your Topic with an AWS identity that can do one thing — put a message on the Topic, and nothing else. Setting up the event stream never widens what an attacker could reach in your AWS account.
Files.com publishes one message per file operation, the instant it happens — no waiting, no lumping things together. A downstream Lambda or SQS consumer reacts the moment a file lands.
Files.com records every event in its own audit log, separate from SNS. So the SNS stream is never your only record — the full trail is still there even if a subscriber misses a message.
A partner uploads a file over SFTP, Files.com publishes the event to SNS, and SNS sends it to a Lambda that processes the file and an SQS queue that holds it for your billing or EDI system. No Lambda sitting there watching a bucket.
SNS sends the same file event to as many places as you want — email, SMS, an internal HTTPS endpoint — so teams in different places all see a critical transfer the moment it happens.
The who, where, and from-what-address details feed a Lambda that writes to your SIEM, turning file activity into security data your team can watch.
A team paying for AWS Transfer Family only to get its SNS notifications points the same Lambda and SQS subscribers at the Topic Files.com publishes to — then retires Transfer Family and the glue code around it.
Your storage behind it all. Pointing Files.com at an S3 bucket and publishing SNS events is the classic AWS setup.
Learn MoreRun file jobs inside Files.com instead of stitching together Lambda, Step Functions, and EventBridge.
Learn More
The same idea over plain HTTP, for when the thing receiving the event isn't on AWS.
Learn MoreThe full, separate record of activity that sits behind the SNS stream.
Learn MoreThe full side-by-side for teams paying for Transfer Family just to get SNS notifications.
Learn MoreWhat buyers ask about how Files.com connects to SNS, what it costs, and what the integration actually does.
Start a free 7-day trial. Point a folder at an SNS Topic, run a test upload, and watch the event reach your subscribers. No credit card required.
No credit card required • 7-day free trial • Setup in minutes