Forem: Abhishek Vasisht

Cost-Aware Platform Engineering: Implementing FinOps in AWS

Abhishek Vasisht — Wed, 04 Feb 2026 07:50:59 +0000

How we transformed our AWS spending from reactive firefighting to proactive cost optimization, reducing waste by 30% while scaling infrastructure 3x - A Platform Engineering Manager's Journey

The Wake-Up Call

It was a Monday morning when our VP of Engineering & IT walked into my office with a printout of our AWS bill. Three months of data told a concerning story:

Month 1: $70K
Month 2: $81K (+15.6%)
Month 3: $100K (+23.3%)

"At this rate," he said, "we're on track for significant annual growth. What's the plan?"

I didn't have a good answer. Like many platform teams, we had focused on velocity and reliability, treating cost as an afterthought. Our developers could spin up resources freely, our monitoring focused on uptime not spend, and our architecture decisions rarely considered the price tag.

That conversation sparked a transformation in how we approach platform engineering. This is the story of how we implemented FinOps practices into our AWS platform, making cost awareness a first-class concern without sacrificing developer velocity.

The Platform Engineering Challenge

As Platform Engineering Managers, we face a unique challenge: enabling developer productivity while maintaining operational excellence AND cost efficiency. Traditional approaches force us to choose:

❌ Option A: Cost Control Through Restriction

Lock down permissions
Manual approval for resources
Developers wait days for infrastructure
Innovation slows to a crawl

❌ Option B: Developer Freedom Without Guardrails

Self-service everything
No cost visibility
Surprise bills at month-end
VP of Engineering & IT unhappy, platform team blamed

✅ Option C: Cost-Aware Platform Engineering

Self-service with intelligent guardrails
Real-time cost visibility
Automated optimization
Developers empowered, finance happy

This blog post shows you how to implement Option C.

Our FinOps Journey: The Three Phases

Phase 1: Visibility          Phase 2: Optimization       Phase 3: Culture
┌─────────────────┐         ┌─────────────────┐         ┌─────────────────┐
│ • Cost tracking │         │ • Rightsizing   │         │ • Cost reviews  │
│ • Tagging       │    →    │ • Reserved Inst │    →    │ • Team KPIs     │
│ • Dashboards    │         │ • Automation    │         │ • Best practices│
│ • Alerts        │         │ • Governance    │         │ • Training      │
└─────────────────┘         └─────────────────┘         └─────────────────┘
   Weeks 1-4                   Weeks 5-12                  Ongoing

Let's dive into each phase with real implementation insights.

Phase 1: Visibility - You Can't Optimize What You Can't See

The Problem We Discovered

When we analyzed our costs, we found:

89.7% of cost increase came from a single production account
EC2 compute grew 62.3% in one month ($12,390 increase)
New infrastructure appeared without platform team awareness
No one knew which team or application was responsible

Solution 1: Automated Cost Reporting

We built a serverless billing bot that sends daily reports to Microsoft Teams:

Architecture:

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   EventBridge   │───▶│  Lambda Function │───▶│ Microsoft Teams │
│   (Daily 9AM)   │    │  (Cost Analysis) │    │  (Adaptive Card)│
└─────────────────┘    └──────────────────┘    └─────────────────┘
                                │
                                ▼
                       ┌──────────────────┐
                       │ Cost Explorer API│
                       │ Organizations API│
                       └──────────────────┘

Key Features:

Daily cost summaries with account names (not just IDs)
Week-over-week and month-over-month comparisons
Top 5 services and accounts by spend
Projected monthly costs based on current burn rate
Automatic alerts for >15% daily changes

Sample Report:

💰 AWS Daily Billing Report

💵 Yesterday's Total: $3,245.67
📈 Daily Change: 📉 -$234.12 (-6.7%)
📊 Weekly Change: 📈 +$456.23 (+16.4%)
📅 Month-to-Date: $84,387.45
🎯 Projected Monthly: $103,482.70

🏢 Top Contributing Accounts
Production Primary: $2,234.56 (68.8%)
Production Secondary: $623.45 (19.2%)
Development: $387.66 (12.0%)

🔧 Top Services by Cost
EC2 - Compute: $1,845.23
RDS: $567.89
S3: $234.56

Implementation:

We used AWS SAM (Serverless Application Model) for deployment:

Lambda Function fetches cost data from Cost Explorer and Organizations APIs
EventBridge triggers daily at 9 AM
Microsoft Teams integration via Adaptive Cards

Benefits:

Serverless (no infrastructure to manage)
Cost-effective (~$0.03/month)
Reliable daily execution
Easy to maintain and update

📖 For complete implementation: Building an Automated AWS Billing Report System

Solution 2: Comprehensive Tagging Strategy

We implemented a mandatory tagging policy across all AWS resources:

Required Tags:

CostCenter: "engineering" | "product" | "data" | "infrastructure"
Environment: "prod" | "staging" | "dev" | "sandbox"
Team: "platform" | "backend" | "frontend" | "data-science"
Application: "api-gateway" | "user-service" | "analytics"
Owner: "email@company.com"
Project: "project-name"

Enforcement with AWS Organizations:

Use Service Control Policies (SCPs) to deny resource creation without required tags:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyResourceCreationWithoutTags",
    "Effect": "Deny",
    "Action": ["ec2:RunInstances", "rds:CreateDBInstance", "s3:CreateBucket"],
    "Resource": "*",
    "Condition": {
      "StringNotLike": {
        "aws:RequestTag/CostCenter": "*",
        "aws:RequestTag/Environment": "*",
        "aws:RequestTag/Team": "*"
      }
    }
  }]
}

Enforcement Strategy:

Use Infrastructure as Code (Terraform/CloudFormation) with required tag variables
Implement pre-commit hooks to validate tags
Create reusable modules with tags baked in
Set up automated tag compliance scanning

Solution 3: Real-Time Cost Dashboards

We created CloudWatch dashboards showing cost trends in real-time:

Dashboard Components:

Daily Spend Trend (last 30 days)
Cost by Account (pie chart)
Cost by Service (bar chart)
Top 10 Resources by cost
Budget vs Actual (gauge)
Anomaly Detection alerts

Implementation Options:

AWS CloudWatch Dashboards (native, free)
Grafana with CloudWatch data source (more customizable)
QuickSight for executive reporting (business intelligence)

Result: Platform team and developers can now see cost impact within hours, not weeks.

Solution 4: Intelligent Budget Alerts

We set up multi-level budget alerts with different thresholds:

Budget Structure:

Organization Budget: $X/month (total)
├── Production Account: $Y/month (largest allocation)
│   ├── Alert at 50% → Platform Team
│   ├── Alert at 75% → Engineering Manager
│   └── Alert at 90% → VP of Engineering & IT + Head of Software Development
├── Development Account: $Z/month (medium allocation)
│   ├── Alert at 80% → Platform Team
│   └── Alert at 100% → Engineering Manager
└── Sandbox Account: $W/month (smallest allocation)
    └── Alert at 100% → Platform Team

Implementation Approach:

Use AWS Budgets for threshold-based alerts
Configure multiple notification levels (50%, 75%, 90%, 100%)
Set up both ACTUAL and FORECASTED alert types
Route notifications to appropriate teams via email or SNS

Alert Strategy:

50% threshold: Early warning to platform team
75% threshold: Escalate to engineering manager
90% threshold: Executive notification (VP of Engineering & IT / Head of Software Development)
100% threshold: Immediate action required

Phase 1 Results:

✅ Daily cost visibility for all stakeholders
✅ Account-level cost attribution
✅ Service-level spend tracking
✅ Proactive alerts before budget overruns
✅ Historical trend analysis

Time to Implement: 2 weeks

Cost: ~$5/month (AWS Budgets + Lambda)

Phase 2: Optimization - From Visibility to Action

With visibility in place, we discovered several optimization opportunities:

Discovery 1: EC2 Instance Rightsizing

The Problem:

40% of EC2 instances were oversized
Average CPU utilization: 15-25%
Average memory utilization: 30-40%
Estimated waste: $15,000/month

The Solution:

We used AWS Compute Optimizer to identify rightsizing opportunities:

Rightsizing Strategy:

Immediate wins (>50% savings): Resize during next maintenance window
Medium opportunities (20-50% savings): Schedule for quarterly optimization
Small optimizations (<20% savings): Evaluate during annual review

Key Metrics to Monitor:

CPU utilization (target: 40-70%)
Memory utilization (target: 50-80%)
Network throughput
Disk I/O patterns

Results:

Resized 45 instances in production
Monthly savings: $12,400
Performance impact: None (monitored for 30 days)
ROI: Immediate

Discovery 2: Reserved Instances & Savings Plans

