Many teams treat cost as something to review after deployment. Mature engineering organizations treat it as an architectural dimension from day one.

Across high-performing cloud teams, a common shift happens:
Cost moves from “something finance deals with” to a standing item in standups, design sessions and architecture reviews.

Why?
Because every technical choice: storage class, scaling policy, compute family, data flow, creates long-term financial impact.

Why Cost Must Be Part of Every Architecture Review

Teams that incorporate cost into technical conversations:

• Build more predictable, efficient systems

• Reduce waste before it hits production

• Make tradeoffs with clarity instead of guesswork

• Strengthen the relationship between engineering, finance, and leadership

Teams that don’t:

• Discover problems only when the bill spikes

• Accumulate unnoticed architectural debt

• Lose control of budget and operational efficiency

Our Leadership Question

Has your organization made cost a standard part of architectural decision-making?
If not, the gap is already impacting your engineering velocity and long-term spend.

That’s it for this week’s FahmaCloud Newsletter (Edition 16).

• If you found this useful, forward it to someone responsible for AWS spending.
• Have a topic you want covered in a future issue? Just reply, I’d love to hear from you.

Fahmacloud Newsletter is owned and published by FahmaCloud LLC.

Unexpected behavior is a signal, not an annoyance, in engineering.
The same mindset applies to cloud costs.

When your AWS bill suddenly increases, it’s not “just a billing issue.”
It’s a production issue hiding in plain sight.

High-performing teams don’t ignore cost anomalies.
They investigate them with the same urgency and discipline as any other system incident.

Cost Spikes Are Symptoms, Not Surprises

Most cost increases trace back to a few root causes:

• A resource scaled quietly in the background

• A service was misconfigured

• A temporary resource was never cleaned up

• A new workload behaved differently under real traffic

• Someone ran an experiment and forgot to shut it down

In all cases, the spike is signal, not noise.

How to Debug Your Bill

Treat your cloud bill like you treat your logs:

1. Start With the Cost Explorer Trend

Look for the moment the spike began.
Patterns tell you whether it’s:

• Gradual (scaling, long-running tasks)

• Sudden (misconfigurations, one-time jobs)

• Repeating (scheduled tasks, predictable workloads)

2. Break It Down by Service

Identify which service is responsible: EC2, Lambda, S3, NAT Gateway, EBS, etc.

Engineers can’t fix “the bill went up,” but they can fix “NAT Gateway data processing increased 300% last night.”

3. Check for Oversized, Orphaned, or Forgotten Resources

This is where most real issues hide:

• Development boxes left running

• Snapshots never cleaned up

• Provisioned RDS or ElastiCache larger than needed

• Over-provisioned autoscaling

• Old deployments still consuming resources

Small mistakes turn into large invoices quickly.

Our Leadership Insight

A cost spike is not a failure, it’s feedback.
It’s an opportunity to tighten processes, improve observability, and reinforce ownership.

Teams that treat cloud costs as operational signals (not accounting events) consistently avoid recurring waste and build more resilient systems.

That’s it for this week’s Fahmacloud Newsletter (Edition 15).

• If you found this useful, forward it to a teammate or peer managing AWS costs.

• Have a question or topic you’d like us to cover in a future issue? Hit reply, we’d love to hear from you.

Fahmacloud Newsletter is owned and published by FahmaCloud LLC.

Many teams still treat cloud savings as cleanup: terminating idle instances, deleting snapshots, or shutting down unused services. These actions are helpful but don’t fix the root cause.

What’s Happening in Most Organizations

• Cost reviews happen after bills spike

• Engineers scramble to tag resources, review budgets, or shut down unused workloads

Problem? The system wasn’t designed with cost efficiency in mind.

Why Intentional Design Matters

Teams that consistently control costs do one thing differently: they engineer for cost efficiency upfront.

Great engineers understand:

• Usage patterns and peak demand

• Structural waste and duplicated workloads

• Opportunities for automation

• How architecture choices affect long-term spend

Practical Steps to Build a Cost-Efficient Environment

• Map usage behavior over time

