Open Forem: Ibrahim S

SPF, DKIM, and DMARC: The Trust Protocols Protecting Your Domain

Ibrahim S — Fri, 06 Mar 2026 05:21:20 +0000

SPF, DKIM, and DMARC aren’t just DNS records quietly sitting in the background.

They are active trust mechanisms that determine whether your domain is legitimate or easily spoofed.

When an email leaves your domain, these protocols work together to answer one simple question:

Can this message be trusted?

⚙️ SPF — Validating the Sender

Sender Policy Framework (SPF) verifies that the IP address sending the email is authorized by the domain owner.
If the sending server isn’t listed in the domain’s SPF record, the receiving server can flag or reject the message.

🧠 DKIM — Cryptographic Message Integrity

DomainKeys Identified Mail (DKIM) adds a digital signature to the email header.
This signature allows the receiving server to verify that the message content hasn’t been altered in transit and that it genuinely originated from the claimed domain.

📊 DMARC — Policy, Alignment, and Reporting

Domain-based Message Authentication, Reporting & Conformance (DMARC) ties SPF and DKIM together.

It allows domain owners to:

Define what should happen when authentication fails (none, quarantine, reject)
Enforce domain alignment
Receive reports about authentication activity

But here’s the insight that changed how I view DMARC:

DMARC isn’t just enforcement. It’s visibility.

Without DMARC reporting, you have no clear view of who is sending emails using your domain — legitimate services, misconfigured systems, or attackers attempting spoofing.

Why This Matters

Email security isn’t simply about filtering spam.

It’s about protecting your domain reputation at the protocol level.

If SPF, DKIM, and DMARC are misconfigured — or missing — your domain becomes an easy target for phishing and spoofing attacks.

Properly implementing these standards means:

Your emails are trusted
Your domain reputation stays intact
Abuse attempts become visible and actionable

Final Thought

Think of SPF, DKIM, and DMARC as the authentication layer of email trust.

They don't just help receivers decide whether to accept an email —
they help domain owners maintain control over how their identity is used on the internet.

And in today’s threat landscape, that visibility is everything.

🔐 Why SPF, DKIM & DMARC Are Essential for Email Security

Ibrahim S — Wed, 25 Feb 2026 04:38:43 +0000

In 2026, fake emails and domain spoofing are still rampant. Learn why major providers enforce SPF, DKIM, and DMARC and how these three protocols protect your domain, boost deliverability, and build trust.

In today’s digital world, email remains one of the most common attack vectors. Phishing, BEC (Business Email Compromise), and domain spoofing attacks trick people daily damaging trust, stealing credentials, and costing businesses millions.

Major inbox providers like Google, Microsoft (Outlook/365), and Yahoo now strictly enforce email authentication. Without proper setup, your legitimate emails may land in spam — or worse, attackers can impersonate your domain to target your customers.

That’s why SPF, DKIM, and DMARC are non-negotiable in 2026.

👉 Think of them as passport + fingerprint + entry rules for your emails.

✅ What Do They Actually Do? (Simple Breakdown)

📌 SPF (Sender Policy Framework)

✔️ Lists which servers/IPs are officially allowed to send email from your domain

✔️ Stops random servers (or attackers) from forging your @yourcompany.com address

Example record: v=spf1 include:_spf.google.com ~all

📌 DKIM (DomainKeys Identified Mail)

✔️ Adds a cryptographic digital signature to every outgoing email

✔️ Proves the message content hasn’t been tampered with in transit

✔️ Uses public-key cryptography (you publish the public key in DNS)

📌 DMARC (Domain-based Message Authentication, Reporting & Conformance)

✔️ Combines SPF + DKIM results and checks alignment (does the visible From: domain match?)

✔️ Lets you set a policy: none (monitor only), quarantine (spam folder), or reject (block outright)

✔️ Sends you detailed forensic reports about who’s trying to spoof your domain

🔄 The Email Authentication Workflow (Step by Step)

