DEV Community: Hennie Francis

My wife and I lost our Apple Walkie-Talkie app, so I'm building my own

Hennie Francis — Tue, 13 Oct 2026 20:38:52 +0000

For years, my wife and I talked through our watches. One tap, one sentence, a quick instant voice connection. Then iOS 27 arrived and Walkie-Talkie was gone. I build software for a living, so I'm doing the obvious thing: building a replacement, and documenting it every step of the way.

Part 1 of my Public Build Series

My favourite app on my Apple Watch was never a fitness tracker or a fancy watch face. It was a simple but effective Walkie Talkie app to chat to my wife when we needed to.

It did one thing really good. You tapped a contact, held a big yellow button, and talked. On the other side, your voice came out of their wrist. No typing, no phone, no waiting for a reply.

iOS 27 and WatchOS 27 released, and I eagerly updated my watch, rookie mistake I know. Few days later, my wife tried to reach me via the Walkie Takie app, and she couldn't reach me, maybe just a bad connection or sometimes it was buggy. The next day, I tried to reach her via the Walkie Takie app, and saw it's no longer there?

Confusion, then shock, then a quick google here, and a claude chat there, only to be discovered it's no longer there. I got to my pc and went on the official site and read through the change logs and discovered it's no longer supported and have been removed.

Why such a small app mattered

The Walkie Talkie app was never about long conversations. It was for the small stuff. "On my way." "Do you want some coffee" or "Food is ready".

Those messages are too small for a phone call and a bit annoying to type on a watch. A quick voice note from your wrist sits right in the middle. It feels more personal than a text, and it takes two seconds. And you can hear your partners voice.

When it disappeared, it wasn't the same. That's usually a good sign that something is worth building.

What I'm attempting to build

The idea is simple: a walkie-talkie app that puts the Apple Watch first. It can use the iPhone too, but the watch is the main hardware.

Think of it as somewhere between Apple's Walkie-Talkie and Zello. Here's how I have it in my mind how I would like it to work: You open the app, pick a contact, and tap Connect. Their watch buzzes, even if the app is closed, and asks them to accept. If they accept, you're connected. Hold the button to talk, let go to listen. If they don't answer, you see "Not available" and that's it.

That's the first version. Voice messages for when the other person is busy, groups, and other extras can come later. I'd rather ship something small that my wife and I use every day than something big that never gets finished.

The catch

I know this would not be a quick weekend project, I have worked on native device tooling before, its never "just a quick thing".

An Apple Watch is built to save battery, so it's strict about what apps can do. A watch app can't sit in the background waiting for someone to talk. It can't keep a live connection open whenever it wants. And Apple's own push-to-talk toolkit only exists on the iPhone, not the watch.

So how do you wake up someone's watch and start talking straight away? The answer is to borrow the way phone calls work. When you tap Connect, the other watch gets a special notification that wakes the app, and the session runs like a call. That's what keeps it alive with the screen off. Some form of alive state.

The trade-off is that the incoming screen will look a bit like a phone call. Not ideal, but I will find something cool I can make it look better. Working within the platform's rules beats fighting them, and those rules shaped this design more than any feature list did.

Why I'm building it in public

I'm going to write about every step: the decisions, the mistakes, what it costs to run, and what I learn along the way. Some of it will work the first time. A lot of it won't. I expect more failures than successes the first time around.

Part of the reason is accountability. If I tell you I'm building it, I have to finish it. The other part is that I couldn't find many projects about building a real Apple Watch app from scratch, so maybe this helps someone else.

It doesn't have a name yet

The app has no name, and I'd love your help to suggest something that we can turn into a real product. And if you used Walkie-Talkie too, tell me what you miss most about it.

In the next part, I'll pick the name, claim it on the App Store, and set up the project. Follow along to see if a two-person walkie-talkie makes it all the way to the App Store.

If you are interested in following the journey, follow me, like this article and share your journey, would love to see what you are building

Kiro: The AI Teammate That Doesn't Break Prod

Hennie Francis — Sun, 11 Oct 2026 10:25:51 +0000

I had the honour of presenting another session at the annual Amazon Web Services (AWS) Summit in Johannesburg, for the fifth time.