• Identify over-provisioning and complexity

• Automate scaling, cleanup, and rightsizing

• Embed cost controls into architecture (serverless, autoscaling, batch processing)

Our Leadership Takeaway

AWS cost optimization isn’t a post-fact cleanup.
It’s an engineering discipline. Systems designed with cost in mind save money automatically.

That’s it for this week’s FahmaCloud Newsletter (Edition 14).

• If you found this useful, forward it to someone responsible for AWS spending.
• Have a topic you want covered in a future issue? Just reply, I’d love to hear from you.

Fahmacloud Newsletter is owned and published by FahmaCloud LLC. Contact us for more.

Managing cloud spend isn’t just a finance problem or an engineering problem, it’s a leadership challenge. Without a clear strategy, costs can quickly spiral out of control.

The real question is: who takes the lead on AWS cost optimization in your organization?

• Finance: responsible for budgeting, forecasting, and tracking spend

• Cloud/DevOps Engineers: managing resources, implementing automation, and executing cost-saving measures

• IT Leadership: driving accountability, setting priorities, and aligning cost goals with business objectives

From our experience, the most successful approach is a collaborative one:

• Finance sets clear budgets and monitors spending trends

• Engineers implement cost-saving measures, automation, and scalable architectures

• Leadership ensures accountability, guides decisions, and aligns cloud spend with strategic business outcomes

Why This Matters

AWS cost optimization isn’t just about cutting costs, it’s about building efficient, predictable, and scalable cloud operations. Teams that coordinate across finance, engineering, and leadership consistently deliver better ROI while maintaining reliability and performance.

Actionable Tip

Set up a cross-functional cloud cost task force or steering committee. Make it clear who owns which responsibilities, track KPIs, and meet regularly to review spend and optimization opportunities.

That’s it for this week’s Fahmacloud Newsletter (Edition 13).

• If you found this useful, forward it to a teammate or peer managing AWS costs.

• Have a question or topic you’d like us to cover in a future issue? Hit reply, we’d love to hear from you.

A common misconception in many organizations is that moving to the cloud automatically reduces costs.

It doesn’t.
In fact, without discipline, the cloud often becomes more expensive.

Cost savings don’t come from the platform.
They come from how well you manage what you run.

High-performing engineering organizations treat cloud spend as a shared operational responsibility, not a financial afterthought. And the teams that consistently avoid surprises all share the same foundational habits.

Start With the Simple Habits That Build Cost-Aware Culture

Even before audits, automation, or re-architecture, two small practices deliver an outsized impact:

1. Check Your Cost Dashboard Frequently

Cost visibility removes guesswork.
Teams that monitor spend weekly, not quarterly, catch anomalies early, avoid bill shock, and understand usage patterns better than those who rely on end-of-month reports.

2. Tag Everything

Untagged resources are the #1 cause of wasted spend.
Proper tagging ensures:

• Ownership

• Accountability

• Accurate reporting

• Chargeback/showback

• Faster cleanup and optimization

When every resource has a clear owner and purpose, unnecessary spending becomes impossible to ignore.

The Takeaway

Clear ownership cuts surprises.
When engineers know what they own, and leaders know what matters, costs stabilize and optimization becomes part of the culture, not a one-time project.

That’s it for this week’s FahmaCloud Newsletter (Edition 12).

• If you found this useful, forward it to someone responsible for AWS spending.
• Have a topic you want covered in a future issue? Just reply, I’d love to hear from you.

Cloud Cost Optimization Isn’t About Turning Things Off. It’s About Engineering Intentional Systems

Many teams still treat cloud savings as a cleanup exercise:
turn off idle instances, delete snapshots, kill unused load balancers.

But here’s the truth:

Real cost optimization doesn’t start at the end of the lifecycle, it starts at the design phase.

Below, we break down what it means to move from reactive savings to intentional engineering.

What’s Happening in Most Organizations

Most teams do cost reviews after the bill goes up. Engineers scramble to:
• Tag resources
• Review budgets
• Check for idle workloads
• Shut down unused services