Your server sends an email
Receiving server checks SPF → “Is this server allowed?”
Verifies DKIM signature → “Was this message changed?”
Applies your DMARC policy → “What should we do if it fails alignment?”
Result: Delivered → Spam → Rejected

Only properly authenticated emails reliably reach the inbox.

🚨 Why This Matters More Than Ever (2026 Reality)

Without authentication:

❌ Attackers spoof your domain for phishing campaigns

❌ Your real emails get flagged as spam (especially to Gmail/Outlook)

❌ Brand reputation tanks — customers lose trust

❌ You miss spoofing attempts until damage is done

With SPF + DKIM + DMARC properly set up:

✔️ Dramatically better inbox placement

✔️ Strong protection against exact-domain phishing

✔️ Visibility via DMARC aggregate/forensic reports

✔️ Higher customer trust and domain reputation

Quick analogy everyone gets:

🛡️ SPF = “Who is allowed to speak for me?”

✍️ DKIM = “Here’s my official signature — prove it’s really me”

📋 DMARC = “If they fail the checks → follow my instructions + send me a report”

💡 Real-World Stats (Early 2026)

~71% of domains still have no effective DMARC protection (p=none, invalid, or missing)
Only ~10-11% enforce strict p=reject globally
Fortune 100 companies have dramatically increased p=reject adoption (up ~89% since 2022)
Major providers reject/ quarantine non-compliant bulk email more aggressively every year

🛠️ Quick Start Guide (Developer-Friendly)

SPF
- Identify all services sending on your behalf (Google Workspace, Mailchimp, your app, etc.)
- Create one TXT record: v=spf1 include:_spf.google.com include:sendgrid.net ~all
- Avoid >10 DNS lookups — use include: wisely
DKIM
- Most email providers (Google, Microsoft 365, SendGrid, etc.) generate the key pair for you
- Publish the public key as a TXT record under selector._domainkey.yourdomain.com
DMARC
- Start monitoring: _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"
- After 1–4 weeks of clean reports → move to p=quarantine
- Then (when confident) → p=reject; pct=100
- Add ruf= for forensic failure reports (careful — they contain full message samples)

Common pitfalls to avoid:

Forgetting third-party senders → legitimate mail gets rejected
Jumping straight to p=reject → you block your own mail
Not covering subdomains (use sp= tag or publish separate records)
SPF with too many lookups (>10 = permerror)
Leaving parked/inactive domains unprotected

Final Takeaway

In 2026, SPF + DKIM + DMARC isn’t nice-to-have — it’s table stakes for serious email security and deliverability.

Set them up, monitor the reports, tighten the policy over time.

Your inbox placement, brand trust, and phishing defense will thank you.

Mastering Exchange Online Mail Flow: What Every IT Admin Should Know

Ibrahim S — Sun, 08 Feb 2026 14:36:37 +0000

The email flow (or mail flow), we’re really describing the full path an email takes from the sender’s mail system to the recipient’s mailbox including all the routing decisions, security checks, filtering, and delivery steps along the way.

In Microsoft Exchange Online, that journey typically includes:

DNS & MX routing
The sender’s mail server looks up your domain’s MX record to find where to deliver email.

or Microsoft 365 tenants, this usually points to Exchange Online Protection (EOP), which is the first security and routing gateway.

SPF, DKIM, and DMARC validation
Incoming messages are checked to see whether the sending server is authorized (SPF), the message is cryptographically signed (DKIM), and how to handle failures (DMARC). This helps reduce spoofing and domain abuse.

Mail flow (transport) rules and policies
Mail flow rules can apply disclaimers, block or redirect messages, add headers, or enforce compliance and DLP-style policies based on conditions like sender, recipient, keywords, or attachments.

Connectors and routing configuration
Connectors control how Exchange Online talks to on-premises Exchange, third-party gateways, or partner domains.

Misconfigured connectors are a very common cause of “mysterious” mail flow problems.

Spam, phishing, and malware filtering
Exchange Online Protection (EOP) and Microsoft Defender for Office 365 scan messages for spam, phishing indicators, malware, and harmful URLs or attachments before they reach the mailbox.