The Analysis:

After 3 months of data, we identified stable workloads:

Production databases: 24/7 uptime, predictable load
Core API services: Consistent baseline capacity
Monitoring infrastructure: Always-on requirements

The Strategy:

Workload Type          | Commitment Strategy        | Savings
-----------------------|----------------------------|----------
Production RDS         | 3-year Reserved Instance   | 63%
Core EC2 (baseline)    | 1-year Compute Savings Plan| 42%
Variable EC2 (burst)   | On-Demand                  | 0%
Development (9-5)      | Instance Scheduler         | 65%

Purchase Decision Matrix:

Utilization Rate | Recommendation           | Commitment
-----------------|--------------------------|------------
> 90%            | 3-year RI (All Upfront)  | Maximum savings
75-90%           | 1-year RI (Partial)      | Balanced
50-75%           | Compute Savings Plan     | Flexible
< 50%            | On-Demand                | No commitment

Analysis Approach:

Review 90 days of usage patterns
Identify stable workloads (>75% utilization)
Calculate ROI for different commitment levels
Start conservative with 1-year commitments

Results:

Purchased $45,000 in Reserved Instances
Annual savings: $18,900 (42% discount)
Payback period: 2.4 years
Risk mitigation: Started with 1-year commitments

Discovery 3: Automated Resource Cleanup

The Problem:

We found significant waste from forgotten resources:

23 stopped EC2 instances (still paying for EBS volumes)
15 unattached EBS volumes
8 old snapshots (>180 days)
12 unused Elastic IPs
Estimated waste: $3,200/month

The Solution:

Automated cleanup with AWS Lambda and EventBridge:

Cleanup Policy:

Day 0: Resource becomes idle
Day 7: First notification to owner
Day 10: Second notification with deletion warning
Day 14: Automatic deletion (unless KeepAlive tag present)

Implementation Approach:

Lambda function scans for idle resources daily
SNS notifications to resource owners
Grace period with KeepAlive tag option
CloudWatch logs for audit trail

Results:

Cleaned up 45 unused resources in first month
Monthly savings: $3,200
Zero complaints (14-day grace period worked well)
Developers became more conscious of resource lifecycle

Discovery 4: Development Environment Scheduling

The Problem:

Development and staging environments ran 24/7 but were only used 9 AM - 6 PM weekdays:

168 hours/week available
45 hours/week actually used (27% utilization)
Waste: $8,500/month

The Solution:

AWS Instance Scheduler with custom schedules:

Schedule Definitions:

dev-hours:        Mon-Fri 8 AM - 7 PM
staging-hours:    Mon-Fri 7 AM - 8 PM
always-on:        24x7 (production only)

Implementation:

Tag-based scheduling (Schedule=dev-hours)
Automatic start before work hours
Automatic stop after hours
Override capability for special cases

Results:

Scheduled 85 development instances
Scheduled 32 staging instances
Monthly savings: $8,500
Developer feedback: Positive (instances auto-start before work hours)
Unexpected benefit: Forced developers to use IaC (instances recreated daily)

Discovery 5: S3 Storage Optimization

The Problem:

S3 costs grew 45% over 3 months with no clear ownership:

2.3 TB in Standard storage
890 GB of data >90 days old
450 GB of incomplete multipart uploads
Monthly cost: $5,200

The Solution:

Intelligent tiering and lifecycle policies:

Storage Class Decision Tree:

Access Pattern                    | Storage Class        | Cost/GB/Month
----------------------------------|----------------------|---------------
Frequent access (>1/month)        | Standard             | $0.023
Infrequent access (>1/quarter)    | Standard-IA          | $0.0125
Rare access (>1/year)             | Glacier IR           | $0.004
Archive (rarely accessed)         | Glacier Deep Archive | $0.00099
Unknown pattern                   | Intelligent-Tiering  | $0.023-0.00099

Lifecycle Policy Strategy:

Move to IA after 30 days
Move to Glacier IR after 90 days
Move to Deep Archive after 180 days
Delete incomplete multipart uploads after 7 days
Delete old versions after 90 days

Results:

Moved 890 GB to Glacier Instant Retrieval
Cleaned up 450 GB of incomplete uploads
Enabled Intelligent-Tiering on 15 buckets
Monthly savings: $1,850
Storage costs reduced by 35%

Phase 2 Summary:

Optimization	Monthly Savings	Implementation Time
EC2 Rightsizing	$12,400	2 weeks
Reserved Instances	$18,900 (annual)	1 week
Resource Cleanup	$3,200	1 week
Dev Scheduling	$8,500	1 week
S3 Optimization	$1,850	1 week
Total	$26,950/month	6 weeks

Annual Impact: $323,400 in savings

Phase 3: Culture - Making FinOps Everyone's Responsibility

Technology alone doesn't create lasting change. We needed to shift the culture.

Initiative 1: Cost-Aware Development Guidelines

We created platform engineering standards that developers follow:

The FinOps Developer Checklist:

Before Deploying to Production:

✅ Resource Sizing

Right-sized instances based on actual load testing
Configured auto-scaling with appropriate min/max
Reviewed CloudWatch metrics for 2+ weeks in staging

✅ Cost Optimization

Enabled S3 lifecycle policies for data storage
Configured RDS automated backups with retention limits
Used appropriate storage classes (GP3 vs GP2 vs IO1)
Implemented caching where applicable (ElastiCache, CloudFront)

✅ Tagging & Governance

All resources tagged with: CostCenter, Team, Application, Environment
Budget alerts configured for the application
Cost dashboard created in CloudWatch

✅ Monitoring

Cost anomaly detection enabled
Utilization metrics tracked
Cleanup automation configured for temporary resources

Infrastructure as Code Guardrails:

We built cost-awareness into our IaC modules:

Instance type validation (prevent oversized instances in dev)
Automatic scheduling tags for non-prod environments
Cost estimation outputs in Terraform plans
Budget threshold checks before deployment

Initiative 2: Monthly Cost Review Meetings

We established a monthly FinOps review with all engineering teams:

Meeting Structure (60 minutes):

Cost Overview (10 min)
- Total spend vs budget
- Month-over-month comparison
- Top 5 cost drivers
Team Deep Dives (30 min)
- Each team presents their top 3 services
- Explains any significant changes
- Shares optimization wins
Optimization Opportunities (15 min)
- Platform team presents recommendations
- Discussion of implementation plans
- Assignment of action items
Best Practices Sharing (5 min)
- Highlight cost-saving innovations
- Recognize teams with best improvements

Sample Report Output:

📊 FinOps Monthly Review

💰 Cost Summary
Total Spend: $87K (Budget: $95K)
vs Last Month: -$13K (-13%) ✅
vs Last Year: +$23K (+36%)

🏆 Team Performance
┌──────────────┬──────────┬──────────┬─────────┐
│ Team         │ Spend    │ Change   │ Status  │
├──────────────┼──────────┼──────────┼─────────┤
│ Platform     │ $32K     │ -15% ✅   │ On Track│
│ Backend      │ $28K     │ -8% ✅    │ On Track│
│ Data Science │ $19K     │ +5%      │ Watch   │
│ Frontend     │ $8K      │ -2% ✅    │ On Track│
└──────────────┴──────────┴──────────┴─────────┘

🎯 Optimization Wins This Month
1. Platform Team: Rightsized 12 RDS instances → $2.4K/mo savings
2. Backend Team: Implemented ElastiCache → $1.8K/mo savings
3. Data Science: Moved to Spot instances → $3.2K/mo savings

📈 Recommendations
1. Backend Team: 8 EC2 instances eligible for Reserved Instances
   Potential savings: $4.2K/month
2. Data Science: S3 buckets with old data (>180 days)
   Potential savings: $890/month

Initiative 3: Cost Attribution & Team Accountability

We made cost visibility transparent at the team level:

Team Cost Dashboard Features:

Real-time spend by team (using CostCenter tag)
Budget vs actual with visual indicators
Top services by cost for each team
Trend analysis (daily, weekly, monthly)
Comparison with other teams (anonymized)

Slack Integration for Real-Time Alerts:

Teams receive daily cost summaries in their Slack channels:

Yesterday's spend with daily change
Week-over-week comparison
Month-to-date vs budget
Top 3 services by cost
Automatic alerts for >20% daily increases

Benefits:

Teams own their costs
Real-time feedback loop
Friendly competition between teams
Early detection of cost spikes

Initiative 4: FinOps Training & Enablement

We created a comprehensive training program for all engineers:

FinOps Training Curriculum:

Week 1: Fundamentals

Understanding AWS pricing models
Reading and interpreting AWS bills
Cost allocation tags and their importance
Introduction to Cost Explorer

Week 2: Optimization Techniques