These are good habits but they don’t solve the underlying problem:

The system was never designed to be cost-efficient in the first place.

That’s why the bill creeps up every quarter, even when teams are “optimizing.”

Why Intentional Engineering Matters for Cost Optimization

Teams that consistently keep costs under control do one thing differently:

They design for cost efficiency before workloads ever go live.

Great engineers understand:
• Usage patterns
• Seasonal demand
• Waste hotspots
• Opportunities for automation
• How architecture decisions impact long-term spend

In other words:

They build systems that stay efficient at scale, not systems that need to be cleaned up later.

This is the difference between reactive and intentional engineering.

Practical Steps to Build a Cost-Efficient Environment

Here are specific ways to move from “cutting waste” to “designing efficiency”:

• Map out usage behavior

Understand when your system spikes, when it idles, and how it grows over time.

• Identify structural waste

Look for patterns of over-provisioning, duplicated workloads, and unnecessary complexity.

• Automate lifecycle actions

Automate scaling, cleanup, and rightsizing, don’t rely on manual cost ops reviews.

• Shift your cost controls into the architecture

Use:
– Serverless for spiky workloads
– Autoscaling for baseline traffic
– Managed services for predictable consumption
– Batch processing for non-urgent tasks

The real win isn’t saving money once.
It’s having an environment that stays efficient without constant intervention.

Leadership Takeaway

Cloud cost optimization isn’t an after-the-fact task.

It’s an engineering discipline.

When teams shift their mindset from “turn things off” to “design intentionally,” they eliminate recurring waste and build systems that scale efficiently, by default.

That’s it for this week’s FahmaCloud Newsletter (Edition 11).

• If you found this useful, forward it to someone responsible for AWS spending.
• Have a topic you want covered in a future issue? Just reply, I’d love to hear from you.

Struggling with an AWS challenge? Need guidance on critical decisions? Or looking for DevOps or Infrastructure expert advice to explore your options and find the best solution? Contact us today and let’s tackle it together.

Any engineer can deploy infrastructure. But true engineering excellence isn’t measured by how many EC2 instances or Kubernetes clusters your team can spin up. It’s measured by how efficiently you can run, scale, and optimize them without compromising performance or reliability.

From good engineer to great team

• A good engineer can deploy 100 EC2 instances.

• A great engineer can reduce spend by 30% while improving stability.

The difference? Intentional design.

Anyone can build in the cloud. Few can design for efficiency, cost visibility, and resilience at scale.

When growth outpaces discipline

Most teams don’t set out to overspend. But as systems grow, so do blind spots.
Without active cost governance, it’s easy for waste to creep in idle volumes, over-provisioned compute, and forgotten services running quietly in the background.

The uncomfortable reality of cloud waste

Many organizations lose thousands of dollars each month simply because no one measures why their AWS bill keeps growing.

Cloud costs aren’t just a finance problem, they’re an engineering leadership problem.

Three areas where great leaders focus

If you want your teams to build smarter, not just faster, focus on these three principles:

1. Design for efficiency, not just uptime
   Encourage teams to question assumptions early. Do we need this service always on? Is this workload right-sized?

   Designing for uptime alone leads to over-provisioning, designing for efficiency ensures long-term scalability.

2. Automate cost visibility
   Cost optimization should not depend on manual reviews. Implement automated cost reporting, anomaly detection, and tagging standards.

   The goal is not micromanagement, it’s empowerment through visibility.

3. Build systems that scale smart, not expensively
   Scalability isn’t about adding more servers. It’s about scaling intelligently through automation, elasticity, and right-sizing. Reward teams for building systems that scale down as efficiently as they scale up.

A leadership perspective on cloud maturity

For technology leaders, cloud optimization isn’t a side project, it’s a core discipline.
It reflects your engineering culture, your architecture maturity, and your ability to balance innovation with fiscal responsibility.

The best teams measure not just what they deploy, but what it costs to keep it running.

That’s what separates good engineering from great engineering.

That’s it for this week’s Fahmacloud Newsletter (Edition 10).