This year the AWS Summit Johannesburg moved to the Gallagher Convention Centre in Midrand, not the usual Sandton Convention Centre we’d grown used to over the years. New venue, more floor space, and the same passion shared among the people in the room.

A bit of history first, because five years goes quickly. Last year I spoke twice: Chaos Engineering in the Community Lounge (now better known as the Developer Community Theatre), and MCP on the main stage for customers and partners. Before that I’ve covered Infrastructure as Code, GenAI, and FinOps. Different topics, but the same thread runs through all of them: the gap between what the technology promises and what actually happens when it meets production. This year I wanted to sit squarely in that gap. The topic: how NOT to break production with AI. Specifically, with Kiro.

If you haven’t picked it up yet, Kiro is AWS’s AI-native integrated development environment (IDE), a customised fork of VS Code built for spec-driven, agent-assisted development. It’s genuinely good. And that is exactly the problem. The better these tools get at writing and shipping code, the easier it becomes to let them drive straight into production without the guardrails we would insist on for any human engineer.

My actual problem with AI

Let me start with my real problem with AI. Not the sci-fi, take-over-the-world problem. Something far more specific and far more personal: it keeps breaking code that was working perfectly fine before I asked it for help.

That’s the whole talk in one sentence. You have something that works. You ask for a small change. You get the change, plus three others you never asked for, and now the thing that worked, doesn’t.

The real problem: it’s sure, even when it shouldn’t be

Here’s what makes that dangerous. The AI is so sure of itself, even when it has no business being.

Picture a simple graph. Up the side, how confident the AI sounds. Along the bottom, how much it actually knows. You’d hope the two climb together. They don’t.

What we have today is a dangerous peak. This generation of vibe coders, and every fresh AI agent, sits right at the top of it: maximum confidence, minimum understanding. Meanwhile the senior engineers are all the way down in the valley. Quiet, calm, mildly terrified. Not because they know less, but because they’ve been burned enough times to respect what they don’t know.

Which gives us lesson one, and if you take nothing else home, take this: confidence is not competence. The AI sounds exactly the same whether it’s right or completely wrong. Same tone, same swagger. There’s no wobble in its voice to warn you. You are the warning system.

Why it keeps breaking working code

Underneath all of that sits one root cause. You and the agent never agreed on the boundary. What’s fair game to change, and what has to stay exactly as it is. Nobody drew that line, so the agent drew its own, somewhere you didn’t expect.

Everything else in the talk comes down to drawing that one line.

The fix, in a single sentence

Get it to write the plan before it writes the code.

Almost every mess I’ve made came from doing the opposite. No plan, vibes only, and a diff I had to clean up afterwards. Plan first, and the agent has to show you its thinking before it touches anything that matters.

Don’t ask Kiro for code. Ask it for the plan.

This is where Kiro earns its place. Don’t open with “write me the code.” You’ll get something that looks right and quietly hides every assumption it made to get there.

Ask for the plan first. A plan is something you can argue with before a single line exists. You can poke holes in it, fix the boundary, catch the assumption that would have cost you an afternoon. Then, once you’re happy with it, let it write the code.

Same tool. Completely different outcome. The only thing that changed is the order you did things in.

Key takeaways

If you skipped to the bottom, here’s the whole talk on one slide:

Ask for the plan, not the code. A plan is something you can argue with. A diff is something you have to clean up.
Understand it, test it, then change it. In that order. Never change what you don’t yet understand.
Spec what ships, vibe only what you’d throw away. Spec-driven for anything going to production. Vibe coding is fine for the prototype you’re going to bin.

Teach it your rules once, in steering. Put your standards in Kiro’s steering files so you’re not repeating yourself every prompt.

A gate only counts if it exits 2. A check that always exits 0 can’t fail the build. That’s not a gate, it’s decoration.
It sounds the same when it’s wrong. So you stay the reviewer. Always.

Thank you, and see you next year

The event is only as good as the people in the room, and this year’s crowd was something else. The questions after the session were sharp, and a few of you stuck around to argue about whether your gate actually exits 2. That’s exactly the conversation I wanted.

Thank you to James Hickman for the incredible keynote, and for opening the Partner Summit the previous day. Catching up with you, and experiencing that true customer obsession, the energy, the passion, and the love you have for the brand, was a real highlight. Thank you for being an incredible human, and for always doing it with a smile.

The AWSome community