Why most “mail flow issues” are not product bugs
In real enterprise environments, most mail flow incidents I’ve seen are not caused by Exchange Online “breaking,” but by:

Incorrect or missing DNS records (MX/SPF/DKIM/DMARC)
Misconfigured connectors or hybrid routing design
Overly aggressive mail flow rules
Custom security devices (secure email gateways, firewalls) changing the path

That’s why understanding the flow end-to-end is so important. When you know the stages, you can narrow down where the issue is happening.

🔍 Pro Tip: Start with headers and message trace
Before you touch any configuration:

Review the message headers

Check the Received hops to see which systems handled the message.

Look at SPF/DKIM/DMARC results and any anti-spam headers.

Identify whether the message actually reached Exchange Online or was altered earlier in the path.

Run a message trace

Confirm if the message was delivered, quarantined, filtered, or bounced.

See which rule, filter, or policy took action and at what time.

These two steps alone often tell you whether the issue is DNS, routing, antispam, or a transport rule, and save you from random trial-and-error configuration changes.

MFA Fatigue Approval: When “Approve” Becomes Your Weakest Link

Ibrahim S — Sat, 07 Feb 2026 15:13:50 +0000

Multi-Factor Authentication (MFA) is now a baseline control in most organizations. We pat ourselves on the back once MFA is enabled for everyone and move on to the next security project.

But attackers haven’t stopped. Instead, they’ve adapted.

One of the most effective techniques they use today is MFA fatigue (also called MFA fatigue approval, push bombing, or MFA spamming). Instead of breaking crypto, they simply annoy your users into approving a malicious sign-in.

In this post, I’ll walk through what MFA fatigue approval is, how the attack works end-to-end, and what you can do as an engineer or security admin to defend against it.

What is MFA fatigue approval?
In many environments, users approve sign-ins through a simple push notification:

“Are you trying to sign in?”
[Approve] [Deny]

MFA fatigue approval happens when an attacker:

Obtains a valid username and password, and
Keeps triggering MFA prompts repeatedly,
Until the user, out of frustration or confusion, finally taps “Approve”.

The underlying authentication protocol still works as designed. The weakness is the user’s decision under pressure.

MFA is still better than passwords alone, but if the user approves anything that pops up on their phone, the effective security is close to zero.

How attackers run MFA fatigue attacks
Let’s break down a typical attack flow.

1. Steal credentials
First, the attacker needs valid credentials. Common sources:

Phishing pages imitating common login portals
Password reuse across multiple sites
Credentials for sale from previous breaches
Infostealer malware that exfiltrates browser-saved passwords

Once they have user@company.com and the password, MFA becomes the only thing standing in their way.

2. Trigger repeated MFA prompts
The attacker starts logging in again and again to the target service:

Each attempt sends a legitimate MFA prompt to the user’s phone or authenticator app.
Some attackers script this to fire prompts in bursts or at random intervals.
Others specifically target late-night hours when the user is tired and less careful.

The goal is not to bypass MFA technically. The goal is to wear down the human.

3. Add social engineering
To increase success, attackers often combine the prompts with social engineering, for example:

Calling the user pretending to be IT support:

We are doing an MFA system test. Please approve the next prompt you see.
Sending a fake “helpdesk” email instructing them to approve a series of prompts.

Now the user is receiving multiple notifications and a “helpful” voice tells them it’s all normal.

The one wrong tap
After enough prompts:
The user is annoyed: “Let me just approve this so it stops.”
Or they are half asleep and assume, “Maybe something is syncing in the background.”
Or they trust the fake IT call and think they’re helping.

They tap Approve once.

That single approval hands the attacker a valid session token, and from that point, it becomes a standard post-compromise scenario.

5. Post-compromise actions
Once inside, attackers can:

Access email and collaboration tools
Search for sensitive data (contracts, credentials, internal docs)
Register their own MFA device for persistence
Elevate privileges, move laterally, and in worst cases, deploy ransomware

All of this started from an MFA-protected account.