• If you found this useful, like it, share it and bookmark it.

• Have a question or topic you’d like us to cover in a future issue? Hit reply, we’d love to hear from you.

If your teams are using or planning to use Terraform, you’ve probably seen the phrase Learn Terraform in every DevOps roadmap.

But from a leadership perspective, the real question isn’t how to write Terraform code, it’s what concepts your teams must understand to build secure, scalable, and maintainable infrastructure.

Here are our 10 key Terraform concepts every engineering leader should be familiar with.

They’ll help you guide your teams, make informed architectural decisions, and build a culture of infrastructure excellence.

1. Terraform State

Terraform tracks infrastructure using a state file. This file is the single source of truth between the declared configuration and real-world resources.

As a leader, ensure your teams protect, version, and back up this state file properly.

2. Providers and Plugins

Providers are Terraform’s bridge to cloud platforms like AWS, Azure, and GCP. They define which resources your teams can manage.

As a leader, encourage consistency by aligning provider versions across projects.

3. Variables and Locals Variables

They make infrastructure code reusable. Locals simplify logic and reduce duplication. Good variable management means faster onboarding and fewer configuration errors.

4. Modules Modules

They bring structure and reusability to Terraform code. They let teams build infrastructure like Lego blocks: consistent, versioned, and shareable.

As a leader, push for module libraries to enforce standards across environments.

5. Backends and Remote State

Remote backends (like S3, Terraform Cloud, or Azure Blob Storage) allow teams to share state safely. They also enable collaboration, locking, and auditing, all critical for compliance and uptime.

6. Workspaces

Workspaces help manage multiple environments: development, staging, and production, from a single configuration. They reduce duplication and make deployments more predictable.

7. Terraform CLI Commands

Your teams should be fluent in commands like init, plan, apply, and destroy. These commands form the core workflow and help prevent human errors in deployment.

8. Data Sources

Data sources allow Terraform to fetch information dynamically, like existing VPC IDs or AMI versions, instead of hardcoding them. They make infrastructure definitions more adaptive and reduce maintenance overhead.

9. Terraform Registry

The Terraform Registry offers vetted, prebuilt modules and providers that can save hours of engineering time.

As a leader, encourage your teams to use it strategically, but ensure they review code for security and compliance.

10. Best Practices

Terraform best practices include naming conventions, file structure, and version pinning. They keep projects maintainable as teams grow and infrastructure scales. Invest in documenting and enforcing these practices early, it pays off long-term.

Final Takeaway

As an engineering leader, your role isn’t to write Terraform every day, it’s to ensure your teams are using it responsibly.

These ten concepts are a strong foundation for technical conversations, design reviews, and infrastructure strategy.

That’s it for this week’s Fahmacloud Newsletter (Edition 9).

• If you found this useful, forward it to a teammate or peer managing AWS costs.

• Have a question or topic you’d like us to cover in a future issue? Hit reply, we’d love to hear from you.

Which of these areas do you think your team needs to strengthen most right now?

Need a second look to what your team is doing now? Contact Us.

AWS released the Step Functions Metrics Dashboard. Here is what it means from a cost-efficiency perspective.

What’s New

The Step Functions Metrics Dashboard gives you deeper visibility into workflow operations: both at the account and state machine level.

You can now view:

• Usage and billing metrics directly in the Step Functions console

• Metrics for both Standard and Express workflows

• Operational data like ApproximateOpenMapRunCount and other workflow-level stats.

In short, AWS has made it easier to see where your Step Functions costs are coming from without needing to jump into multiple tools or dashboards.

Why It Matters for Cost Optimization

Step Functions are great for orchestrating distributed systems, but costs can add up quickly if you’re not paying attention to workflow behavior.

This dashboard helps identify hidden inefficiencies that quietly increase your bill, such as:

• High retry counts: Often caused by poor error handling or service timeouts.

• Long-running executions: Especially common in Standard workflows when tasks wait on external events.

• Inefficient state transitions: Too many states or unnecessary branching logic can increase execution time and cost.

Having these metrics in one place means you can spot issues early and make data-driven optimizations.