EC2 instance selection and rightsizing
Reserved Instances vs Savings Plans
S3 storage classes and lifecycle policies
Database optimization (RDS, DynamoDB)

Week 3: Platform Tools

Using our cost dashboards
Setting up budget alerts
Automated cleanup tools
Cost estimation in Terraform

Week 4: Best Practices

Architecture for cost efficiency
Serverless vs containers vs VMs
Monitoring and alerting
Case studies from our teams

FinOps Champion Certification:

We created an internal certification program:

Requirements:

Complete 4-week training program
Achieve 30% cost reduction in your team's AWS spend
Present optimization case study to engineering team
Mentor 2 other engineers on FinOps practices

Benefits:

Recognition in company all-hands
Professional development budget
Priority for AWS certification training
FinOps Champion badge

Initiative 5: Cost-Aware Architecture Reviews

We integrated cost considerations into our architecture review process:

Architecture Review Checklist (Cost Section):

✅ Estimated Costs

Monthly cost estimate provided (with calculations)
Cost comparison with alternative approaches
Breakdown by service (compute, storage, data transfer)

✅ Scalability & Cost

Cost scaling analyzed (linear, exponential, logarithmic)
Auto-scaling configured with cost limits
Peak load costs estimated and budgeted

✅ Optimization Strategy

Reserved capacity opportunities identified
Spot instances considered for appropriate workloads
Caching strategy to reduce compute/database costs
Data transfer costs minimized (same region, VPC endpoints)

✅ Monitoring & Alerts

Cost anomaly detection configured
Budget alerts set at 50%, 75%, 90%
Cost dashboard created for the service
Runbook for cost spike investigation

✅ Alternatives Considered

Serverless vs container vs VM comparison
Managed service vs self-hosted cost analysis
Multi-region vs single-region cost implications

Real Example from Our Reviews:

Architecture Review: New Analytics Pipeline
==========================================

Proposed Architecture:
- 5x m5.2xlarge EC2 instances (24/7)
- 2TB S3 Standard storage
- RDS PostgreSQL db.r5.2xlarge
Estimated Monthly Cost: $4,850

Alternative Architecture (Platform Team Recommendation):
- AWS Glue for ETL (serverless)
- S3 Intelligent-Tiering (2TB)
- Aurora Serverless v2 (auto-scaling)
Estimated Monthly Cost: $1,240

Decision: Approved alternative architecture
Savings: $3,610/month ($43,320/year)

The Results: 6 Months Later

After implementing our FinOps platform engineering practices, here's what we achieved:

Financial Impact

Month     | Actual Spend | Without FinOps | Savings  | Cumulative
----------|--------------|----------------|----------|------------
Month 1   | $70K         | $70K           | $0       | $0
Month 2   | $81K         | $81K           | $0       | $0
Month 3   | $100K        | $100K          | $0       | $0
Month 4   | $87K         | $120K          | $33K     | $33K
Month 5   | $85K         | $144K          | $59K     | $92K
Month 6   | $82K         | $173K          | $91K     | $183K

Total Savings (3 months post-implementation): $183K
Projected Annual Savings: ~$730K

Key Metrics

Metric	Before FinOps	After FinOps	Improvement
Monthly AWS Spend	$100K	$82K	-18%
Cost per Developer	Higher	Lower	-18%
Wasted Resources	~35%	~8%	-77%
Budget Overruns	3/month	0/month	-100%
Cost Visibility	Leadership only	All teams	+100%
Time to Detect Issues	30 days	<24 hours	-97%
Developer Satisfaction	7.2/10	8.9/10	+24%

Operational Improvements

Before FinOps:

❌ Monthly surprise bills
❌ No cost attribution
❌ Reactive firefighting
❌ Developers unaware of costs
❌ Manual cost analysis (8 hours/month)
❌ No optimization process

After FinOps:

✅ Predictable spending
✅ Team-level cost visibility
✅ Proactive optimization
✅ Cost-aware development culture
✅ Automated reporting (<1 hour/month)
✅ Continuous optimization

Cultural Transformation

Developer Feedback:

"I used to just pick the biggest instance type to be safe. Now I actually think about what I need and use the cost estimator. Turns out t3.medium works fine for most of our services."

— Backend Developer

"The daily Slack updates make me aware of our team's spending. When I see a spike, I investigate immediately instead of waiting for the monthly bill."

— Team Lead

"The FinOps training changed how I design systems. I now consider cost as a first-class requirement, not an afterthought."

— Senior Engineer

Leadership Feedback:

"We went from reactive cost management to proactive optimization. The platform team's FinOps implementation has been transformational."

— Head of Software Development

"The visibility and predictability we now have makes financial planning so much easier. And the savings speak for themselves."

— VP of Engineering & IT

Lessons Learned: What Worked and What Didn't

What Worked Well ✅

1. Start with Visibility, Not Restrictions

We didn't lock down permissions or block developers. We gave them visibility first, and behavior changed naturally.

2. Automate Everything

Manual cost analysis is unsustainable. Our automated daily reports, cleanup scripts, and scheduling saved hundreds of hours.

3. Make It Easy to Do the Right Thing

Our IaC modules with cost guardrails made it easier to be cost-efficient than wasteful.

4. Celebrate Wins Publicly

Recognizing teams that achieved cost savings created positive peer pressure and friendly competition.

5. Integrate with Existing Workflows

Slack notifications, Grafana dashboards, and architecture reviews fit into existing processes rather than creating new ones.

What Didn't Work ❌

1. Initial Tagging Enforcement Was Too Strict

Our first attempt blocked all resource creation without perfect tags. This frustrated developers and slowed velocity. We relaxed to required tags only.

2. Cost Alerts Were Too Noisy

Early alerts fired for every 5% change. Teams ignored them. We adjusted to 15% for daily, 25% for weekly.

3. One-Size-Fits-All Policies

Applying the same lifecycle policies to all S3 buckets caused issues. We learned to categorize by data type first.

4. Assuming Everyone Understands AWS Pricing

Many developers didn't know the difference between Reserved Instances and Savings Plans. Training was essential.

5. Focusing Only on Big Wins

We initially ignored small optimizations (<$100/month). But 50 small wins = $5,000/month savings.

Unexpected Benefits 🎁

1. Better Architecture Decisions

Cost awareness led to better designs: more caching, better auto-scaling, appropriate service selection.

2. Improved Resource Hygiene

Automated cleanup forced teams to use Infrastructure as Code and properly manage resource lifecycles.

3. Faster Incident Response

Cost anomaly detection caught several production issues before they became major incidents.

4. Stronger Team Collaboration

Monthly cost reviews brought teams together to share learnings and best practices.

5. Career Development

Engineers who became FinOps champions gained valuable skills and visibility in the organization.

Getting Started: Your FinOps Implementation Roadmap

Based on our experience, here's a practical 90-day plan to implement FinOps in your organization:

Days 1-30: Foundation & Visibility

Week 1: Assessment

[ ] Analyze last 3 months of AWS bills
[ ] Identify top 10 cost drivers
[ ] Map costs to teams/applications (best effort)
[ ] Document current state and pain points

Week 2: Quick Wins

[ ] Set up AWS Budgets with alerts
[ ] Deploy automated billing report
[ ] Create basic CloudWatch cost dashboard
[ ] Identify and clean up obvious waste

Week 3: Tagging Strategy

[ ] Define required tags
[ ] Create tagging policy document
[ ] Tag existing critical resources
[ ] Implement tag enforcement for new resources

Week 4: Team Enablement

[ ] Present findings to engineering teams
[ ] Share cost dashboards and reports
[ ] Conduct initial FinOps training session
[ ] Establish monthly cost review meeting

Expected Results: 5-10% cost reduction, full visibility into spending

Days 31-60: Optimization & Automation

Week 5: EC2 Optimization

[ ] Enable AWS Compute Optimizer
[ ] Analyze rightsizing recommendations
[ ] Implement instance scheduler for dev/staging
[ ] Rightsize top 10 oversized instances

Week 6: Storage Optimization

[ ] Audit S3 buckets and implement lifecycle policies
[ ] Review EBS volumes and snapshots
[ ] Enable S3 Intelligent-Tiering where appropriate
[ ] Clean up old snapshots and AMIs

Week 7: Reserved Capacity

[ ] Analyze usage patterns for stable workloads
[ ] Calculate ROI for Reserved Instances
[ ] Purchase initial RIs (start conservative)
[ ] Document RI management process

Week 8: Automation

[ ] Deploy automated resource cleanup Lambda
[ ] Set up cost anomaly detection
[ ] Create IaC modules with cost guardrails
[ ] Implement automated cost reporting

Expected Results: 15-25% cost reduction, automated optimization processes