Why this technique works so well
MFA fatigue approval is powerful because it attacks human behavior and UX, not the math.

A few reasons it’s so effective:

Notification overload
Users receive many prompts and alerts daily. A few more don’t stand out.

Bad habits
Some users approve out of routine without carefully reading the prompt.

Poor context
Many MFA prompts don’t clearly show location, device, or app. Users approve blindly.

Time pressure & annoyance
Late-night or repeated prompts create stress. People want them to stop.

Imperfect training
Users are told “MFA makes you safe”, but rarely taught “Unexpected prompts = active attack”.

If your environment relies purely on tap approve MFA without guardrails, you are vulnerable to this even if “MFA is enabled for everyone”.

How to detect MFA fatigue attacks
You can’t defend what you can’t see. Typical detection indicators include:

Multiple MFA prompts for one user in a short time window
Example: 15 MFA attempts in 5 minutes.

Many denied requests followed by a single successful approval
Pattern: deny, deny, deny, approve.

Unusual times and locations
Successful approval at unusual hours, or from a location/device that doesn’t match the user’s normal pattern.

Helpdesk tickets about “weird MFA spam”
Users complain they keep getting prompts they didn’t initiate.

If you have access to your identity provider or SIEM logs, building alerts around these patterns is a great starting point.

Technical defenses against MFA fatigue approval
Now, let’s get to the part that matters: what you can actually do.

Replace “Approve/Deny” with number matching or codes
The most impactful change:
Instead of a generic approve/deny push, require the user to
enter a number shown on the login screen, or
enter a verification code from the app.

This forces a tight binding between the login session and the device. An attacker who only has the password and can’t see the login screen can’t guess the number.

It also forces the user to pay more attention: it’s harder to “mindlessly approve” when you have to type something.

2. Enrich MFA prompts with context
Give users enough data to make a good decision:

Where is this request coming from? (City, country)
What is being accessed? (App/resource)
Which device or browser is used?

If a user is sitting in India and sees a prompt from a login in another country at 3 a.m., they should instantly know: this is not me.

3. Limit MFA prompt retries
Don’t let attackers spam your users indefinitely.

Set rate limits on MFA attempts per user per time window.
After several failed or denied attempts, temporarily block further prompts.
Require additional verification or helpdesk interaction if there’s a spike in MFA failures.

This both protects users and gives your security team a signal that something suspicious is happening.

4. Use stronger, phishing-resistant methods where possible
For high-value accounts (admins, finance, executives), consider moving beyond push-based MFA:

FIDO2 security keys / hardware tokens
Platform authenticators tied to specific devices
Certificate-based authentication

These methods remove the “tap approve” surface entirely and are much harder to abuse remotely.

5. Hardening privileged and cloud admin accounts
MFA fatigue against admin accounts is particularly dangerous.

For privileged roles:

Require MFA on every sign-in, no long “remember this device” window.
Restrict admin sign-in to dedicated, hardened devices and locations.
Use just-in-time elevation (PIM-style) so users are not permanently privileged.
Combine Conditional Access-like rules: device compliance, location, risk signals.

Even if an attacker manages one approval, they still have a much harder time escalating.

The human side: training users to say “No”
Technology alone won’t solve MFA fatigue approval. You also need user education.

Key messages for users:

Never approve a prompt you didn’t initiate.
If you’re not currently logging in, treat the prompt as an attack.

Multiple prompts = red flag.
If you get repeated prompts, don’t ignore them—report them immediately.

IT will never ask you to approve random MFA prompts.
Any call, chat, or email asking you to “help test MFA by approving” is suspicious.

A simple rule you can include in internal training:

If you’re not logging in right now and you see an MFA request, always deny it and notify IT.

Final thoughts

MFA is essential, but it’s not magic. If your users are one annoyed tap away from compromise, you haven’t closed the loop.

To reduce the risk of MFA fatigue approval:
Move beyond simple push approvals.
Add context and friction where it matters.
Monitor for suspicious MFA patterns.
Train users to treat unexpected prompts as an active security incident.

Better Microsoft 365 Email Security Through Smarter Configuration