Practical Ways to Use the Dashboard for Cost Control

• Monitor trends weekly: Track how execution counts and durations change over time.

• Identify expensive workflows: Look for state machines with unusual cost spikes.

• Adjust retry logic: Reduce unnecessary retries or add exponential backoff.

• Use Express workflows where possible: They’re often cheaper for short-lived, high-volume use cases.

• Set CloudWatch alarms on metrics like ExecutionsStarted or ExecutionsFailed to catch cost anomalies early.

Small adjustments in workflow design can lead to noticeable savings when you’re running hundreds or thousands of executions daily.

The takeaway

The new Step Functions Metrics Dashboard isn’t just another observability feature, it’s a cost visibility tool.

By surfacing real-time billing and usage data, AWS is giving teams a clearer picture of where their automation dollars are going.

For anyone managing large-scale workflows, this is a step in the right direction toward smarter, more cost-aware operations in the cloud.

That’s it for this week’s Fahmacloud Newsletter (Edition 8).

• If you found this useful, forward it to a teammate or peer managing AWS costs.

• Have a question or topic you’d like us to cover in a future issue? Hit reply, we’d love to hear from you.

You’ve probably seen “Learn CI/CD” on every DevOps roadmap.

But for leadership, the goal isn’t just learning pipelines, it’s building a culture of reliable delivery.
A CI/CD mindset transforms how your teams ship code, collaborate, and respond to change.

Here are 10 core concepts every leader should understand to guide that transformation:

1. Version Control (Git)

Everything starts with Git. A healthy branching and merging strategy makes releases predictable and rollbacks painless. This is the foundation of trust between your dev, QA, and ops teams.

2. Build Automation

Automation removes “it works on my machine” from your vocabulary. When builds are consistent across environments, you gain confidence in every release.

3. Continuous Integration (CI)

CI is about catching issues early, not firefighting later. Frequent commits, automated tests, and fast feedback loops are what keep engineering velocity sustainable.

4. Continuous Delivery vs Deployment

Not every company needs to push to prod on every merge. Delivery means ready to go; deployment means it’s live. Leaders decide which model fits their risk, regulation, and culture.

5. Pipeline as Code

Pipelines aren’t hidden in Jenkins dashboards anymore. Defining them as code (GitHub Actions, GitLab CI, etc.) means visibility, version control, and collaboration, for the entire org.

6. Testing Automation

A robust CI/CD setup tests everything, from units to integration to end-to-end. It’s how you turn every commit into a confidence signal, not a gamble.

7. Artifact Management

Where do your builds live? Repositories like Artifactory, Nexus, or even S3 ensure traceability and repeatability, key for compliance and rollback strategies.

8. Environment Promotion

Clear promotion paths (dev → staging → prod) reduce deployment anxiety. No one should ever have to ask, “Which version is in staging right now?”

9. Secrets Management

If your tokens live in a Git repo, you’re one incident away from disaster. Centralized secrets management (Vault, SSM, etc.) is a non-negotiable investment in trust.

10. Monitoring and Rollback

The pipeline doesn’t end after deployment. Observability, alerting, and rollback procedures make sure you can measure success and recover fast.

Leadership Takeaway

CI/CD isn’t a toolchain. it’s a cultural foundation.

It shapes how your teams think about risk, reliability, and ownership. When done right, it’s not just faster delivery, it’s better delivery.

That’s it for this week’s Fahmacloud Newsletter (Edition 7).

• If you found this useful, forward it to a teammate or peer managing AWS costs.

• Have a question or topic you’d like us to cover in a future issue? Hit reply, we’d love to hear from you.

Struggling with a CI/CD challenge?
Need guidance on critical delivery decisions?
Or looking for expert advice to explore your options and find the best solution?

Let’s talk, book a call and let’s tackle it together.

If your teams rely on Terraform to deploy and manage infrastructure, there’s one thing you can’t afford to overlook: state management.

At first, Terraform’s state file might seem like a small technical detail buried deep in the DevOps pipeline. In reality, it’s the single source of truth that defines your entire infrastructure across environments, teams, and cloud platforms.

