DEV Community: Soham

How I Started Learning Microsoft Azure for Free (A Complete Guide for Students)

Soham — Sun, 12 Jul 2026 04:34:10 +0000

Cloud computing has become one of the most valuable skills for students and developers. Whether you're interested in Software Development, AI, Machine Learning, Data Engineering, DevOps, or Cybersecurity, understanding cloud platforms can open many career opportunities.

Recently, I started expanding my cloud skills beyond a single platform. Learning multiple cloud providers like AWS, Microsoft Azure, and Google Cloud Platform helps you understand different services, architectures, and deployment methods. It also prepares you for real-world projects where organizations often use more than one cloud provider.

While exploring Azure, I discovered that Microsoft provides an excellent opportunity for students through Azure for Students. If you're eligible, you can get free Azure credits to learn, experiment, and build projects without paying anything.

In this article, I'll explain:

What Azure for Students is
How to claim your free Azure credits
What you can build using Azure
The difference between Azure for Students and Azure Free Account

Let's get started.

What is Azure for Students?

Azure for Students is a Microsoft program created specifically for university students.

Instead of asking for a credit card, Microsoft verifies your student status using your college or university email address. Once you're verified, you receive Azure credits that you can use to explore Azure services.

Benefits of Azure for Students

✅ No credit card required
💰 USD 100 promotional Azure credit
☁️ Access to the complete Azure service catalog within free limits
📦 Free monthly amounts of 20+ popular Azure services for 12 months (new Azure customers)
🚀 Free monthly amounts of 65+ always-free Azure services
🤖 Access to modern Azure technologies, including Azure AI services available under your subscription
🔄 Renew your subscription every year as long as you're an eligible student

For students who want to gain practical cloud experience, this is one of the best ways to get started.

How to Claim Azure for Students

The registration process is simple and usually takes only a few minutes.

Step 1

If you don't already have one, create a free Microsoft account.

Step 2

Open the Azure for Students page using the following link:

👉 https://azure.microsoft.com/free/students/?wt.mc_id=studentamb_519741

Step 3

Click the Start Free button.

Step 4

Verify your student status using your official college or university email address.

Microsoft will automatically verify your eligibility.

Step 5

After successful verification, your Azure for Students subscription will be activated.

You can immediately begin creating Azure resources using your promotional credit.

What Can You Build Using Azure?

The free credits are more than enough to explore many Azure services while learning cloud computing.

Some project ideas include:

Personal portfolio website
Static websites
REST APIs
AI chatbots
Machine Learning projects
Virtual Machines
Azure Blob Storage
Azure SQL Database
Serverless applications with Azure Functions
Docker container deployments
IoT applications
Data Engineering projects

If you're preparing for Microsoft Azure certifications, these credits are also perfect for hands-on practice.

Azure for Students vs Azure Free Account

Microsoft also offers a standard Azure Free Account for anyone who wants to explore Azure.

Here are the key differences.

Feature	Azure for Students	Azure Free Account
Credit Card Required	❌ No	✅ Yes
Promotional Credit	USD 100	USD 200
Available For	Students	Everyone
Annual Renewal	✅ Yes (while eligible)	❌ No
Free Services	20+ for 12 months + 65+ always free	20+ for 12 months + 65+ always free

Azure Free Account

If you're not eligible for Azure for Students, you can still start with an Azure Free Account.

It includes:

💰 USD 200 Azure credit for the first 30 days
📦 Free monthly amounts of 20+ Azure services for 12 months (new Azure customers)
🚀 More than 65 services that are always free within their limits
🛡 Spending protection so your credit card won't be charged automatically
❌ Cancel anytime

You can explore it here:

👉 https://azure.microsoft.com/free/?wt.mc_id=studentamb_519741

Why Every Student Should Learn Azure

Cloud computing is no longer limited to large companies.

Today, startups, enterprises, government organizations, and research institutions all rely heavily on cloud platforms.

Learning Azure can help you:

Build real-world projects
Prepare for cloud certifications
Understand cloud architecture
Deploy applications
Learn DevOps practices
Explore Artificial Intelligence services
Work with databases and storage
Practice serverless computing

Even basic Azure experience makes your resume stronger and gives you confidence while building projects.

My Thoughts

As I continue learning cloud technologies, one lesson has become very clear.

Don't limit yourself to learning just one cloud platform.

AWS, Microsoft Azure, and Google Cloud Platform each have unique services and different ways of solving problems. Learning multiple cloud platforms gives you broader knowledge and prepares you for more career opportunities.

If you're currently a university student, I highly recommend claiming your Azure for Students subscription and exploring the platform through hands-on projects.

The best way to learn cloud computing is by building something yourself.

Happy Learning! ☁️🚀

If you've already started learning Azure or have built a project using Azure services, I'd love to hear about your experience in the comments.

[Boost]

Soham — Fri, 21 Nov 2025 09:34:52 +0000

When One Config File Shook the Edge: Lessons from the Cloudflare Outage

Soham ・ Nov 21

#cloudflare #devops #performance #architecture

When One Config File Shook the Edge: Lessons from the Cloudflare Outage

Soham — Fri, 21 Nov 2025 09:34:15 +0000

At 11:20 UTC on an otherwise ordinary Tuesday, nothing obvious exploded.
No data center fires, no submarine cables sliced, no headline‑worthy cyberattack.
Yet, from Mumbai to New York, your feed wouldn’t refresh, your AI assistant stared back in silence, your dashboards froze, and half the tools you rely on at work simply refused to load.

What actually “broke” the internet for millions of people wasn’t a dramatic external assault.
It was a quiet, invisible change deep inside Cloudflare’s infrastructure—a misbehaving database query and an oversized configuration file—that rippled outward until a sizable slice of the public web started returning 5xx errors.

This is the story of how a single config artifact at the edge became a global failure point—and what that means for anyone building on today’s cloud and CDN stack.

The Day the Edge Flinched
On 18 November 2025, Cloudflare experienced a major incident that disrupted HTTP and API traffic for thousands of sites and services that depend on its network.
Core routing and connectivity remained largely fine, but the application layer at the edge—the place where Cloudflare terminates TLS, enforces security rules, and proxies requests—began failing.

To users, the symptoms were simple and brutal:

Pages that wouldn’t load, ending in generic “5xx” or “bad gateway” messages.
Apps that opened but couldn’t log in, fetch data, or complete payments.
Services that looked alive on status pages but felt dead in the browser.

For roughly three hours, a critical slice of the internet behaved as if it had hit an invisible wall.

One File, Many Failures
The root of the problem was not some exotic new bug.
It was a classic combination of automation, assumptions, and scale.

Cloudflare’s Bot Management system relies on a “feature configuration file” generated from data in a ClickHouse database.
Every few minutes, this file is built and pushed out across Cloudflare’s global edge fleet, telling the proxy layer how to distinguish real users from bots using a variety of signals.

Then a seemingly safe internal change landed:

Database permissions and behavior around queries feeding this file were updated.
The query started returning duplicate entries and more data than expected.
The resulting feature file quietly grew far beyond its normal size.

On its own, a bigger file doesn’t sound catastrophic.
But the proxy software consuming it had hard limits—limits tuned around “typical” size and shape.
Once the file crossed that threshold, processes started failing.
Those failures turned into 5xx errors.
And because Cloudflare’s edge is everywhere, the blast radius was, too.

This is the uncomfortable truth: nothing “mystical” happened.
A config artifact got larger than the code was prepared to handle, and at Cloudflare’s scale, that’s enough to look like a global outage.

Not an Attack, but Just as Disruptive
In the first half‑hour, the incident pattern looked suspicious: spikes in errors, intermittent availability, different regions experiencing issues in waves.
It would have been reasonable to suspect a large DDoS or some novel external assault.

But as Cloudflare’s teams dug in, a different story emerged:

No credible signs of a coordinated attack.
Clear correlation between the rollout of new bot‑feature data and the onset of failures.
Consistent recovery once the bad configuration was rolled back and the pipeline corrected.