Ibrahim S — Fri, 06 Feb 2026 09:50:34 +0000

Email continues to be the primary attack vector for phishing, malware, and identity-based threats. Many organizations assume that achieving strong email security requires purchasing premium or expensive Microsoft 365 licenses.

The reality? Even cost-effective plans like Business Basic, Business Standard, and Office 365 E1 can deliver solid protection when configured correctly.

🚨 Why Email Security Still Matters

Attackers continue to target email because:

It’s widely used across all organizations
Users remain vulnerable to social engineering
Credential theft often starts with phishing
Email is commonly used for malware delivery

A single compromised account can lead to data breaches, ransomware attacks, and business email compromise (BEC) incidents.

✅ Security Controls You Can Implement Today

🛡️ 1. Enable and Customize Anti-Phishing & Anti-Spam Policies

Microsoft 365 includes built-in protection, but relying only on default settings leaves gaps.

Recommended Actions:

Enable anti-impersonation protection
Protect executive and high-value accounts
Configure spoof intelligence settings
Adjust spam confidence levels based on organizational needs
Enable user safety tips and alerts

Impact:
Reduces spoofing, impersonation, and malicious sender threats.

🔗 2. Configure Safe Links and Safe Attachments (Where Available)

These features provide real-time scanning and protection against malicious URLs and attachments.

Safe Links

Rewrites URLs and scans them when clicked
Protects against delayed or time-based phishing attacks

Safe Attachments

Uses sandbox analysis to inspect attachments
Blocks or quarantines malicious files before delivery

Impact:
Greatly reduces successful phishing and malware infection attempts.

✉️ 3. Properly Implement SPF, DKIM, and DMARC

Email authentication is essential for preventing domain spoofing.

SPF (Sender Policy Framework)

Defines which servers can send emails on behalf of your domain.

DKIM (DomainKeys Identified Mail)

Adds cryptographic signatures verifying message integrity.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

Enforces SPF and DKIM policies and provides reporting visibility.

Impact:

Prevents attackers from spoofing your domain
Improves email deliverability and trust
Provides valuable visibility into email authentication failures

🔒 4. Disable Legacy Authentication

Legacy authentication protocols (POP, IMAP, basic SMTP auth, etc.) do not support modern security controls like MFA.

Recommended Approach:

Disable basic authentication globally
Use Conditional Access policies
Enforce Modern Authentication

Impact:
Significantly reduces credential-based attacks and password spray attempts.

👤 5. Apply Role-Based Access & Least Privilege

Not every administrator requires full global access.

Best Practices:

Assign roles based on job responsibilities
Use Privileged Identity Management (if available)
Regularly review admin role assignments
Remove unused or stale privileged accounts

Impact:
Limits blast radius during account compromise.

🧠 6. Strengthen User Awareness and Reporting

Technology alone cannot stop phishing users remain your first and last line of defense.

Recommended Actions:

Enable “Report Phishing” and “Report Junk” features
Conduct phishing simulation training
Provide ongoing security awareness education
Encourage a security-first culture

Impact:
Faster detection, improved response, and reduced human risk.

💡 Key Takeaway

Strong Microsoft 365 email security is not always about higher licensing. It’s about smarter configuration and continuous improvement.

Organizations that regularly review and optimize their security posture often achieve better protection at lower cost.

🔄 Security Is a Continuous Journey

Threat actors continuously evolve their techniques. Security configurations should be:

Regularly reviewed
Tested through simulations
Updated based on emerging threats
Supported by user education

📌 Final Thoughts

Many businesses overlook the powerful security features already available in their existing Microsoft 365 subscriptions. By focusing on configuration, policy tuning, and user awareness, organizations can build a resilient, cost-effective, and secure email environment.

Read 🔐 Strengthening Email Security in Microsoft 365 Without Upgrading the License Type

Day26: Data Moves. Money Moves ☁️

Ibrahim S — Mon, 12 Jan 2026 13:59:13 +0000