When managed correctly, it keeps your deployments consistent, predictable, and auditable. When ignored, it becomes a silent risk to uptime, collaboration, and compliance.

The Business Risk Hidden in the State File

Poorly managed Terraform state can lead to:

• Conflicting infrastructure changes: multiple engineers making updates simultaneously, causing instability.

• Configuration drift: when production no longer matches what’s in version control.

• Deployment delays: locked or corrupted state files blocking critical releases.

• Data exposure: unencrypted local state files leaking sensitive information.

Each of these translates to lost engineering time, unexpected downtime, or audit vulnerabilities all preventable with the right processes in place.

How High-Performing Teams Solve It

Mature DevOps organizations invest early in remote state management.
Instead of storing the Terraform state file locally, they use shared, secure backends that centralize access and maintain integrity.

Recommended setups include:

• AWS S3 + DynamoDB (for remote storage and state locking)

• Azure Blob Storage + CosmosDB

• Terraform Cloud or Terraform Enterprise with built-in access control, versioning, and collaboration

These backends create a single source of truth for infrastructure, aligning perfectly with principles of governance, security, and scalability.

Best Practices for Enterprise Teams

If you’re managing multiple environments (dev, staging, prod), make sure that:

• Each environment has its own state file

• Encryption and access controls are enforced (at rest and in transit)

• State versioning and backups are part of your CI/CD pipeline

• Terraform access is role-based to prevent unintended changes

The Takeaway

Terraform isn’t just an engineer’s tool, it’s part of your operational foundation.
How your organization handles state management says a lot about the maturity of your infrastructure governance and DevOps discipline.

A small oversight in state handling can ripple into costly downtime or compliance issues.
A well-designed backend strategy, on the other hand, boosts reliability, collaboration, and speed-to-market.

If your team is scaling cloud operations or managing infrastructure as code at any meaningful level make Terraform state management part of your executive DevOps conversation.

That’s it for this week’s Fahmacloud Newsletter (Edition 6).

• If you found this useful, forward it to a teammate or peer managing AWS costs.

• Have a question or topic you’d like us to cover in a future issue? Hit reply, we’d love to hear from you.

Recently, we came across a post on Reddit where someone asked:
“How do you prevent runaway serverless costs?”

It’s a great question — and one that hits close to home for many teams managing large-scale AWS environments.

Now, imagine you’re the CTO, and you ask the team to bring solutions to this exact problem. What would they do?

Before jumping into solutions, we want to share a short story from our experience that shaped how we think about cost management and cloud governance.

During one of our projects, we were tasked with solving three key challenges:

• Enable access without overexposure: Allow contractor teams to download logs without granting full access to our AWS accounts.

• Detect failures early: Build a system that alerts the infrastructure team when applications stop sending data to our landing zones.

• Increase cost visibility: Create a daily health report that notifies the governance team about cost increases across services, without requiring them to log into AWS.

Through that experience, we learned that even in mature environments, cloud engineers and operations teams play a critical role in driving efficiency and governance, not just in building new systems.

If you’re starting your AWS journey, don’t stop at tutorials. Look for real-world problems to solve, even if they seem small.

Those challenges teach you how AWS behaves in real situations: how costs grow, how data flows and how governance works behind the scenes.

Because cloud engineering isn’t only about building. It’s also about improving, monitoring, and governing what already exists.

That’s it for this week’s Fahmacloud Newsletter (Edition 6).

• If you found this useful, forward it to a teammate or peer managing AWS costs.

• Have a question or topic you’d like us to cover in a future issue? Hit reply, we’d love to hear from you.

Someone asked this question:
“If I already use AWS Trusted Advisor, why would I need AWS Explorer?”

Here is my take. Both tools help you understand your AWS environment, but they serve different purposes.

AWS Explorer helps you:
- Visualize AWS resources: shows relationships between services and resources
- Map dependencies: see what’s running and how it’s connected

Explorer is great for troubleshooting, inventory management, architecture planning, and onboarding new team members.