Days 61-90: Culture & Governance

Week 9: Architecture Integration

[ ] Add cost section to architecture review template
[ ] Create cost estimation tools
[ ] Document cost-aware design patterns
[ ] Review upcoming projects for cost optimization

Week 10: Team Accountability

[ ] Implement team-level cost dashboards
[ ] Set up Slack/Teams cost notifications
[ ] Create team cost budgets
[ ] Establish cost KPIs for teams

Week 11: Training & Certification

[ ] Develop comprehensive FinOps training program
[ ] Train team leads and senior engineers
[ ] Create internal FinOps champion program
[ ] Document best practices and runbooks

Week 12: Continuous Improvement

[ ] Conduct first monthly FinOps review
[ ] Gather feedback and iterate
[ ] Plan next quarter's optimization initiatives
[ ] Celebrate and communicate wins

Expected Results: 25-35% cost reduction, sustainable FinOps culture

Essential Tools & Resources

AWS Native Tools (Free):

AWS Cost Explorer
AWS Budgets
AWS Compute Optimizer
AWS Cost Anomaly Detection
AWS Trusted Advisor

Open Source Tools:

Cloud Custodian (policy as code)
Komiser (cloud asset dashboard)
Infracost (Terraform cost estimation)
CloudQuery (cloud asset inventory)

Recommended Reading:

"Cloud FinOps" by J.R. Storment and Mike Fuller
AWS Well-Architected Framework - Cost Optimization Pillar
FinOps Foundation resources (finops.org)

Common Pitfalls and How to Avoid Them

Pitfall 1: Analysis Paralysis

Problem: Spending months analyzing costs without taking action.

Solution: Start with quick wins in week 1:

Clean up stopped instances
Delete unattached volumes
Set up basic budgets
Deploy automated reporting

Impact: 5-10% savings in first week builds momentum.

Pitfall 2: Over-Optimization

Problem: Spending $1000 in engineering time to save $50/month.

Solution: Use the 10x rule:

Only optimize if annual savings > 10x implementation cost
Example: If optimization takes 8 hours ($800), annual savings should be >$8,000

Pitfall 3: Ignoring Developer Experience

Problem: Cost controls that slow down development velocity.

Solution: Make cost-efficient choices the easy choice:

Provide IaC modules with sensible defaults
Automate optimization (don't require manual work)
Give visibility, not restrictions

Pitfall 4: Lack of Executive Support

Problem: FinOps treated as "IT's problem" without leadership buy-in.

Solution: Speak the language of business:

Show ROI in dollars, not percentages
Connect cost savings to business outcomes
Present at executive meetings with clear metrics

Example Pitch:

"Our FinOps initiative delivered significant cost savings in the first quarter. That's equivalent to hiring additional engineers or funding new product features. With continued optimization, we project substantial annual savings that directly impact our bottom line."

Pitfall 5: Set-and-Forget Mentality

Problem: Implementing FinOps once and assuming it's done.

Solution: FinOps is continuous:

Monthly cost reviews
Quarterly optimization sprints
Annual strategy refresh
Ongoing training and enablement

Measuring Success: Key FinOps Metrics

Track these metrics to measure your FinOps maturity:

Financial Metrics

Total Cloud Spend (monthly trend, YoY growth)
Cost per customer/transaction
Cost per developer
Infrastructure cost as % of revenue
Waste metrics (unused, idle, oversized resources)
Monthly savings from optimizations
ROI of FinOps program

Operational Metrics

% of resources with complete tags
% of costs attributed to teams
Time to detect cost anomalies
Budget compliance rate
Policy violation rate
% of resources managed by IaC
Automated optimization actions/month

Cultural Metrics

% of engineers trained in FinOps
Cost dashboard active users
Cost review meeting attendance
Cost optimization ideas submitted
FinOps champions certified
Developer satisfaction score

FinOps Maturity Model

Level 1: Reactive (Crawl)
├─ Manual cost analysis
├─ No tagging strategy
├─ Surprise bills common
└─ No optimization process

Level 2: Proactive (Walk)
├─ Automated reporting
├─ Basic tagging in place
├─ Budget alerts configured
└─ Ad-hoc optimizations

Level 3: Optimized (Run)
├─ Real-time visibility
├─ Comprehensive tagging
├─ Predictable spending
├─ Continuous optimization
└─ Cost-aware culture

Level 4: Advanced (Fly)
├─ Predictive analytics
├─ Multi-cloud optimization
├─ FinOps as code
├─ Cost innovation
└─ Industry-leading efficiency

Our Journey:

Month 1: Level 1 (Reactive)
Month 3: Level 2 (Proactive)
Month 6: Level 3 (Optimized)
Target: Level 4 (Advanced)

Real-World Case Studies from Our Teams

Case Study 1: Backend Team - API Service Optimization

Challenge:

Backend team's API service costs grew 85% in 2 months with no corresponding traffic increase.

Investigation:

12 m5.xlarge instances running 24/7
Average CPU utilization: 18%
Peak CPU utilization: 45%
Traffic pattern: 9 AM - 6 PM weekdays

Solution:

Rightsized to m5.large (50% cost reduction)
Implemented auto-scaling (3-8 instances based on load)
Configured instance scheduler for non-peak hours
Added ElastiCache to reduce database load

Results:

Monthly cost: $15,170 → $5,240 (65% reduction)
Annual savings: $119,160
Performance: Improved (better caching)
Implementation time: 1 week

Key Lesson: "We were over-provisioning for peak load that rarely happened. Auto-scaling gave us better performance at 1/3 the cost."

Case Study 2: Data Science Team - ML Training Optimization

Challenge:

Data Science team spending $12,000/month on GPU instances for model training, with instances idle 60% of the time.

Investigation:

4x p3.2xlarge instances (24/7)
Training jobs: 2-4 hours each
Jobs run: 3-4 times per day
Idle time: 14-16 hours/day

Solution:

Migrated to SageMaker Training Jobs (pay per use)
Used Spot instances for training (70% discount)
Implemented training job scheduler
Optimized model code (reduced training time 30%)

Results:

Monthly cost: $12,000 → $3,200 (73% reduction)
Annual savings: $105,600
Training time: Reduced by 30%
Implementation time: 2 weeks

Key Lesson: "Serverless ML training with spot instances was a game-changer. We only pay when we're actually training."

Case Study 3: Platform Team - Monitoring Infrastructure

Challenge:

Monitoring infrastructure (Prometheus, Grafana, ELK) costing $6,500/month, growing 15% monthly.

Investigation:

EC2 instances: $3,200/month
EBS volumes: $1,800/month
Data transfer: $1,500/month

Solution:

Migrated to AWS Managed Services:
- Amazon Managed Prometheus
- Amazon Managed Grafana
- Amazon OpenSearch Service
Implemented log filtering (reduced volume 60%)
Configured log retention policies (30 days hot, 90 days cold)

Results:

Monthly cost: $6,500 → $2,800 (57% reduction)
Annual savings: $44,400
Operational overhead: Reduced 80%
Reliability: Improved (managed services)
Implementation time: 3 weeks

Key Lesson: "Managed services cost more per unit but eliminated operational overhead and actually saved money overall."

Case Study 4: Frontend Team - CDN and Storage

Challenge:

Frontend team's S3 and CloudFront costs growing 40% monthly due to increased traffic.

Investigation:

S3 storage: 800 GB (all Standard class)
CloudFront data transfer: 15 TB/month
Cache hit ratio: 45% (should be >80%)
Image optimization: None

Solution:

Implemented image optimization (WebP format, compression)
Improved CloudFront caching (increased TTL)
Moved old assets to S3 Intelligent-Tiering
Enabled CloudFront compression

Results:

S3 costs: $184 → $98 (47% reduction)
CloudFront costs: $1,275 → $510 (60% reduction)
Cache hit ratio: 45% → 87%
Page load time: Improved 35%
Implementation time: 1 week

Key Lesson: "Optimizing for performance also optimized for cost. Better caching reduced both latency and data transfer costs."

The Platform Engineering Perspective

As a Platform Engineering Manager, implementing FinOps taught me several crucial lessons:

1. Platform Teams Are Cost Enablers, Not Cost Police

Our role isn't to restrict developers—it's to enable them to make cost-effective choices easily:

Provide tools: Cost dashboards, estimation tools, IaC modules
Create guardrails: Sensible defaults, automated cleanup, budget alerts
Enable self-service: Developers can provision resources without approval
Offer guidance: Training, documentation, architecture reviews

2. Cost Optimization Is a Product Feature

Treat FinOps like any other platform capability:

User research: Understand developer pain points
Iterative development: Start small, gather feedback, improve
Measure success: Track adoption, savings, satisfaction
Continuous improvement: Regular updates and enhancements

3. Culture Change Takes Time

Technical implementation is fast (weeks). Cultural transformation is slow (months):

Month 1: Resistance ("This is finance's job, not mine")
Month 2: Curiosity ("Interesting, but not a priority")
Month 3: Engagement ("Let me try this optimization")
Month 6: Ownership ("We saved $5K this month!")

Be patient and celebrate small wins.

4. Executive Support Is Critical

FinOps succeeds when leadership:

Allocates time: Engineers need time for optimization work
Recognizes efforts: Public acknowledgment of cost savings
Provides resources: Budget for tools and training
Sets expectations: Cost efficiency as a performance metric

5. Start Small, Think Big

Our implementation roadmap:

Week 1: Quick wins (cleanup, budgets)
  ↓
Month 1: Visibility (dashboards, reporting)
  ↓
Month 3: Optimization (rightsizing, scheduling)
  ↓
Month 6: Culture (training, accountability)
  ↓
Year 1: Maturity (predictive analytics, innovation)

Don't try to do everything at once. Build momentum with early wins.

Conclusion: The Future of Cost-Aware Platform Engineering

Six months ago, we faced a crisis: unsustainable AWS cost growth threatening our business. Today, we have a mature FinOps practice that has:

Achieved significant cost savings through systematic optimization
Dramatically reduced waste across our infrastructure
Improved visibility from leadership-only to all teams
Transformed culture from cost-ignorant to cost-aware
Enhanced developer experience with better tools and processes

But more importantly, we've fundamentally changed how we think about platform engineering.

The New Platform Engineering Paradigm

Traditional Platform Engineering:

Focus: Reliability + Velocity
Metrics: Uptime, deployment frequency, MTTR
Cost: Afterthought, handled by finance

Cost-Aware Platform Engineering:

Focus: Reliability + Velocity + Efficiency
Metrics: Uptime, deployment frequency, MTTR, cost per transaction
Cost: First-class requirement, owned by engineering

Key Principles We Live By

Cost is a feature, not a constraint
- Efficient systems are better systems
- Cost optimization drives architectural improvements
- Savings fund innovation
Visibility drives behavior
- Developers can't optimize what they can't see
- Real-time feedback creates accountability
- Transparency builds trust
Automation scales culture
- Manual processes don't scale
- Automated optimization is sustainable
- Tools enable best practices
Continuous improvement is the goal
- FinOps is never "done"
- Always room for optimization
- Learn, measure, improve, repeat

What's Next for Us

Our FinOps roadmap for the coming months:

Short-term (Next Quarter):

Implement predictive cost modeling with ML
Expand to multi-cloud cost optimization
Launch advanced FinOps certification program
Build cost optimization into CI/CD pipelines

Medium-term (6-12 Months):

Achieve advanced FinOps maturity
Further reduce waste through automation
Implement carbon-aware computing
Share learnings at industry conferences

Call to Action

If you're a Platform Engineering Manager facing similar challenges:

Start today:

Analyze your last 3 months of AWS bills
Identify your top 5 cost drivers
Set up basic budget alerts
Deploy automated cost reporting

This week:

Clean up obvious waste (stopped instances, unattached volumes)
Implement a tagging strategy
Create a cost dashboard
Schedule your first FinOps team meeting

This month:

Rightsize oversized instances
Implement instance scheduling for dev/staging
Set up automated cleanup
Conduct FinOps training for your team

This quarter:

Evaluate Reserved Instances and Savings Plans
Optimize storage with lifecycle policies
Integrate cost into architecture reviews
Establish monthly cost review meetings

Final Thoughts

FinOps isn't about spending less—it's about spending smart. It's about building a culture where every engineer understands the cost impact of their decisions and has the tools to make efficient choices.

The journey from reactive cost management to proactive optimization wasn't just about saving money. It was about building a better platform, creating better systems, and empowering better engineers.

The best time to start your FinOps journey was yesterday. The second best time is today.

Resources and Next Steps

Recommended Resources

Books:

"Cloud FinOps" by J.R. Storment and Mike Fuller
"The DevOps Handbook" by Gene Kim et al.
"AWS Well-Architected Framework" - Cost Optimization Pillar

Websites:

FinOps Foundation - Industry best practices
AWS Cost Optimization - Official AWS resources
The FinOps Podcast - Weekly FinOps discussions

Certifications:

FinOps Certified Practitioner
AWS Certified Cloud Practitioner
AWS Certified Solutions Architect

Building an Automated AWS Billing Report System with SAM and Microsoft Teams

Abhishek Vasisht — Sun, 18 Jan 2026 08:04:11 +0000

How we built a serverless solution that sends daily AWS cost reports to Microsoft Teams, featuring account names, cost analysis, and smart alerts - all for less than $0.50/month.

A serverless, automated AWS cost reporting system that posts daily insights directly to Microsoft Teams using AWS SAM and Python.

The Challenge

As our AWS infrastructure grew across multiple accounts and services, keeping track of daily spending became increasingly difficult. We needed a solution that would:

Provide daily visibility into AWS costs across all accounts
Send alerts for significant cost changes
Display meaningful account names instead of cryptic account IDs
Integrate seamlessly with our existing Microsoft Teams workflow
Cost almost nothing to operate
Be easy to deploy and maintain

Traditional solutions like AWS Budgets or third-party tools either lacked the customization we needed or came with hefty price tags. So we decided to build our own serverless solution using AWS SAM.

The Solution Architecture

Our final architecture is elegantly simple yet powerful:

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   EventBridge   │───▶│  Lambda Function │───▶│ Microsoft Teams │
│   (Schedule)    │    │  (Billing Bot)   │    │ (Power Automate)│
└─────────────────┘    └──────────────────┘    └─────────────────┘
                                │
                                ▼
                       ┌──────────────────┐    ┌─────────────────┐
                       │ AWS Cost Explorer│    │ AWS Organizations│
                       │   (Billing Data) │    │ (Account Names) │
                       └──────────────────┘    └─────────────────┘

Key Components:

AWS Lambda: Processes billing data and formats reports
EventBridge: Triggers daily reports at 9 AM NZT
Cost Explorer API: Provides detailed billing data
Organizations API: Resolves account names
Microsoft Teams: Receives rich Adaptive Card notifications

Why We Chose AWS SAM Over CDK

Initially, we started with AWS CDK but quickly ran into deployment complexity:

Docker dependency for Python packaging
Complex bundling configuration
Deployment failures due to missing dependencies
Harder local testing

AWS SAM proved to be the better choice:

# Simple deployment with SAM
sam build
sam deploy --guided

SAM Benefits:

✅ No Docker required
✅ Built-in Python dependency management
✅ Excellent local testing with sam local invoke
✅ Cleaner template syntax
✅ Better error messages
✅ Faster development cycle

Implementation Journey

Phase 1: Basic Cost Reporting

We started with a simple Lambda function that fetches yesterday's costs:

def get_billing_data(self):
    """Fetch billing data using AWS Cost Explorer API"""
    today = datetime.now().date()
    yesterday = today - timedelta(days=1)

    response = self.ce_client.get_cost_and_usage(
        TimePeriod={
            'Start': yesterday.strftime('%Y-%m-%d'),
            'End': today.strftime('%Y-%m-%d')
        },
        Granularity='DAILY',
        Metrics=['UnblendedCost'],
        GroupBy=[
            {'Type': 'DIMENSION', 'Key': 'LINKED_ACCOUNT'},
            {'Type': 'DIMENSION', 'Key': 'SERVICE'}
        ]
    )
    return response

Phase 2: Enhanced Analytics

We added comparative analysis and projections:

# Calculate daily and weekly changes
daily_change = yesterday_total - previous_total
daily_change_pct = (daily_change / previous_total * 100) if previous_total > 0 else 0

# Project monthly costs
daily_average = mtd_total / days_elapsed if days_elapsed > 0 else yesterday_total
projected_monthly = daily_average * days_in_month

Phase 3: Teams Integration Challenge

The biggest challenge was getting Microsoft Teams integration right. Native Teams webhooks are being deprecated, so we had to use Power Automate:

Key Learning: Power Automate expects Adaptive Cards with "type": "AdaptiveCard", not the legacy MessageCard format.

adaptive_card = {
    "type": "AdaptiveCard",
    "version": "1.2",
    "body": [
        {
            "type": "Container",
            "style": color,
            "items": [
                {
                    "type": "TextBlock",
                    "text": "💰 AWS Daily Billing Report",
                    "weight": "Bolder",
                    "size": "Large"
                }
            ]
        }
    ]
}

Phase 4: Account Names Feature

Business users wanted meaningful account names instead of masked IDs like "****7737". We integrated AWS Organizations API:

def get_account_name(self, account_id):
    """Get account name from Organizations API with caching"""
    if account_id in self.account_names_cache:
        return self.account_names_cache[account_id]

    try:
        response = self.org_client.describe_account(AccountId=account_id)
        account_name = response['Account']['Name']
        self.account_names_cache[account_id] = account_name
        return account_name
    except Exception as e:
        # Graceful fallback to masked ID
        masked_id = f"****{account_id[-4:]}"
        self.account_names_cache[account_id] = f"Account {masked_id}"
        return self.account_names_cache[account_id]

Critical IAM Lesson: We initially added a restrictive condition to the Organizations permissions:

# This DIDN'T work
- Effect: Allow
  Action:
    - organizations:DescribeAccount
  Resource: '*'
  Condition:
    StringEquals:
      'organizations:ActionType': 'READ'  # This condition caused access denied

The fix was simple - remove the condition:

# This WORKS
- Effect: Allow
  Action:
    - organizations:DescribeAccount
  Resource: '*'

Phase 5: Historical Context

Users wanted better context for cost projections, so we added last month's total:

# Fetch last month's data for context
last_month_response = self.ce_client.get_cost_and_usage(
    TimePeriod={
        'Start': last_month_start.strftime('%Y-%m-%d'),
        'End': last_month_end.strftime('%Y-%m-%d')
    },
    Granularity='MONTHLY',
    Metrics=['UnblendedCost']
)

Deployment Best Practices

1. Secure Parameter Management

Never hardcode webhook URLs in your code. Use parameter overrides:

# Secure deployment
sam deploy --parameter-overrides TeamsWebhookUrl="https://your-webhook-url"

2. Multi-Environment Support

Our SAM template supports multiple environments:

Parameters:
  Environment:
    Type: String
    Default: prod
    AllowedValues: [dev, staging, prod]
    Description: Environment name for resource naming

3. Proper Git Workflow

We used feature branches for development:

# Create feature branch
git checkout -b feature/account-names-and-last-month-context

# Make changes, test, commit
git add .
git commit -m "feat: Add account names and last month context"

# Push and create pull request
git push -u origin feature/account-names-and-last-month-context

4. Local Testing Strategy

Always test locally before deploying:

# test_local.py - Load environment from env.json
def load_env_from_json():
    if os.path.exists('env.json'):
        with open('env.json', 'r') as f:
            env_config = json.load(f)
            if 'BillingFunction' in env_config:
                for key, value in env_config['BillingFunction'].items():
                    os.environ[key] = value

The Results

Our solution now delivers rich, actionable billing reports:

💰 AWS Daily Billing Report
Report for January 7, 2026

💰 Key Metrics
💵 Yesterday's Total: $1,795.29
📈 Daily Change: 📉 -$1,356.35 (-43.0%)
📊 Weekly Change: 📉 -$1,121.95 (-38.5%)
📅 Month-to-Date: $23,367.06
🎯 Projected Monthly: $103,482.70 (Day 7/31)
📊 Last Month: $145,230.75

🏢 Top Contributing Accounts
Production Account: $1,234.56 (68.8%)
Development Account: $345.67 (19.2%)
Staging Account: $215.06 (12.0%)

🔧 Top Services by Cost
Elastic Compute Cloud - Compute: $1,234.56
Simple Storage Service: $234.56
Relational Database Service: $156.78

Cost Analysis

Our solution is incredibly cost-effective:

Service	Monthly Usage	Cost
Lambda	30 executions, 256MB, 30s avg	~$0.01
EventBridge	30 rule executions	~$0.00
CloudWatch Logs	10MB logs, 30-day retention	~$0.01
Cost Explorer API	120 API calls	Free
Organizations API	150 API calls	Free
Data Transfer	Minimal outbound	~$0.00
S3	SAM deployment artifacts	~$0.01
Total		~$0.03/month

Lessons Learned

1. Choose the Right Tool

SAM was significantly better than CDK for this serverless use case. Don't assume the "newer" tool is always better.

2. Test IAM Permissions Thoroughly

IAM conditions can be tricky. When in doubt, start with basic permissions and add conditions only when necessary.

3. Plan for Graceful Degradation

Our account name feature falls back to masked IDs if Organizations access fails. Always plan for failure scenarios.

4. Security First

Use parameter overrides for sensitive data. Never commit webhook URLs or API keys to version control.

5. Documentation Matters

Good documentation saved us hours during troubleshooting and made the solution maintainable.

Getting Started

Want to implement this solution? Here's a complete step-by-step guide:

1. Create the Project Structure

# Create a new SAM project
mkdir aws-billing-automation
cd aws-billing-automation

# Create the directory structure
mkdir src events

2. Create the SAM Template

Create template.yaml:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: AWS Billing Automation using SAM

Globals:
  Function:
    Timeout: 300
    MemorySize: 256
    Runtime: python3.9

Parameters:
  TeamsWebhookUrl:
    Type: String
    Description: Microsoft Teams webhook URL for Power Automate
    NoEcho: true

  Environment:
    Type: String
    Default: prod
    AllowedValues: [dev, staging, prod]
    Description: Environment name for resource naming

Resources:
  BillingFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub "${Environment}-aws-billing-automation"
      CodeUri: src/
      Handler: lambda_function.lambda_handler
      Environment:
        Variables:
          TEAMS_WEBHOOK_URL: !Ref TeamsWebhookUrl

      Policies:
        - Version: '2012-10-17'
          Statement:
            - Effect: Allow
              Action:
                - ce:GetCostAndUsage
                - ce:GetUsageReport
              Resource: '*'
            - Effect: Allow
              Action:
                - organizations:ListAccounts
                - organizations:DescribeAccount
              Resource: '*'

      Events:
        BillingSchedule:
          Type: Schedule
          Properties:
            Schedule: "cron(0 21 * * ? *)"  # 9 AM NZT daily
            Name: !Sub "${Environment}-billing-schedule"

3. Create the Lambda Function

Create src/lambda_function.py with the core billing logic (see the implementation examples above).

Create src/requirements.txt:

requests==2.31.0
boto3>=1.26.0

4. Create Environment Configuration

Create env.json.example:

{
  "BillingFunction": {
    "TEAMS_WEBHOOK_URL": "https://your-power-automate-webhook-url-here",
    "LOG_LEVEL": "INFO"
  }
}

5. Set Up Your Environment

# Copy environment template
cp env.json.example env.json

# Edit env.json with your actual webhook URL
# Set AWS region to us-east-1 (required for Cost Explorer)
export AWS_DEFAULT_REGION=us-east-1

6. Create Local Test Script

Create test_local.py for local testing:

#!/usr/bin/env python3
import os
import sys
import json

# Load environment from env.json
def load_env_from_json():
    if os.path.exists('env.json'):
        with open('env.json', 'r') as f:
            env_config = json.load(f)
            if 'BillingFunction' in env_config:
                for key, value in env_config['BillingFunction'].items():
                    os.environ[key] = value

load_env_from_json()
sys.path.insert(0, 'src')

from lambda_function import AWSBillingBot

def test_billing_bot():
    webhook_url = os.environ.get('TEAMS_WEBHOOK_URL')
    if not webhook_url or 'your-webhook-url-here' in webhook_url:
        print("❌ Please set your webhook URL in env.json")
        return False

    bot = AWSBillingBot(webhook_url)
    return bot.generate_report()

if __name__ == "__main__":
    print("🧪 Testing AWS Billing Bot locally...")
    success = test_billing_bot()
    print("✅ Test passed!" if success else "❌ Test failed!")

7. Test Locally

# Set your AWS profile
export AWS_PROFILE=your-profile-name

# Test the solution
python3 test_local.py

8. Deploy to AWS

# Build the application
sam build

# Deploy with guided setup (first time)
sam deploy --guided

# For subsequent deployments
sam deploy --parameter-overrides TeamsWebhookUrl="https://your-webhook-url"

9. Verify Deployment

# Test the deployed function
aws lambda invoke --function-name prod-aws-billing-automation response.json --region us-east-1

# Check the response
cat response.json

# View logs
sam logs -n BillingFunction --stack-name your-stack-name --tail

10. Set Up Microsoft Teams Integration

Create Power Automate Flow:
- Go to Power Automate (flow.microsoft.com)
- Create a new "Instant cloud flow"
- Choose "When an HTTP request is received" trigger
- Add "Post adaptive card in a chat or channel" action
- Connect to your Teams channel
- Save and copy the webhook URL
Update Your Deployment:

   sam deploy --parameter-overrides TeamsWebhookUrl="your-power-automate-webhook-url"

11. Create Cleanup Script

Create cleanup.sh for easy resource removal:

#!/bin/bash

# AWS SAM Billing Automation - Complete Cleanup Script
set -e

# Colors for output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'

STACK_NAME=${STACK_NAME:-"aws-billing-sam-prod"}
REGION=${AWS_DEFAULT_REGION:-"us-east-1"}

echo -e "${BLUE}🗑️  AWS SAM Billing Automation - Complete Cleanup${NC}"
echo "Stack: ${STACK_NAME}, Region: ${REGION}"

# Check AWS CLI
if ! aws sts get-caller-identity > /dev/null 2>&1; then
    echo -e "${RED}❌ AWS CLI not configured${NC}"
    exit 1
fi

# Check if stack exists
if aws cloudformation describe-stacks --stack-name $STACK_NAME --region $REGION > /dev/null 2>&1; then
    echo -e "${YELLOW}📋 Resources to be deleted:${NC}"
    aws cloudformation list-stack-resources --stack-name $STACK_NAME --region $REGION \
        --query 'StackResourceSummaries[*].[ResourceType,LogicalResourceId]' --output table

    echo -e "${RED}⚠️  WARNING: This will permanently delete all resources!${NC}"
    read -p "Type 'DELETE' to confirm: " confirmation

    if [ "$confirmation" != "DELETE" ]; then
        echo "Cleanup cancelled"
        exit 0
    fi

    # Delete stack
    if command -v sam &> /dev/null; then
        sam delete --stack-name $STACK_NAME --region $REGION --no-prompts
    else
        aws cloudformation delete-stack --stack-name $STACK_NAME --region $REGION
        aws cloudformation wait stack-delete-complete --stack-name $STACK_NAME --region $REGION
    fi

    echo -e "${GREEN}✅ Stack deleted successfully!${NC}"
else
    echo -e "${YELLOW}Stack not found or already deleted${NC}"
fi

echo -e "${GREEN}🎉 Cleanup completed!${NC}"

Make it executable:

chmod +x cleanup.sh

Complete File Structure

aws-billing-automation/
├── src/
│   ├── lambda_function.py      # Main Lambda code
│   └── requirements.txt        # Python dependencies
├── events/
│   └── test-event.json        # Test event for local testing
├── template.yaml              # SAM infrastructure template
├── env.json.example          # Environment variables template
├── test_local.py             # Local testing script
├── cleanup.sh               # Cleanup script
└── README.md               # Documentation

Advanced Features

Smart Alerts

The system automatically highlights significant cost changes:

if abs(analysis['daily_change_pct']) > 15:
    alert_container = {
        "type": "Container",
        "style": "Attention",
        "items": [{
            "type": "TextBlock",
            "text": "⚠️ Cost Alert",
            "weight": "Bolder",
            "color": "Attention"
        }]
    }

Monitoring Dashboard

Includes a CloudWatch dashboard for monitoring:

BillingDashboard:
  Type: AWS::CloudWatch::Dashboard
  Properties:
    DashboardName: !Sub "${Environment}-aws-billing-automation"
    DashboardBody: !Sub |
      {
        "widgets": [
          {
            "type": "metric",
            "properties": {
              "metrics": [
                ["AWS/Lambda", "Invocations", "FunctionName", "${BillingFunction}"],
                [".", "Errors", ".", "."],
                [".", "Duration", ".", "."]
              ]
            }
          }
        ]
      }

Cleanup Script

Easy cleanup when needed:

# Remove all resources
./cleanup.sh

Future Enhancements

We're considering these improvements:

Cost Anomaly Detection using AWS Cost Anomaly Detection service
Budget Integration with AWS Budgets API
Slack Integration for teams using Slack
Custom Metrics for business-specific KPIs
Multi-Region Support for global deployments

Conclusion

Building this AWS billing automation solution taught us valuable lessons about:

Tool Selection: SAM vs CDK for different use cases
IAM Best Practices: Avoiding overly restrictive conditions
Integration Challenges: Working with evolving APIs like Teams webhooks
Cost Optimization: Building solutions that cost pennies to operate
Operational Excellence: Proper testing, documentation, and deployment practices

The solution now provides our team with daily visibility into AWS costs, has prevented several cost overruns through early alerts, and has become an essential part of our FinOps toolkit.

Total Development Time: ~8 hours

Monthly Operating Cost: ~$0.03

Value Delivered: Immeasurable cost visibility and control

Resources

AWS SAM Documentation: docs.aws.amazon.com/serverless-application-model
Cost Explorer API: docs.aws.amazon.com/aws-cost-management/latest/APIReference
Microsoft Adaptive Cards: docs.microsoft.com/en-us/adaptive-cards
AWS Organizations API: docs.aws.amazon.com/organizations/latest/APIReference

Have you built similar cost monitoring solutions? What challenges did you face? Share your experiences in the comments below!

Tags: #AWS #SAM #Serverless #FinOps #CostOptimization #MicrosoftTeams #Lambda #Python #DevOps #CloudCosts

Accelerate customers cloud migration and modernization with AWS MAP

Abhishek Vasisht — Mon, 11 Sep 2023 00:59:36 +0000

Imagine you’re a CIO, CEO, or CTO of a sizable enterprise company tasked to craft Cloud Strategy for your organization. You’re fully convinced that steering the company toward cloud adoption is the optimal path for its expansion. However, there’s a significant hurdle: all applications currently reside in on-premise data centers, and your team possesses minimal cloud expertise.

This scenario very much resembles relocating from one country to another. When you’re single and living in a one-bedroom apartment, packing up your belongings and moving can be completed in a day or two with relative ease. Yet, the situation becomes considerably more complicated when you are married and have children. You must make extensive preparations and attend to numerous details, including schools, the destination’s suitability, cultural adjustments, weather considerations, and deciding what to do with your current residence. The complexity escalates tenfold when multiple employees of your company (with families undergo) a similar relocation process. Transitioning to the cloud resonates with this scenario in many ways, representing a life-changing event for the company and its employees.

This blog is for

Enterprises Leadership teams , who are committed, and considering the migration of mission-critical workloads from on-premise data centres (or other cloud providers) to the AWS cloud.
AWS Partners, to know, where is the meat for them in the program? In simple terms, how to utilize MAP to support and accelerate the cloud migration of an enterprise customer.
AWS Solution Architects (or Engineers), to understand what role they can play in Migration Acceleration Program for an enterprise grade customer.

MAP Introduction

The AWS Partner Migration Acceleration Program (MAP) is a comprehensive and proven methodology based on AWS’s experience migrating thousands of enterprise customers to the cloud. MAP provides an excellent starting point to assist in the migration journey by speeding up the cloud migration and modernization by simplifying complicated and time-consuming tasks.

🗺️ AWS MAP (migration acceleration program) is not limited to navigation instead it’s your guide to the cloud migration journey!. 🌥️

The Migration Acceleration Program (MAP) offers an array of cost-saving tools, efficient execution automation, and tailored training programs that are backed up by the expertise of AWS Partner Network, a global partner community and funding from AWS. The program utilizes a proven three-phased framework (Assess, Mobilize, and Migrate & Modernize) to enable clients to achieve their migration goals. MAP’s solutions allow clients to establish a strong foundation in the AWS cloud, minimize risk, and accelerate the process while offsetting initial costs. Clients can leverage the cloud’s performance, security, and reliability to enhance their operations.

Common drivers (or motivation)

There are various reasons why organizations decide to migrate to the cloud. One of the most common reasons is to shift away from traditional data centers. Currently, one of the enterprise clients I am assisting aims to complete a lift-and-shift migration of their Oracle heavy workload from the data center within the next two years. Their primary drivers for this decision are their intention to exit the data center and the approaching renewal period for their Oracle licensing.

Additionally, cloud migration enables companies to enhance their business agility, streamline their workforce productivity, gain visibility into their operational costs, and reduce the risk of failures, outages, and downtime.

These enterprises often face numerous challenges while migrating to AWS Cloud, including high initial costs and operational complexities. To overcome these challenges, MAP offers consulting support, training, and service credits, aimed at reducing the risk of migration and building a strong operational foundation. These services are designed to help organizations to offset the initial costs of migration and ensure a seamless transition to AWS Cloud.

Benefits for Enterprises

Enterprises can greatly benefit from migrating to AWS as it allows them to shift their focus from the unproductive task of maintaining existing systems and technical debt to concentrating on business innovation, which is crucial for long-term success and growth. By leveraging the cloud infrastructure and services provided by AWS, enterprises can streamline their operations, improve their scalability, and enhance their ability to respond to changing market demands.
Previously, in order to launch a product quickly, it was often necessary to make sacrifices and difficult trade-offs. However, with advancements in technology and modern business practices, it is now possible to bring products to market efficiently without compromising on quality or making painful sacrifices.
Rather than simply existing in the marketplace, enterprises can strive to distinguish themselves by leveraging new capabilities and technologies to gain a competitive edge.

How MAP Work?

The AWS Migration Acceleration Program involves three distinct phases.

1st phase – Assess the readiness

Before embarking on a migration project to the AWS Cloud, performing a migration readiness assessment (MRA) is important. The MAP assessment phase is designed to help identifying potential gaps in six key areas of the AWS Cloud Adoption Framework – business, people, governance, platform, security and operations. By performing this assessment, you can determine the necessary capabilities needed for a successful migration and develop your project’s comprehensive TCO (Total Cost of Ownership) model.

AWS CAF identifies specific organizational capabilities that are crucial to successful cloud transformations. These capabilities provide guidance to help you improve your cloud readiness. AWS CAF groups its capabilities into six perspective and each perspective comprises a set of capabilities that different stakeholders manage or own throughout the cloud transformation journey. You can use AWS Cloud Adoption Readiness Assessment Report to identify and prioritize transformation opportunities, evaluate and enhance your cloud readiness, and iteratively improve your transformation roadmap.

2nd phase – Mobilize your resources

During the mobilization phase, you lay the groundwork for your migration by addressing any capability gaps that were identified during the assessment phase. This phase is designed to streamline the migration decisions by providing you with guidance on migration plans that will enhance the overall success of the process. With the help of AWS Partner Solutions Architects and SMEs, you can validate migration patterns and identify workload candidates for the Pilot/MVP phase. Additionally, you establish success criteria by ensuring full operating capability based on the AWS Well-Architected Review (WAR).

3rd phase – Migrate & Modernize

During the Migrate and Modernize phase, AWS Migration Services, the AWS Professional Services team, and AWS Migration Partners collaborate closely with you to ensure the successful execution of the large-scale migration plan that was developed during the Mobilize phase. This involves various activities, such as identifying the correct migration tools and services, testing the migration process in a controlled environment, and providing guidance on optimizing your application architecture and infrastructure for maximum efficiency and cost savings in the cloud. Throughout the process, the AWS team works closely with you to provide support and expertise, ensuring that your migration is completed smoothly and with minimal disruption to your business operations.

As part of the Migration Acceleration Program, AWS offers financial incentives (funding) to support AWS customers in their migration process. These incentives are designed to offset the costs associated with migration, which can include expenses related to labor, training, and running two environments in parallel.

Program requirements for SI (Software Industry) and ISV (Independent Software vendors) Partners

AWS Partners are required to possess a migration consulting competency as a prerequisite to take advantage of the Migration Acceleration Program. AWS validates and promotes AWS partners that have demonstrated technical proficiency and proven customer success in specialized areas across industries, use cases, and workloads. AWS partners undergo rigorous technical and business verification by AWS and third-party auditors, including AWS WAF validation and review by AWS Partner SAs and AWS Product teams. Attaining an AWS competency helps partners to market and differentiate their business from other Partners by showcasing migration skills to AWS customers. Having an AWS competency designation gives customers full confidence in choosing the right AWS partner to team up with.

MAP 2.0 resources for partners

The AWS Migration Acceleration Program (MAP) offers its partners a range of valuable resources to help them advance their AWS MAP practice. In the APN Navigate Program, partners can access the “Migration to AWS Course,” a comprehensive training initiative that equips them with the knowledge and skills needed for successful migration to AWS.

AWS provides the “Migration Immersion Day” a publicly available hands-on experience for partners to deepen their understanding of AWS migration solutions and best practices.

The “Migration Game Day” offers a unique approach to learning by gamifying various migration scenarios to the AWS Cloud. It comprises two variants: the first focuses on a fictional 3-tier application migration, while the second, known as “AWS Migration and Modernization – Level 400,” delves into advanced migration concepts.

The “Migration Black Belt” (nicely explained by a Migration Black Belt) program is a specialized, long-term training initiative designed for AWS Partners. It requires no ongoing commitment from AWS Partner resources. In this program, technical resources are designated by AWS Partner Development Managers, who meet every six months for in-depth sessions on migration and modernization within the AWS Cloud. Participants gain hands-on experience through labs, immersion days, and Game Days while staying up-to-date with the latest AWS tooling and practices.

To maintain their place in the Black Belt program, participants must achieve specific milestones, such as earning new certifications, delivering Migration Immersion and Game Days for end customers, or contributing public content like blog articles or videos on migration topics.

Within AWS perspective guidance (APG), Migration Tool Comparison is a new offering from AWS that provides a comprehensive platform to help partners and customers find, compare, review, and select the right migration tool. This tool lets you efficiently filter the results based on the interests, requirements and use-case. Whether looking for a tool to migrate your applications, databases, or infrastructure, the Migration Tool Comparison tool can help you make an informed decision by providing detailed information and insights on the available options. It’s a great way to save time and effort in your migration journey while ensuring you choose the right tool for your business.

AWS competency partners in consulting and technology are collaborating and building joint solutions in AWS migration practices and offerings to accelerate migrations to the AWS cloud.

Conclusion

Leveraging AWS cloud services and adhering to best practices through AWS MAP offers advantages to multiple stakeholders:

Enterprises dedicated to cloud migration find it highly advantageous to utilize these resources and incentives, making it a compelling choice.
AWS Partners can enhance their migration expertise by tapping into the wealth of partner resources, ultimately aiding their clients in achieving seamless cloud transitions.
AWS Solutions Architects and Engineers stand to gain from gaining a holistic understanding of industry-leading migration methodologies and practices.

Forem: Abhishek Vasisht

Cost-Aware Platform Engineering: Implementing FinOps in AWS

The Wake-Up Call

The Platform Engineering Challenge

Our FinOps Journey: The Three Phases

Phase 1: Visibility - You Can't Optimize What You Can't See

The Problem We Discovered

Solution 1: Automated Cost Reporting

Solution 2: Comprehensive Tagging Strategy

Solution 3: Real-Time Cost Dashboards

Solution 4: Intelligent Budget Alerts

Phase 2: Optimization - From Visibility to Action

Discovery 1: EC2 Instance Rightsizing

Discovery 2: Reserved Instances & Savings Plans

Discovery 3: Automated Resource Cleanup

Discovery 4: Development Environment Scheduling

Discovery 5: S3 Storage Optimization

Phase 3: Culture - Making FinOps Everyone's Responsibility

Initiative 1: Cost-Aware Development Guidelines

Initiative 2: Monthly Cost Review Meetings

Initiative 3: Cost Attribution & Team Accountability

Initiative 4: FinOps Training & Enablement

Initiative 5: Cost-Aware Architecture Reviews

The Results: 6 Months Later

Financial Impact

Key Metrics

Operational Improvements

Cultural Transformation

Lessons Learned: What Worked and What Didn't

What Worked Well ✅

What Didn't Work ❌

Unexpected Benefits 🎁

Getting Started: Your FinOps Implementation Roadmap

Days 1-30: Foundation & Visibility

Days 31-60: Optimization & Automation

Days 61-90: Culture & Governance

Essential Tools & Resources

Common Pitfalls and How to Avoid Them

Pitfall 1: Analysis Paralysis

Pitfall 2: Over-Optimization

Pitfall 3: Ignoring Developer Experience

Pitfall 4: Lack of Executive Support

Pitfall 5: Set-and-Forget Mentality

Measuring Success: Key FinOps Metrics

Financial Metrics

Operational Metrics

Cultural Metrics

FinOps Maturity Model

Real-World Case Studies from Our Teams

Case Study 1: Backend Team - API Service Optimization

Case Study 2: Data Science Team - ML Training Optimization

Case Study 3: Platform Team - Monitoring Infrastructure

Case Study 4: Frontend Team - CDN and Storage

The Platform Engineering Perspective

1. Platform Teams Are Cost Enablers, Not Cost Police

2. Cost Optimization Is a Product Feature

3. Culture Change Takes Time

4. Executive Support Is Critical

5. Start Small, Think Big

Conclusion: The Future of Cost-Aware Platform Engineering

The New Platform Engineering Paradigm

Key Principles We Live By

What's Next for Us

Call to Action

Final Thoughts

Resources and Next Steps

Recommended Resources

Related Blog Posts

Building an Automated AWS Billing Report System with SAM and Microsoft Teams

The Challenge

The Solution Architecture

Why We Chose AWS SAM Over CDK

Implementation Journey

Phase 1: Basic Cost Reporting

Phase 2: Enhanced Analytics

Phase 3: Teams Integration Challenge

Phase 4: Account Names Feature

Phase 5: Historical Context

Deployment Best Practices

1. Secure Parameter Management