Data transfer pricing in cloud computing is also known as cloud traffic cost when cloud services such as AWS, Azure, or GCP start levying charges to transfer any sort of data from one service to another or to any external network or to the internet in any manner that is in most cases hidden in FinOps traps.

Data transfer pricing is the cost charged for moving data into, within, or out of the cloud.

Types of Charges:

Intra Zone
Inter Zone (same region)
Inter Region
Egress to Internet

Cloud providers categorize this movement into Ingress, Egress, and Within the Cloud.

Ingress → Data comes in (usually free)
Egress → Data goes out (usually paid)
Within cloud → Data moves internally (sometimes paid)

Data transfer pricing, also known as cloud traffic cost, refers to the fee levied by the cloud provider when data is moved between services, within and across regions, and/or outside to the internet.

Such expenses often function as hidden FinOps pitfalls in terms of quietly escalating with utilization.

Day25: Design Smart. Spend Less. Scale Right. Because every cloud decision has a price tag

Ibrahim S — Sun, 11 Jan 2026 07:48:04 +0000

Cost-concerned architecture reviews specifically target the design and evaluation of cloud-based systems in terms of cost, without reducing performance, security, or reliability.

“For cloud computing, all architectural decisions come with a price tag,” says Daniel Kraft, VP of Business Development They enable early detection of unnecessary spending and contribute towards the development of financially sustainable systems.

Right-sizing VMs, containers, serverless sizing computation
Storage tiers & lifecycle policies
The costs of networking --> hosting data transferring, NAT gateways, load balancers
High availability & real business needs
Scaling strategies (auto-scaling vs over-provisioning)

Why it matters
• Prevents cloud cost surprises
• Improves ROI on cloud investments
• Encourages smarter design decisions
• Aligns engineering with business goals

Good cloud architecture isn’t just secure and resilient. It’s cost-conscious by design.

Day24: FinOps Governance Models: Who Decides, Who Pays, Who’s Accountable

Ibrahim S — Sat, 10 Jan 2026 08:23:38 +0000

FinOps governance models define how cloud financial decisions are made, enforced, and shared across an organization.
They help teams control cloud spending without slowing down innovation.

FinOps governance answers who decides, who pays, and who is accountable for cloud costs.

These models define workflows for budgeting, tagging, approvals, and compliance in cloud environments like AWS or Azure.

They prevent cost overruns by enforcing rules such as mandatory resource tagging or spend thresholds, while enabling data-driven decisions through KPIs like utilization rates.

Centralized - Finance owns approvals (regulated orgs)
Decentralized - Teams self-govern (agile startups)
Federated - Central rules + team execution (enterprise sweet spot)

Governance is applied continuously through the FinOps lifecycle:

Inform – Make cloud costs visible
Optimize – Improve efficiency and reduce waste
Operate – Enforce policies and track accountability

FinOps governance models help organizations manage cloud costs through collaboration not control alone.

Day23: Understanding Cloud Budgeting Through the FinOps Lens

Ibrahim S — Fri, 09 Jan 2026 17:11:04 +0000

Cloud budgeting is the practice of planning, tracking, and controlling cloud spending so organizations can get the most value from cloud services without overspending.

Unlike traditional IT budgets, cloud costs are variable, usage-based, and dynamic, which makes budgeting both more powerful and more complex.

Fundamentals:

Visibility
Forecasting
Cost Allocation
Guardrails & Alerts

Most organizations manage cloud budgets using native tools from providers like Amazon Web Services, Microsoft Azure, and Google Cloud, often complemented by FinOps or third-party cost management solutions.

FinOps cloud budgeting is a modern approach to planning, managing, and optimizing cloud spend by bringing finance, engineering, and business teams together with shared ownership of costs.

The FinOps Budgeting Lifecycle

Inform
Optimize
Operate

FinOps cloud budgeting turns unpredictable cloud costs into transparent, controlled, and value-driven spending.

Day22: Cloud Commitments Don’t Save Money — Management Does

Ibrahim S — Thu, 08 Jan 2026 14:47:05 +0000