AWS Trusted Advisor helps you:
- Get actionable insights: focuses on cost optimization, performance, security, fault tolerance, and service limits
- Use AWS best practices with recommendations like removing unused resources or fixing security gaps

Trusted Advisor is great for cutting costs, improving performance, and staying secure and compliant.

Takeaway:
- Use AWS Explorer for visibility: it maps your environment but doesn’t give advice.
- Use AWS Trusted Advisor for actionable guidance: it helps you optimize and secure your setup.
- Together, they’re powerful: Explorer shows you what you have, Trusted Advisor helps you make it better.

Do you rely on AWS’s built-in tools for cloud cost optimization, or do you prefer third-party solutions?

That’s it for this week’s Fahmacloud Newsletter (Edition 4).

• If you found this useful, forward it to a teammate or peer managing AWS costs.

• Have a question or a topic you’d like covered in a future issue? Hit reply, we’d love to hear from you.

The flexibility of platforms like AWS, Azure, and GCP is great but it also means cloud bills can spiral if left unmanaged.

One of the most effective ways to bring clarity into the discussion is to split cloud spend into two categories:

• Controllable Costs

• Less-Controllable Costs

This simple framework helps teams focus optimization efforts where they’ll have the biggest ROI, while also setting realistic expectations for the areas that are harder to reduce.

1. Controllable Costs

These are the costs your team has direct influence over. They’re the natural starting point for cloud cost optimization because improvements here are measurable and repeatable.

Examples:

• Compute Optimization: Rightsize EC2, RDS, or VM instances to match workload requirements.

• Storage Efficiency: Use S3 lifecycle policies, archive old data, delete unused EBS snapshots.

• Eliminate Waste: Shut down idle instances, release unused Elastic IPs, remove orphaned resources.

• Pricing Models: Adopt Savings Plans, Reserved Instances, or Spot Instances for predictable workloads.

These costs can usually be optimized with better tooling, automation, and processes, and they’re where cost savings show up the fastest.

2. Less-Controllable Costs

I avoid calling these non-controllable, because while they’re harder to influence, they’re not impossible. These costs are often driven by business or vendor constraints.

Examples:

• Business Requirements: Maintaining active/active architectures across regions for compliance or redundancy.

• Vendor Pricing: Some managed services (e.g., API Gateway, managed databases, networking costs) have fixed pricing models.

• Performance SLAs: Running workloads at higher tiers to meet customer expectations.

In these cases, optimization often requires re-architecture, workload migration, or long-term negotiation with vendors. It’s less about shutting something off, and more about strategic decision-making.

Why This Framework Works

By splitting costs into these two categories, teams gain:

• Clarity: Not all costs are equal, and that’s okay.

• Focus: Start with controllable costs, where ROI is clear and quick.

• Alignment: Leadership understands why some costs won’t move as quickly.

Over time, most teams evolve from a pure cost reduction mindset to one focused on predictability and business alignment. This shift ensures cloud spend isn’t just lower, it’s also better connected to company goals.

Practical Steps to Apply This

1. Map Spend to Categories → Run AWS Cost Explorer or Azure/GCP equivalents, and tag spend as controllable or less-controllable.

2. Prioritize Quick Wins → Focus first on waste elimination, rightsizing, and automation.

3. Set Business Context → For less-controllable costs, document the “why” (compliance, performance, vendor). This helps during budget reviews.

4. Revisit Regularly → What’s “less-controllable” today may become “controllable” tomorrow as tech evolves or business needs shift.

The Takeaway

Cloud cost optimization isn’t just about cutting spend—it’s about making smart, aligned decisions.

By breaking cloud spend into controllable vs. less-controllable categories, you empower teams to:

• Capture quick wins

• Communicate better with leadership

• Keep long-term strategy in focus

The result? Costs that are lower, more predictable, and aligned with business outcomes.

In future posts, I’ll share real-world case studies showing how teams applied this framework to save millions while improving agility.

That’s it for this week’s Fahmacloud Newsletter (Edition 3).