Huge thanks to the AWS teams, Natalia Stones, Echo Pan, Francesca Sassi, Veliswa Boya, and Olivier Leplus. Working with you on this event has been an incredible experience. Special thanks to you, the customers, the builders, and everyone who came through the talk.

Always so grateful to spend time with the special connections I’ve made over the years: Phyllis Madaba, Thoko Mathenjwa, Rejoice Mucheri, and Henri Zietsman.

To the AWS Community South Africa team and members: you’re the reason I keep showing up to do this.

That’s a wrap on AWS Summit Johannesburg 2026. Same stage, same stakes, same question next year.

See you at Summit 2027. Bring your plans, not just your prompts.

From Buckets to File Systems: Making Amazon S3 Feel Like Home (Without Breaking It)

Hennie Francis — Thu, 09 Apr 2026 09:48:22 +0000

The Reality Behind “Just Put It in S3”
Let’s be honest... S3 is amazing… until it isn’t.

If you’ve spent any time working in cloud environments, you’ve likely heard the phrase: “Let’s just move it to S3.” And to be fair, Amazon S3 is one of the most powerful and widely adopted services in the cloud. It offers virtually unlimited scale, extremely high durability, and a cost model that makes storing massive amounts of data both practical and predictable.

But this is also where things tend to go wrong.

As a Technical Account Manager, I’ve seen this pattern repeat itself across different customers and industries. Teams migrate workloads to S3 expecting it to behave like the file systems they’ve used for years. At first, everything seems fine, but soon enough issues start creeping in. Applications behave unpredictably, scripts fail in subtle ways, performance doesn’t match expectations, and costs begin to climb in ways that are difficult to explain.

None of this happens because S3 is flawed. It happens because it is being used with the wrong assumptions.

Teams want cheap, durable storage

They move to Amazon S3

Then reality hits: “Why can’t I just mount it?” “Why doesn’t ls work properly?” “Why is my app breaking?”

That’s because S3 is not a file system — it’s object storage. And that difference matters more than most teams expect.

The Mental Model Shift (That Everyone Skips)
S3 works fundamentally differently. At its core, S3 is not a file system. It is object storage, and that distinction is not just technical nuance; it fundamentally changes how data is stored, accessed, and managed.

Unlike traditional file systems, S3 does not have real directories, even though it may appear that way in consoles and tooling. What looks like a folder structure is simply a naming convention built on prefixes. There is no native concept of file locking, and it does not follow POSIX standards that many applications rely on implicitly. Even operations that seem simple, such as renaming files or listing directories, behave very differently under the hood.

The challenge is that most applications were not designed with this model in mind. They expect a mounted path, predictable file operations, and consistent low-latency access. When those expectations collide with the reality of object storage, friction is inevitable.

Bridging the Gap Without Changing the Foundation
Enter: S3 as a File System (Finally… Kind Of)
AWS introduced ways to bridge the gap — making S3 behave more like a file system.

Mountpoint for S3 (Cloud-Native Approach)
High-performance access directly to S3

Designed for throughput-heavy workloads

Works well for: ML training Data processing pipelines Batch jobs

S3 File Gateway (Hybrid / Enterprise Friendly)
Uses standard protocols (NFS / SMB)

Adds: Local caching Low-latency access Seamless integration with existing apps

Think of it as:

“Make S3 look like a NAS… but backed by cloud-scale storage”

Both approaches are valuable, but they are not magic solutions. They do not turn S3 into a traditional file system; they simply provide a more familiar interface for interacting with it.

Where Things Still Break
Even with these abstractions in place, certain limitations remain, and this is where many teams get caught off guard.

S3 does not suddenly gain full file system semantics. Operations that depend on strong consistency guarantees, file locking, or rapid metadata changes can still behave differently than expected. Performance is also highly dependent on how the data is accessed. Workloads that involve large, sequential reads tend to perform exceptionally well, while those that rely on frequent, small, random writes often struggle.

Cost is another area where misunderstandings surface. With S3, you are not only paying for storage but also for how you interact with that data. Every request, whether it is a read, write, or list operation, contributes to the overall cost. Inefficient access patterns can quickly turn what seemed like a cost-effective solution into an unexpectedly expensive one.

