Keeping Cloud Chaos in Check: Introducing the AWS Resource Notifications for Microsoft Teams

It's been a long time since I wrote here. Things have been chaotic at work and also in my personal life lately. I could say I don't have enough time to write in the blog, although I'd be lying; one can always find time for writing things and stuff. Well... I can safely say that I've gathered some ideas and topics for this blog, so I can't wait to share all of them with you.

This post is about a feature that I've implemented for around 1 month now, and I can safely say that it's ready to be shared with all of you.

When you’re part of a large engineering organization, the cloud can start to feel like the Wild West. New EC2 instances pop up for quick tests, S3 buckets appear for last-minute data dumps, and an occasional IAM user gets created for “just one script.” Before long, you’re staring at a dashboard full of resources, each with its own price tag and security footprint—yet no clear owner in sight.

After one too many “Who spun this up?” conversations, I decided to automate the detective work. The result is AWS Resource Notifier, a serverless workflow that tracks resource creation and deletion events and sends a concise, clickable message into Microsoft Teams. This post explains the use case, shares the architecture, and shows you how to get it running in less than ten minutes.

The Pain We Needed to Solve

1. Lack of Ownership Visibility

Every resource carries a cost and a security footprint. Normally, using related tags would help identify the ownership, but there might be some cases where you cannot identify the owner of the resource. Knowing who created it is step 1 toward accountability, remediation, or optimization.

2. Notification Gaps

CloudTrail does record every API call, but scrolling through logs when an incident strikes is reactive and slow. We needed real‑time awareness.

3. Scaling Challenges

In large organizations, multiple teams share AWS accounts. PMs, devs, data scientists, cloud engineers and DevOps engineers all provision resources daily. Manual tracking doesn’t scale.

AWS Resource Notifier

This use case is a lightweight, serverless solution that pushes real‑time creation and deletion events straight into Microsoft Teams. No more surfing CloudTrail consoles or using Athena queries—your team sees what happened, who did it, and where it lives, all in‑line with their daily chat flow.

Architectural Diagram

From this architectural diagram, you can understand how things are working on a high level with the diagram below.

aws-resource-notifier regional architectural diagram

How It Works (High‑Level)

1. CloudTrail captures every API call.

2. Amazon EventBridge filters for create and delete actions on key services (EC2, S3, RDS, Lambda, IAM, Route 53, and more).

3. AWS Lambda parses the event, enriches it with resource details, and formats a rich card for Teams.

4. AWS Secrets Manager stores the Teams webhook URL securely.

5. Microsoft Teams receives a clean, clickable message—complete with AWS service icon, resource ID, region, actor, and a direct link to the AWS Console.

(Both regional and global resources are covered by dedicated stacks so you can monitor just one account or roll out to every region in an afternoon.)

Key Highlights

Feature	Why It Matters?
Serverless Architecture	Zero servers to manage; pay only for events processed.
Multi‑Region Support	Deploy once per region (or centrally for global services) and forget about it.
Card‑Based Teams UI	Clear, scannable notifications, no JSON dumps in chat.
One‑Command Deployment	./deploy.sh sets up CloudFormation stacks, secrets, and EventBridge rules.
Least‑Privilege IAM	Follows AWS best practices—Lambda has only what it needs to read events and post to Teams.

Getting Started on AWS Resource Notifications

1. Clone the aws-resource-notifier repository.

2. Create (or reuse) a Teams Incoming Webhook.

3. Run chmod +x deploy.sh && ./deploy.sh --region us-east-1 --webhook-url "https://<your‑webhook>".

4. Watch your Teams channel light up with the next AWS resource notifications.

(Optional flags let you choose environment names, prefixes, or delete the stack just as easily.)

Here is what an example Teams notification looks like:

Example Teams notification

Customizing for Additional Resources

Out‑of‑the‑box, the solution watches:

• IAM users

• Route 53 DNS records

• Security groups

• Lambda functions

• EC2 instances

• S3 buckets

• RDS instances

• VPCs

• Elastic Load Balancers

Need more? You only have to tweak two things:

1. EventBridge Rules

Add a new rule in the regional stack for resource‑specific Create*, Put*, or Delete* API calls (e.g., CreateTable for DynamoDB).

2. Lambda Handler

Inside the notifier Lambda, update—or add—a handler that:

• Extracts the right identifiers from the event (ARN, name, region).

• Builds a section in create_teams_message() for the new resource type.

• Optionally fetches tags or configuration for richer context.

Regional vs. Global Stacks

• Regional resources (EC2, S3, RDS, …): use the regional deployment script in every region you care about.

• Global resources (Route 53 records, IAM users): deploy the global-services stack once in us‑east‑1—the home of AWS global control planes.

Our current use case implements both patterns, but feel free to split or merge them to fit your own org structure.

Heads‑up: The project is still in the test phase. It works reliably for us in production‑like traffic, yet some edge cases may need tuning—especially if you introduce unfamiliar services.

Possible Improvements & Roadmap

Like I said, the use case is still in the testing phase, so there is plenty of room for improvement. These are the ones that came to my mind:

• Richer Teams Cards

  Add collapsible sections, severity colors, or actionable buttons (e.g., “Tag Owner” or “Open CloudWatch Logs”). Also, possible improvements can include adjusting the Teams Card image depending on the resource type, which can be imported from a URL (currently hardcoded).

• Tag‑Driven Routing

  Route notifications to different Teams channels based on project, cost center, or environment tags.

• Auto‑Remediation Hooks

  Trigger follow‑up Lambdas that quarantine rogue resources, add mandatory tags, or enforce lifecycle policies (also can be configured using AWS Config).

• Cross‑Account Visibility

  Aggregate events from multiple AWS accounts into a single Teams channel using EventBridge Pipes or AWS Organizations trails.

Final Thoughts

AWS gives us incredible freedom to build, but that freedom can introduce chaos if left unchecked. By pushing real-time resource events straight into Microsoft Teams, this small serverless workflow turns cloud activity into shared knowledge—all without adding dashboards, manual audits, or new logins.

If visibility, cost control, or compliance are on your team’s radar, give the AWS Resource Notifier a spin and let me know how it fits into your workflow. I’d love feedback, feature requests, or war stories from the field.

Happy building, and may your CloudTrail always tell a clear story!