That distinction matters.
Defending against adversaries is one problem.
Defending against your own automation and assumptions is another—and increasingly, just as important.

How Big Was the Blast Radius?
“Cloudflare is down” is only the surface‑level summary.
Underneath that, the outage exposed how much of the modern internet quietly depends on a few shared edges.

During the incident, users reported issues with:

Social and communication platforms like X (Twitter), Discord, and parts of other major networks.
AI services such as ChatGPT, Claude, and other LLM‑backed tools that run behind Cloudflare.
Streaming, collaboration, commerce, and content platforms like Spotify, Canva, Shopify and others.
Banking, payment, and enterprise portals that rely on Cloudflare for security and performance.

In many cases, sites weren’t “fully down.”
You might get the HTML shell, but static assets wouldn’t load, JS errors would cascade, or critical API calls would fail.
That partial failure made the situation feel chaotic and random, even though the underlying cause was centralized.

Ironically, outage‑tracking and status sites that depended on Cloudflare also struggled, so even the tools people use to understand what’s broken were themselves degraded.

A Concentration Risk Story in CDN Clothing
The AWS US‑EAST‑1 incidents showed what happens when too much logic is concentrated in a single region.
The Cloudflare outage shows what happens when too much of the world’s public surface area is concentrated behind a single edge.

Cloudflare sits in front of a massive portion of global web traffic, acting as:

CDN and performance layer
DDoS shield and WAF
Reverse proxy and TLS terminator
Sometimes even identity and zero‑trust front door

This consolidation is powerful.
It lets small teams tap into world‑class performance and security with a few DNS changes and some configuration.
But it also means that:

A single misbehaving configuration pipeline can affect thousands of independent businesses at once.
An internal limit breached in one piece of software can look, from the outside, like “the internet is broken.”
Even multi‑region, highly resilient backends are effectively unreachable if their only public face is through one provider’s edge.

The Cloudflare incident is therefore less about one company’s bad day and more about an architectural pattern that keeps repeating: convenience and centralization up front, with concentration risk hiding in the background.

What Cloudflare Is Doing Next
To its credit, Cloudflare has approached this outage with transparency and a willingness to name the uncomfortable parts.
From public statements and post‑incident analysis, the themes are clear:

Hardening the config pipeline Enforcing stricter validation, size limits, and sanity checks on automatically generated files before they ever hit production proxies.
Tightening database controls Treating permission and query‑shape changes feeding security and routing configs as high‑risk, high‑scrutiny operations.
Improving observability and early warning Instrumenting feature file generation and distribution so anomalies are caught in minutes, not after a global fleet has consumed them.
Owning the impact Publicly acknowledging that this was a self‑inflicted failure, not an attack, and that customers paid the price for assumptions baked into Cloudflare’s own systems.

These are all the right moves—but they’re also reminders that no provider, no matter how sophisticated, is immune to latent bugs colliding with scale.

Lessons for Builders and DevOps Teams
Just like the AWS outage reframed how teams think about region design, the Cloudflare incident should reframe how we think about edges and third‑party dependencies.

Here are some concrete questions to ask of your own architecture:

1. What happens if your edge provider becomes your bottleneck?
If Cloudflare (or any CDN/WAF) starts returning errors, do you:

Fail closed and go fully dark?
Fail open and accept more risk but keep some traffic flowing?
Have a designed, testable degradation mode?

2. Can you bypass or switch edges in an emergency?
Multi‑CDN is complex, but a “break glass” approach—e.g., alternative DNS configuration, a simplified static origin, or a secondary CDN for critical paths—can mean the difference between total downtime and partial service.

3. Do you understand your real dependency graph?
Document which parts of your system depend on:

A specific CDN or WAF
A single DNS provider
A single identity / auth solution
One AI, payments, or messaging vendor

Then challenge that map: where could a single vendor outage take out an entire user journey?

4. Are you only testing for the failures you find “intuitive”?
Many chaos and resilience tests model VM loss, AZ loss, or even full region loss.
Fewer test for:

Corrupted or oversized config files
Mis‑shapen responses from internal services
Unexpected but valid‑looking data that exceeds a limit deep in the stack

The Cloudflare outage is a textbook example of why those tests matter.

Resilience in the Age of Shared Edges
In 2025, building “highly available” systems is no longer just about redundant instances and multiple zones.
It’s about accepting that your architecture is now braided with the architectures of your providers.

A database permission change at Cloudflare should not be able to take your business completely offline.
But for many teams, on November 18, it did.

The goal going forward isn’t to avoid using Cloudflare, AWS, or any other major platform; that’s neither realistic nor desirable.
The goal is to stop treating them as infallible constants and start treating them like what they are: powerful, failure‑prone components in your own system design.
The next time an edge provider stumbles, the question won’t be “Why did they fail?”
They will fail.
The real question is:

will your architecture be ready to bend—or will it snap right along with them?

The Day the Internet Froze: A 15-Hour Wake-Up Call

Soham — Wed, 22 Oct 2025 17:50:35 +0000

On October 20, 2025, millions of users globally found their digital lives at a standstill. Snapchat, Fortnite, Roblox, Venmo, and even major banking and airline services suddenly stopped working. This wasn't a series of isolated incidents; it was a systemic failure originating from a single point: the AWS US-EAST-1 region in Northern Virginia.
For 15 hours, the internet experienced a cascading failure that provided a stark, real-world lesson on the immense role cloud infrastructure plays and the profound risks of architectural concentration.

How a Single DNS Issue Triggered a Global Cascade
The outage began with a seemingly routine technical fault: a DNS resolution issue for the regional DynamoDB service endpoint. Because US-EAST-1 is the oldest and one of the most critical hubs in the global cloud, its services are deeply interconnected.
This single DNS problem didn't stay contained. It set off a chain reaction:

DynamoDB Fails: The initial DNS issue made this core database service unreachable for other services within the region.
EC2 Subsystem Impaired: The internal subsystem responsible for launching new EC2 instances, which depends on DynamoDB, began to fail.
Load Balancers Falter: This impairment then caused Network Load Balancer health checks to fail.
The Internet Stops: With load balancers and EC2—the engine and the traffic cops of the cloud—impaired, everything built on top of them collapsed. Services like Lambda, SQS, and CloudWatch went down, taking thousands of customer applications with them. In the end, over 140 AWS services were impacted, all stemming from one initial fault in one region.

The Real Vulnerability: Single-Region Concentration
This event wasn't just a technical failure; it was an architectural one. It exposed a critical vulnerability shared by many of the world's largest tech companies: over-reliance on a single cloud region.
AWS infrastructure is the backbone of the modern internet, holding over 30% of the cloud market. Its US-EAST-1 region is the default for many services and often hosts the control planes for global services like IAM.
When companies build their critical applications, even massive ones, to run entirely within this single region, they create a single point of failure. They are, in effect, building a global business on a single foundation. While multi-zone deployment within that region offers some protection, it doesn't help when the region's core services (like DNS, IAM, or core database endpoints) are impacted at a regional level.
The 15-hour disruption was a painful demonstration of this "concentration risk." Companies that lacked a multi-region strategy had no failover. They were completely offline, forced to wait for the primary region to be restored.

Key Insights for Builders
The October 20th outage is a powerful reminder that "resilience" is not just a feature to be purchased; it's an architecture that must be actively designed.

Multi-Region is Non-Negotiable: For critical, global-scale applications, a multi-region, active-active or active-passive architecture is essential for high availability.
Understand Service Dependencies: This outage showed that a failure in a "foundational" service like DynamoDB can have an outsized blast radius. Builders must map and understand these dependencies.
Avoid the "Default" Trap: The convenience of using the default region (US-EAST-1) for everything can introduce unacceptable risk.

Ultimately, the cloud provides the tools for incredible resilience. But as this 15-hour global outage proved, those tools are only effective if we use them to build for failure, not just for convenience.