What Works in Practice
A Strong Fit for Data-Driven Workloads
In practice, S3 shines in scenarios where its strengths align with the workload. Data lakes, analytics platforms, and machine learning pipelines are all excellent examples. These use cases benefit from S3’s scalability, durability, and ability to handle large volumes of data efficiently.

Use Carefully with Traditional Patterns
Challenges start to appear when S3 is used as a direct replacement for traditional shared storage. Applications that expect low-latency file access or rely heavily on small file operations may require additional design considerations or alternative services.

A Better Way to Approach It
The most valuable shift is not technical; it is conceptual.

Instead of asking how to make S3 behave like a file system, it is more effective to ask whether the workload actually needs a file system in the first place. In many cases, what appears to be a requirement is simply a legacy assumption carried over from on-premises environments.

When workloads are redesigned to align with object storage principles, the benefits of S3 become far more apparent. Complexity is reduced, performance improves, and costs become easier to manage. When that redesign is not possible, using the right abstraction layer thoughtfully can still provide a viable path forward.

TL;DR
S3 is object storage — not a file system

New features make it feel like one

Great for throughput-heavy workloads

Dangerous if you treat it like traditional storage

The real skill: choosing the right abstraction for the workload

From Buckets to File Systems: Making Amazon S3 Feel Like Home (Without Breaking It)

Hennie Francis — Thu, 09 Apr 2026 08:20:34 +0000

The Reality Behind “Just Put It in S3”
Let’s be honest... S3 is amazing… until it isn’t.

But this is also where things tend to go wrong.

None of this happens because S3 is flawed. It happens because it is being used with the wrong assumptions.

Teams want cheap, durable storage

They move to Amazon S3

Then reality hits: “Why can’t I just mount it?” “Why doesn’t ls work properly?” “Why is my app breaking?”

That’s because S3 is not a file system — it’s object storage. And that difference matters more than most teams expect.

Bridging the Gap Without Changing the Foundation
Enter: S3 as a File System (Finally… Kind Of)
AWS introduced ways to bridge the gap — making S3 behave more like a file system.

Mountpoint for S3 (Cloud-Native Approach)
High-performance access directly to S3

Designed for throughput-heavy workloads

Works well for: ML training Data processing pipelines Batch jobs

S3 File Gateway (Hybrid / Enterprise Friendly)
Uses standard protocols (NFS / SMB)

Adds: Local caching Low-latency access Seamless integration with existing apps

Think of it as:

“Make S3 look like a NAS… but backed by cloud-scale storage”

Both approaches are valuable, but they are not magic solutions. They do not turn S3 into a traditional file system; they simply provide a more familiar interface for interacting with it.

Where Things Still Break
Even with these abstractions in place, certain limitations remain, and this is where many teams get caught off guard.

A Better Way to Approach It
The most valuable shift is not technical; it is conceptual.

TL;DR
S3 is object storage — not a file system

New features make it feel like one

Great for throughput-heavy workloads

Dangerous if you treat it like traditional storage

The real skill: choosing the right abstraction for the workload

Mastering Cloud Cost Reduction: Architecture, Tools, and Best Practices for FinOps Success

Hennie Francis — Fri, 27 Feb 2026 08:32:26 +0000

Picture your Cloud bill ballooning like a bad balloon animal at a kid's party. Organizations race ahead in digital shifts, craving speed and fresh ideas to crush rivals. But here's the punchline: true wins demand smart tech picks plus tight money smarts. Cut costs by firing up resources only when needed, then automate the whole dance.

Introduction: The Imperative of Cost-Aware Digital Transformation

Teams are moving fast. Cloud makes it easy to spin things up, but it's just as easy to forget to turn them off. And that's where the bill starts climbing. Technology keeps changing, and so does the way we manage cost. You can't just "set and forget" anymore. You need visibility. You need control.

The goal is simple: cut operational costs by automatically starting and stopping resources when they're actually needed. No manual effort. No "who forgot to shut that down?" messages in Slack.

Engineers design lean architectures. Ops teams keep everything running smoothly. Leadership sees the savings show up month after month.

And when it works? Everyone's happy - especially finance.

Chapter 1: Defining Cloud Cost Responsibility and Essential Management Tools

Shared Responsibility for Cloud Financial Management

Cost optimization isn't one team's job. It's not just the C-suite staring at dashboards.
Not just Ops watching utilization.
Not just Finance questioning invoices.
Not just architects designing systems.