It’s a Cloud Commitment Management & Optimization framework a management discipline that focuses on long-term cloud resource usage commitment management and optimization to cut costs with minimal risk.

Reserved Instances concepts
Savings Plans / Committed Use Discounts
Commitment planning strategies
Coverage vs utilization
Risk management in commitments
Multi-account commitment sharing
Break-even analysis
Commitment monitoring
Commitment optimization review
Midpoint assessment

Cloud providers give you steep discounts if you agree to use their services. However, there are savings only if these commitments are managed.

It applies to the whole lifecycle of commitments like:

Reserved Instances
It Savings Plans/Committed Use Discounts

Commitment Planning Strategies
Only commit to workloads that run all the time.
Avoid committing for workloads that spike or change often.

Coverage vs Utilization

Coverage: How much of your cloud usage gets a discount

Utilization: How much of what you bought is actually used

👉 Buying discounts you don’t use doesn’t save money.

Risk Management in Commitments

Reduce risk by:

Committing for shorter periods
Committing only part of your usage
Choosing flexible commitment options

Multi-Account Commitment Sharing

Share commitments across teams or accounts so unused capacity in one place can be used in another.

Break-Even Analysis

Know how long it takes before a commitment becomes cheaper than pay-as-you-go pricing.

Commitment Monitoring

Continuously check:
Are commitments being used?
Are any expiring soon?
Has usage changed?

Commitment Optimization Reviews

Regular check-ins to adjust commitments when architecture, traffic, or business needs change.

Midpoint Assessment
A halfway review to fix problems early instead of discovering losses at the end of the term.

Day21: FinOps for Engineers: The Hidden Cloud Costs Lurking in Your Data

Ibrahim S — Wed, 07 Jan 2026 14:52:30 +0000

Cloud cost challenges rarely, if ever, exist in isolation with just computing.They come from data.

Unchecked storage growth, missed snapshots, too much log data, non-optimal data transfer, as well as misconfigured CDNs, contribute to making cloud environments “cost drains” over time.

It is at this point where FinOps and engineering actually overlap.

FinOps is not concerned with finance “policing” spend but rather with engineers understanding how their architecture fundamentally maps to spend, and engineering systems that are inherently efficient.

Here's a breakdown of some of the most underrated cloud pricing drivers, which will focus on the topics of storage, data movement, and observability.

Most engineers believe cloud cost optimization is about:

Right-sizing compute
Shutting Down Unused Instances

This is not the entire truth.

In real-world cloud infrastructures, data-related expenses creep up without one even realizing it.

Here is where cloud engineers specifically factor:

Storage tiers & lifecycle policies
Object storage cost optimization
Block vs file storage tradeoffs
Snapshot & backup cost control
Data transfer pricing
CDN optimization E
gress minimization strategies
Logging & monitoring cost control
Data retention policies
Optimization summary

Storage Tiers & Lifecycle Policies

Object storage offers multiple tiers, but data doesn’t move itself.
Without lifecycle policies, cold data sits in hot storage and you pay for it every month.

Object Storage Cost Optimization

Costs aren’t just about GBs stored.
Request volume, retrieval frequency, and object size matter.

Block vs File Storage Tradeoffs

Block storage is fast but expensive.
File storage scales easily but can become a cost trap.

Snapshots & Backups

Snapshots feel cheap until they’re retained forever.
Cross-region backups amplify the cost.

Data Transfer & Egress

Ingress is usually free.
Egress is not.

Cross-AZ, cross-region, and cross-cloud traffic adds up fast.

CDN Optimization

A CDN can reduce latency and cost but only if caching is configured correctly.

Logging & Monitoring Costs

Logs and metrics can cost more than compute when left unchecked.

Data Retention Policies

Keeping data “just in case” is expensive.
Retention should be intentional and policy-driven.

Day20: Why Storage Isn’t Cheap: Managing Data Growth with FinOps Principles

Ibrahim S — Tue, 06 Jan 2026 14:57:59 +0000

In today’s cloud infrastructure, data is seen to be growing at a rate that outpaces computes – logs, backups, media, analytics data, snapshots, and replicas continue to pile up relentlessly.