- If you found this useful, forward it to a teammate or peer managing AWS costs.
- Have a question or a topic you’d like covered in a future issue? Hit reply, we’d love to hear from you.

This week, we’re focusing on a simple but powerful way to reduce your AWS bill: EBS snapshots. If you’re managing significant amounts of data, storage costs can pile up fast. The good news? With the right snapshot strategy, you can cut costs, protect your data, and simplify backups.

What Are EBS Snapshots?

EBS snapshots are incremental backups of your EBS volumes. They only store changes since the last snapshot, making them highly efficient, cost-effective, and a powerful tool for storage optimization.

Benefits of EBS Snapshots

1. Cost-Effective: Only incremental changes are stored, lowering storage use.

2. Data Protection: Regular backups protect against data loss.

3. Flexibility: Snapshots can be used to create new volumes in any Availability Zone (AZ).

How to Reduce Your AWS Bill with EBS Snapshots

1. Identify Unused Volumes: Delete or detach idle volumes to stop paying for unused storage.

2. Take Regular Snapshots: Automate with AWS Backup or Amazon Data Lifecycle Manager.

3. Optimize Retention: Keep only what you need (e.g., daily for a week, weekly for a month).

4. Use Lifecycle Policies: Move older snapshots to Amazon S3 Glacier for cheaper storage.

5. Monitor Costs: Use AWS Cost Explorer and Budgets to spot savings opportunities.

Example: Automating Snapshots

With Amazon Data Lifecycle Manager, you can:

• Create policies for snapshot schedules (e.g., every 12 hours).

• Define retention rules (e.g., keep 30 snapshots).

• Automate cleanup to avoid cost creep.

The Key Takeaways

• EBS snapshots are a cost-saving strategy, not just backups.

• Automation and lifecycle policies minimize manual work and prevent cost creep.

• Optimized retention ensures you protect data while controlling costs.

• Regular monitoring and analysis of usage can highlight additional savings opportunities.

That’s it for this week’s Fahmacloud Newsletter (Edition 2).

- If you found this useful, forward it to a teammate or peer managing AWS costs.
- Have a question or a topic you’d like covered in a future issue? Hit reply, we’d love to hear from you.

The flexibility of AWS is powerful but it also means you could be paying for resources you don’t need.

The good news? With the right framework, you can take back control. Here’s where to start:

1. Get Visibility Into Your Costs

• Use AWS Cost Explorer to spot top spenders.

• Enable Cost & Usage Reports (CUR) for detail.

• Set budgets and alerts to track in real time.

• Pro Tip: Tag resources by environment, team, or project for easy tracking.

2. Eliminate Waste

• Shut down idle EC2 instances.

• Delete unattached EBS volumes.

• Archive or remove old snapshots.

• Release unused Elastic IPs.

3. Right-Size Your Resources

• Use AWS Compute Optimizer for instance recommendations.

• Downsize oversized RDS databases.

• Leverage auto-scaling groups instead of running 24/7 at peak capacity.

4. Commit to Savings Plans & RIs

• Savings Plans → flexibility across families/regions.

• Reserved Instances (RIs) → best for predictable workloads.

• Start simple with Savings Plans, then layer in RIs for stability.

5. Optimize Storage

• Apply S3 Lifecycle Policies → cheaper storage tiers (Glacier).

• Use S3 Intelligent-Tiering → automated cost savings.

• Switch to gp3 EBS volumes for better performance + lower cost.

6. Automate & Monitor

• Set budgets & alerts.

• Manage with Infrastructure as Code (Terraform, CloudFormation).

• Schedule monthly/quarterly audits.

The Takeaway

AWS cost optimization isn’t a one-and-done project. Start with visibility, eliminate waste, and right-size resources. Then layer in automation to keep costs predictable.

That’s it for this week’s Fahmacloud Newsletter (Edition 1).

- If you found this useful, forward it to a teammate or peer managing AWS costs.
- Have a question or a topic you’d like covered in a future issue? Hit reply, we’d love to hear from you.

Thanks for reading! Subscribe for free to receive new posts and support my work.