It's everyone.

Developers make decisions every day that impact cost - instance sizes, storage choices, retry logic, idle environments. A small change in code can prevent a big bill later. When engineers build efficiently, Ops spends less time firefighting waste. And leadership can focus on growth instead of explaining surprise spend.

Funny thing about the cloud: one forgotten compute instance running all weekend can quietly eat the budget. Multiply that a few times, and there goes the team pizza party.

Overview of Core Cloud Cost Management Services

If you want to control cost, you need visibility. Fast.

No more guessing.
No more "I think it's storage?" conversations.

Here's what actually helps.

Cost Explorer / Cost Analysis Tools: Peek at past spend and usage with clean charts and easy drill-down reports, sliced by service, tag, account, subscription, or that one experimental workload nobody remembers approving.
Budgets and Alerts: Set spending thresholds. Track commitments like Reserved Instances or Savings Plans. Most importantly, get notified before finance does. Email, Slack, SMS - whatever works. The goal is early warning, not post-mortems.
Detailed Cost & Usage Reports: This is the raw stuff. Line items, Credits, Discounts, Refunds… Every tiny charge. Export it to CSV and push it into a data warehouse. Build your own dashboard if you enjoy wrestling with data. This is where the truth lives.
Business Intelligence Dashboards: Feed cost data into your BI tool. Add trends. Add forecasts. Let ML flag "anomalies" - which usually translates to "someone deployed something very large on Friday afternoon." Share it across the organization so conversations are based on numbers, not opinions.

These tools don't magically save money, but they turn fog into facts. And in cloud, the rule is simple: If you don't measure it, it multiplies.

Supported Compute and Database Resources for Automation

Target these bad boys for auto naps.
Compute:

Virtual machines.
Scale sets.
Auto-scaling groups.
Managed Kubernetes worker nodes.

If it can spin up, it can usually spin down. Schedules are your friend. So are policies that say, "Hey, it's Sunday. Chill."

Databases:

Managed relational databases (Postgres, MySQL, SQL Server, the usual suspects).
Cloud-native NoSQL stores.
Managed graph databases.
Globally distributed key-value stores.

If it's provisioned and idling, it's billable. Automation doesn't care which cloud logo is on the console - it cares whether that dev database really needs to exist at 03:00 on a Saturday.

Different cloud providers, same rule. If it's not serving traffic, it should be serving savings. Idle resources shouldn't exist just because nobody remembered them. If it's not handling requests, processing jobs, or delivering value, it should be off. No traffic? No reason to run.

Cloud doesn't care about your logo. It cares about runtime.
Shut 'em down post-bedtime. Wake for work. Bills shrink like a cheap shirt.

Chapter 2: Establishing Resource Lifecycle Control via Infrastructure as Code (IaC)

The Value Proposition of Infrastructure as Code for Consistency

IaC rules the roost. Code your stacks, not clicks. Environments match like twins. Humans goof less - no typos in UIs. Drift dies. No more "why's prod fat?" jokes.

Key Cloud-Native and Cross-Platform Provisioning Methods

Pick your poison (Preferably declarative):

AWS Native: Cloud Formation Stack it up clean. Templates define everything. Push once, Reproduce forever.
Microsoft Native: Azure Resource Manager (ARM) You define your infrastructure in JSON. You declare your resources. You specify dependencies. Then you deploy. It's structured. It's powerful. It's also… very verbose. If you value precision, ARM delivers.
Terraform: Works anywhere. One syntax to rule them all. State file included (guard it with your life).

All of them beat the manual click-ops adventure. Deploy once, version it and sleep better.

Chapter 3: Architectural Patterns for Custom Shutdown/Startup Solutions

Architecture Pattern 1: The Simple Event-Driven Scheduler

Keep it beautifully dumb-simple - my personal favorite.
A scheduled event fires where a tiny function wakes up. It flips the switch: start or stop.

That's it. No orchestration Olympics. No 14-service architecture diagram. Just clean, time-based automation doing its job.

In AWS land, that might be EventBridge cron poking Lambda.
In Azure world, it's a Timer Trigger nudging an Azure Function.
Different names. Same "hey, it's 6PM, go to sleep" energy.