Still, though cloud storage is viewed as cheap, poor decisions related to storage and data movement increasingly prove to be among the most costly expenses involved in cloud computing.

Storage tiers & lifecycle policies
Object storage cost optimization
Block vs file storage tradeoffs
Snapshot & backup cost control
Data transfer pricing
CDN optimization
Egress minimization strategies
Logging & monitoring cost control
Data retention policies
Optimization summary

1. Storage tiers & lifecycle policies

Storage tiers are different price/performance levels for storing data (hot, warm, cold, archive). Lifecycle policies automatically move data between tiers over time.

Hot tier → frequent access, low latency, highest cost
Warm / Cool → infrequent access
Cold / Archive → rarely accessed, very cheap, slow retrieval

Automate lifecycle rules (e.g., 30 days hot → 90 days cool → archive)
Avoid human decision-making for data aging
Prevent “forgotten data” bills

Logs: Hot for 7–14 days, then archive

Backups: Hot for recent, cold for long-term compliance

2. Object storage cost optimization

Object storage stores data as objects (files + metadata) in flat namespaces.
Choose correct tier (Standard vs Infrequent Access vs Archive)

Compress data before upload
Use lifecycle + delete markers cleanup
Avoid small-object explosion (bundle small files)

Cost per GB-month is low, but scale makes it expensive
Storage grows silently → requires governance

3. Block vs file storage tradeoffs

Block storage → raw disk volumes (VM disks, databases)
File storage → shared filesystem (NFS, SMB)

Block → performance & low latency
File → shared access
Cost reality
Block storage is expensive at scale
File storage costs grow with:
Provisioned capacity
Throughput
IOPS

Don’t store logs or backups on block storage
Right-size volumes (over-provisioning is common)
Monitor IOPS vs provisioned limits

4. Snapshot & backup cost control

Snapshots are point-in-time copies; backups are long-term protection.

Disaster recovery, rollback, compliance.
Hidden cost drivers
Snapshots accumulate
Incremental chains grow forever
Cross-region backups add transfer costs

Snapshot retention limits (e.g., 7–14 days)
Delete orphaned snapshots
Separate “backup” from “snapshot” strategy

“If you don’t test restore, you’re just paying for storage.”

5. Data transfer pricing

Cost for moving data
Ingress (usually free)
Egress (almost always expensive)
Inter-region / inter-zone traffic

Microservices, multi-region apps, DR, analytics.
Cost traps
Cross-AZ traffic inside clusters
Region-to-region replication
Data pulled out to the internet

6. CDN optimization

Content Delivery Network caches data closer to users.

Lower latency
Reduced origin load
Lower egress costs
Optimization techniques
Correct cache-control headers
Longer TTLs for static assets
Avoid cache-busting unnecessarily

CDN cost < origin egress cost
Performance + savings = rare double win

7. Egress minimization strategies

Reducing data leaving your cloud.

Keep compute close to data
Use same-region services
Process data before exporting
Compress responses

Design for data gravity
Move logic to data, not data to logic
Egress is a tax on bad architecture

8. Logging & monitoring cost control

Telemetry data: logs, metrics, traces.

Observability, debugging, reliability.

Cost problems
High-cardinality logs
Debug-level logs in prod
Long retention by default
Smart controls
Log sampling
Tiered retention (hot vs archive)
Drop noisy logs at source

“Logs are data exhaust treat them like waste unless proven valuable.”

9. Data retention policies

Rules defining how long data is kept.

Compliance
Risk reduction
Cost control

Legal vs operational retention split
Default delete unless justified
Periodic audits of retained data

Cloud storage and data costs rarely spike overnightthey accumulate quietly through architectural defaults, missing guardrails, and unmanaged growth.

While individual GB costs may appear negligible, scale, retention, replication, and data movement amplify waste over time.

Effective optimization is not about aggressive deletion or compromising reliability.

Instead, it is about intentional data placement, automated lifecycle management, and cost-aware design choices embedded directly into engineering workflows.