If something fails? A queue grabs it. Retries kick in. An HTTP webhook blasts alerts to wherever your team lives:

Slack for chill vibes.
PagerDuty for "why is my phone screaming at 02:00?"

It's customizable enough to get fancy - but simple enough that you can still explain it on a whiteboard without running out of ink.

Low parts count. Time-based naps. Alerts that don't suck.
Minimal moving pieces with maximum smug satisfaction.

Chef's kiss.

Architecture Pattern 2: Leveraging Native Instance Scheduler

This is where things go from "cute little cron job" to "who designed this spaceship?" The native scheduler setup looks… involved. Because it is.

You've typically got:

A state store (some NoSQL table or config backend) remembering who's allowed to nap and when.
Serverless functions acting like tiny cloud butlers: "Sir, your VM shall now sleep."
Infrastructure templates wiring it all together.
A systems management layer lurking in the background, doing important grown-up things.

First time you see the architecture diagram? You zoom in and out. You question your career choices, but under the hood, this might be:

AWS Instance Scheduler with Lambda, DynamoDB, and SSM doing a coordinated dance.
Azure Automation or Functions with managed identities and tag-driven logic keeping subscriptions in line.

Different cloud. Same vibe: controlled chaos with documentation.

Why engineers secretly love it:

Cross-account / cross-subscription control (because one environment is never enough).
Tag-driven automation: if it's tagged properly, it lives. If not… surprise 24/7 billing.
Centralized schedules so "dev-test-final-final-v3" doesn't run all weekend.
Governance that makes auditors nod approvingly.

Schedules can be defined via CLI, automation runbooks, or policies. Translation: there are at least three ways to misconfigure it.

Senior engineers call it "robust."
Junior engineers call it "complicated."
Finance calls it "finally."

If you know what you're doing? Absolute pro move. If you don't? Start with something simpler before you summon the scheduling boss monster.

Architecture Pattern 3: Advanced Orchestration with Cloud-Native Workflow Engines

Serverless functions chain together in clean flows. One step triggers the next. Decisions happen mid-flight.

All on? Half fleet? Nada because it's a public holiday?

Choice blocks decide. Branches split. Logic gets smart. You can orchestrate like this:

Compute fleet starts Tuesday at dawn.
Databases wake up just before lunch traffic.
Everything shuts down at 17:00 sharp.

Multi-step magic with custom schedules on conditional logic. Retries built in and failures handled without panic. Under the hood, this could be:

A state machine service in AWS.
A workflow engine like Azure Logic Apps or Durable Functions in Microsoft land.

Different consoles. Same pattern: Event → Decision → Action → Control.
Auto-scaling still does its thing. But orchestration? That's boss-level control.

Chapter 4: Adopting Cloud Cost Optimization Best Practices

Foundational Discipline: Tagging and Resource Governance
Tag everything. Now. IDs pop. Classes stick. Stop idle junk - it's bill vampires. "Oops, forgot that test box." Not funny twice.

Resource Sizing and Commitment Strategies
No giant trucks for milk runs. Test sizes right. Sweet spot saves cash. Savings Plans beat long RI locks. Spot Instances? Gold for dev chaos. Non-prod laughs cheapest.

Budget Monitoring and Anomaly Detection
Budgets everywhere - even play pens. Alarms scream early. Weird: post-100%, they hush. Add Anomaly Detection. Quotas cage wild spends. No runaway trains.

Chapter 5: Essential Configuration Tips and Tricks for Ongoing Savings

Infrastructure Deployment and Data Volume Considerations
IaC every time while drift begs for it. EBS alert: sizes grow only but always too small? New disks and cloning mess in a game of data roulette. Never start big.

Intelligent Tiering for Storage Cost Efficiency
Storage Intelligent-Tiering watches access. Move the cold stuff into cheap storage automatically. Since 2018, folks saved billions versus plain S3. Patterns shift? It adapts

Dynamic Scaling and Database Cost Management
Auto Scaling or on-demand flex. DynamoDB? On-demand caps throughput tricks. Match real use. Bills slim.

Conclusion: Key Takeaways for Immediate Cost Action

Costs bind us all - coders lead. IaC locks auto starts-stops tight. Savings Plans and Spots slash non-prod fat. Watch budgets plus anomalies always. Act now: tag, size right, automate. Your wallet cheers. Scan QR for docs - Serverless Land too. Lunch awaits, bills don't. Go save!

Survival Guide: Why You Should Pursue and how to excel in the AWS Cloud Practitioner Exam

Hennie Francis — Fri, 21 Feb 2025 14:59:19 +0000

Background

Whether you’re a student just beginning your career or an experienced professional seeking to expand your skill set, it’s never too late to learn something new. In this post, we’ll explore the AWS Cloud Practitioner Foundational Guide, providing you with a roadmap to get started and offering tips to help you succeed in the exam — no prior coding or technical experience required.

The best part? All of these resources are completely free to use — no cost involved! Free learning is always a win. While there are paid options available, it’s a great idea to start with the free resources to get a feel for the platform. Once you’re ready, you can invest in an AWS Skills Builder subscription to continue progressing on your learning journey.

Why Should You Pursue the AWS Cloud Practitioner Certification?

You might be thinking, “I’m a Business Analyst or a Manager — why should I spend my time learning this? I’ll never use it, and it feels like a waste of time.” Let’s take a different approach and shift your perspective.

From a Manager’s viewpoint, it’s common to not dive too deep into technical details. They focus are often on managing teams, attending countless meetings, handling administrative tasks, and, of course, putting out fires. They are frequently pulled in multiple directions by other teams and stakeholders, each pushing their own issues onto the team. With this in mind, let’s explore why gaining a technical understanding, even at a foundational level, can benefit you and your role.

Perspective Shift

In many meetings or discussions, engineers often throw around technical terms like S3, VPC, Load Balancers, and more. For a manager without technical expertise, this can quickly become overwhelming, leaving them out of the conversation. While a manager doesn’t need to be an expert in every technical aspect, having a basic understanding of key concepts can make a significant difference. For example, knowing that S3 is a cloud storage solution for data — where you can store files like documents, images, and backups — and understanding that it’s an affordable and easy-to-use service, can empower a manager to engage more effectively in discussions and make informed decisions.

Where do I start?

Achieving success involves a few key steps, but before we dive into the advanced stages, it’s important to take things step by step. The first step? Get started by registering for a free AWS Skills Builder account. If you already have an AWS Skills Builder ID, congratulations! You’ve unlocked the first milestone and are ready to begin your journey!

What resources can I use?

The path you take will largely depend on your familiarity with the cloud. If you’re new to the concept — unsure of what the cloud is, its purpose, or why it even exists — there are a few foundational steps you should take before moving forward. To ensure you don’t feel overwhelmed by a flood of information, I recommend starting with the AWS Educate and then moving to the Beginner Resources listed below. These will help you get a solid understanding of the cloud before diving deeper into more complex topics.

If you’re already comfortable with the fundamentals of cloud technology and are familiar with the core concepts, you may not need to go through the Beginner Resources. In that case, feel free to jump straight into the Intermediate Resources, where you’ll find more advanced content to further build your knowledge.

When you feel confident in the knowledge you’ve built and are ready to take the next step toward certification, it’s time to dive into the Advanced Resources. However, before jumping into that, I highly recommend checking out the Bonus Resources. These include hands-on experiences like AWS Cloud Quest and the AWS Escape Room, which offer game-based learning. After all, who wouldn’t want to level up their skills while having some fun?AWS Educate

To bring everything together in one convenient spot, you can use the Learning Paths. These paths bundle most of the key resources, though they don’t include AWS Educate or the Bonus content. Think of the learning path as a single link that directs you to a curated collection of resources.

AWS Educate

Once you complete each course in the AWS Educate program, you’ll earn a Credly badge as a recognition of your achievement.

Beginner Resources

Getting Started with AWS Cloud Essentials

Intermediate Resources

Advance Resources

Exam Prep Standard Course: AWS Certified Cloud Practitioner (CLF-C02)

Bonus Resources

Learning Plans

Next Steps

After completing your AWS Cloud Practitioner exam, the next step in your tech journey can go in many directions. To figure out which path is best for you, check out Learning By Role or Solution by AWS.

The key is to never stop learning — stay curious and keep expanding your technical knowledge and skills.

Once you complete each course in the AWS Skills Builder program, and you wrote and passed your AWS Certification, you'll earn a Credly badge as a recognition of your achievement.