Forem: Ikenna Iheanaetu

The Hidden Cost of "Free" AI: The Question Nobody's Asking

Ikenna Iheanaetu — Wed, 20 Aug 2025 07:28:27 +0000

Everyone in tech loves AI right now. ChatGPT, Claude, Copilot we're all using these tools daily, and honestly, they're incredible. But here's something that going on, and I'm surprised more people aren't talking about it:

Why the hell is this stuff free?

I know, I know. It sounds like a dumb question. "Free" tech is great, right? But hear me out, because I think we're missing something huge here.

Nothing Is Ever Actually Free

Look, I've been around tech long enough to know this basic rule: you're either paying directly, or you're paying some other way. There's no magical land where billion-dollar companies just give away their most expensive products out of the goodness of their hearts.

With most "free" tech, we pay through what economists call opportunity cost, basically, what we give up to use it.

Think about it:

Personal computers made us incredibly productive, but how many people under 30 can read an analog clock? We traded that skill for digital convenience.
Smartphones gave us instant everything, but nobody memorizes phone numbers anymore. When was the last time you navigated somewhere without GPS?
Dating apps connected us during the pandemic, but they also fundamentally changed how humans form relationships. And guess what? We became the product being sold.

See the pattern?

The Google Reality Check

Here's my favorite example. Google employs hundreds of thousands of people worldwide. They run massive data centers. They maintain offices in every major city. All so you can... search for free?

Come on.

Google's real business model is simple:

Your attention → billions in advertising revenue
Your data → sold to companies you've never heard of
Your behavior patterns → used for way more than just "improving search"

Gmail isn't free. Search isn't free. YouTube isn't free. You're the product being sold.

So What About AI?

This brings us to the elephant in the room. ChatGPT, Claude, and Gemini represent the most sophisticated technologies ever created. The computational power behind a single ChatGPT conversation costs more than most people's monthly salary. The research that built these systems took decades and billions in investment.

So why are they giving it away?

Meet AMECA (This Blew My Mind)

I stumbled across something recently that connected all the dots. There's a company called Engineered Arts that makes humanoid robots. Their flagship robot, AMECA, is genuinely terrifying and amazing:

It walks and talks naturally
Makes realistic facial expressions
Holds conversations and shows emotions
Responds to situations like a human would

And here's the kicker: AMECA is powered by ChatGPT and similar AI systems.

Suddenly, the "free" AI makes perfect sense.

We're Training Our Own Replacements

Every conversation you have with ChatGPT teaches it human reasoning patterns. Every coding question you ask shows it how developers think. Every debugging session feeds it data about how we solve problems.

We're not just using a helpful tool we're creating the training data for systems designed to replace us.

Think about what you've asked AI lately:

"Help me debug this code"
"Explain this algorithm"
"Write a function that does X"
"Review my code for issues"

Each interaction is a lesson in "how humans approach software development." Multiply that by millions of developers worldwide, and you've got the most comprehensive dataset on human problem-solving ever assembled.

What I'm Seeing in Practice

I've been watching how teams use AI tools, and honestly, it's concerning:

Dependency is growing fast. When ChatGPT was down last month, productivity crashed because people had forgotten how to debug without it.
Core skills are eroding. Developers who used to think through problems step-by-step now immediately reach for AI assistance.
Nobody questions the business model. Everyone just assumes it's a free productivity boost.

The scariest part? Most people don't even realize they're becoming dependent.

The Three Levels of Cost

This "free" AI is actually costing us on multiple levels:

Personal Level

We're losing critical thinking skills, problem-solving creativity, and deep technical knowledge. Why struggle through a complex algorithm when AI can just give you the answer?

Professional Level

If AI can do your job, what's your unique value proposition? We're literally training the systems that will make us redundant.

Societal Level

We're creating a world where human agency is diminished, employment landscapes shift dramatically, and authentic human creativity becomes rare.

The Master Plan (As I See It)

Here's what I think is really happening:

Phase 1 (Now): Give AI away "free" to collect human interaction data on a massive scale
Phase 2 (Soon): Use that data to create sophisticated humanoid robots and automation systems
Phase 3 (Coming): Deploy those systems to replace human workers across industries

We're funding our own replacement through our data and attention.

What We Should Actually Do

I'm not saying don't use AI – it's genuinely helpful. But maybe we should:

Use it consciously, not reflexively. Ask yourself why you're reaching for AI instead of thinking through the problem first.
Maintain your core skills. Don't let AI become a crutch for fundamental development abilities.
Question the business model. When something seems too good to be true, it probably is.
Focus on uniquely human skills – creativity, critical thinking, emotional intelligence, complex problem-solving.

The Question That Keeps Me Up

Are we okay with unknowingly participating in building our own replacement?

Next time you open ChatGPT, just remember: you're not just the customer, you're the product. Your conversations are training data. The "free" period is an investment in collecting human intelligence.

The bill will come due eventually.

And it might be higher than we think.

What do you think? Am I being paranoid, or are we sleepwalking into something we should be more concerned about? Let me know in the comments, I'd love to hear other perspectives on this.

AWS IAM for Beginners: Understanding Roles

Ikenna Iheanaetu — Thu, 17 Apr 2025 18:32:31 +0000

IAM Roles — Another "Who" in the IAM Family

If you check the AWS docs, they say:

“An IAM role is similar to an IAM user in that it is an AWS identity with permission policies that determine what the identity can and cannot do. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.”

Yeah… not exactly clear at first glance.

Let me break it down with an example.

🧵 The Real-World Use Case

Let’s say you want to host an application on EC2, and that app needs to:

Store and retrieve files in S3
Publish logs to CloudWatch

You’ve got a few ways to do this.

❌ Option 1: Use an IAM User

You could:

Create an IAM user
Attach the necessary permissions (S3 and CloudWatch access)
Hardcode the credentials into your application

Or store those credentials somewhere in the EC2 file system and read them at runtime.

Sounds doable, right?

🚨 Don’t do this. It’s a bad idea. Hardcoding credentials is a massive security risk, and storing them locally isn’t any better.

✅ The Right Way: Use an IAM Role

A better approach is to:

Create an IAM role with the exact permissions your app needs (e.g., S3 and CloudWatch access)
Attach that role to the EC2 instance when launching it

AWS will automatically provide your instance with temporary, secure credentials using that role.

No manual keys, no risk of accidental leaks. This is the recommended and secure way to give AWS services access to other AWS services.

🎯 Creating a Role — Step by Step

Go to the IAM dashboard
Select Roles from the sidebar
Click Create role

You’ll be asked to choose a trusted entity type, which just means:

“Who or what will use this role?”

Some options include:

AWS service (e.g., EC2, Lambda)
Another AWS account
Web identity or SAML provider

Once selected:

Attach the required policies (permissions)
Name the role and create it

Done.

🧠 Quick Recap

Users are actual people (with passwords, keys, etc.)
User Groups are collections of users
Roles are assignable identities with temporary credentials, ideal for services like EC2, Lambda, or even federated users

They’re all part of the "who" that can access your AWS resources.

📌 Up Next: IAM Policies

Now that we’ve covered the who, next up is the what — as in, what can they do?

In the next blog post, we’ll dive deep into IAM Policies — how to write them, use them, and avoid common pitfalls.

📚 Missed a post in the series?

Catch up here:

➡️ Understanding IAM Users

➡️ Understanding IAM User Groups

🔔 Follow me for more beginner-friendly AWS and cloud content!

AWS IAM for Beginners: Understanding User Groups

Ikenna Iheanaetu — Sun, 13 Apr 2025 23:36:24 +0000

In the first post of this IAM beginner series, I walked through IAM Users how to create one and why you shouldn’t rely on your root account for daily AWS tasks.

Now, we're building on that foundation with something more scalable and practical: User Groups.

What Are IAM User Groups?

User groups are collections of users that share the same permissions. Instead of assigning permissions one-by-one to each user, you attach a policy to the group, and every user in that group inherits it.

This simplifies access management especially in large teams or fast-growing projects.

How to Create a User Group in AWS

Log in to the AWS console.
Navigate to the IAM service.
On the sidebar under Access Management, click User groups.
Click the Create group button.

Give your group a name, like Admins, Developers, or Testers.
You can optionally add users to the group at this stage.

And you’re done!

Real-World Examples of User Groups

Let’s say you're working on a production application with different teams. Here's how you might use groups:

🛠 Admins: Full control over all AWS resources. Attach policies like AdministratorAccess.
👨‍💻 Developers: Need access to deploy apps using services like EC2, Lambda, and S3, but don’t need full account control.
🧪 Testers: Might need read-only access to logs and certain data buckets to verify app behavior.

By using groups, you avoid assigning policies individually and reduce the risk of misconfiguration.

Why This Matters

This becomes especially useful when onboarding new team members. Instead of manually figuring out permissions every time, just add them to the relevant group, and they’re ready to go.

It also makes offboarding safer—remove someone from a group and they instantly lose access to associated resources.

What’s Next?

Next up, we’ll cover IAM Roles—one of the most misunderstood but powerful parts of IAM.

Here it is Understanding IAM Roles

Roles are what services and other AWS accounts use to assume access without storing long-term credentials.

We'll explore when to use them, how they're different from users, and practical examples for real projects.

Conclusion

User groups are a foundational part of any secure and scalable IAM setup.

They help enforce the principle of least privilege, reduce human error, and make permission management way easier as your cloud usage grows.

Don’t wait until your IAM dashboard is a mess to start organizing users properly. Start now. Start simple.

✍️ If this post helped you, drop a comment or share it with someone new to AWS.

🔗 Catch up on Part 1: IAM Users

🛡️ Part 3 on IAM Roles is coming soon.

aws #iam #cloudsecurity #devops #awscommunity #awstips #infosec #cybersecurity #cloudcomputing #securitybestpractices

Getting Started with AWS IAM: Understanding Users

Ikenna Iheanaetu — Wed, 09 Apr 2025 21:14:26 +0000

When I first started using AWS, I logged in with my root account and built everything from there. It worked—until I needed to collaborate with someone and realized they couldn't access my AWS resources. That’s when I learned about IAM.

A friend recently asked me about IAM because he's new to AWS. I explained what I could, then figured—why not write it down and help more people? This blog is what I wish I had when I started out.

This is part of a beginner-friendly IAM series:

Users ← (this post)
Groups
Roles
Policies
Final: Putting it all together

Let’s start with IAM Users.

What is IAM?

IAM stands for Identity and Access Management. It’s the AWS service that helps you manage:

Authentication: Who can access your AWS resources
Authorization: What actions they can perform

What’s an IAM User?

An IAM user is an identity you create in your AWS account to represent a person or application that interacts with AWS services.

Each user:

Has a name
Can have credentials (passwords, access keys)
Can be given permissions (via policies)

By default, new IAM users have no access to anything. You decide what access they get.

Creating Your First IAM User

Let’s walk through creating an IAM user from the AWS Console.

1. Log in to AWS

2. Go to the IAM Dashboard

From the sidebar, under Access management, click on Users.

3. Click “Create users”

You'll see a button to create a user.

4. Set a username

Enter a name for the user (e.g., test-user).

5. Skip group assignment

IAM groups come next in the series, so skip this step and click Next.

6. Review and create the user

Check your input and click Create user.

After the user is created, click on their name to view their details.

Go to the Security credentials tab.

Enable Console access so the user can log in via the web.

You can:

Let AWS generate a password
Or create your own

Download the credentials file (CSV). It contains the username, password, and login link.

Recap

You’ve just created your first IAM user—a key step toward building more secure and scalable AWS projects. IAM might seem like a small detail at first, but it becomes critical as your infrastructure grows or your team expands.

Start small. Avoid using the root account. Create IAM users with just the right permissions. That’s how you build good habits early.

In the next post, we’ll explore IAM groups—how they help you manage permissions for multiple users at once and make your setup easier to maintain.

If this helped you, consider bookmarking it for later or sharing it with a friend who’s also getting into AWS.

Next in the series

🛠️ IAM Groups – Read part 2

In the next post, we’ll cover:

What groups are
Real examples of group usage

Stay tuned.

My First AWS EC2 Hosting Experience: A Step-by-Step Guide -- Nodejs

Ikenna Iheanaetu — Tue, 18 Feb 2025 01:05:08 +0000

Hey there, fellow developers! I wanted to share my recent experience setting up my first application on AWS EC2. I've been working on becoming an AWS Community Builder, and this project was an important step in that journey. If you're considering using EC2 for hosting, hopefully my experience will help make your process smoother.

What is EC2 and Why I Chose It

Amazon Elastic Compute Cloud (EC2) is basically AWS's virtual server offering. I chose EC2 because I wanted full control over my environment while still leveraging the reliability of AWS infrastructure. Plus, the free tier option was perfect for my initial testing phase.

Let's Get Started

Prerequisites

An AWS account (obviously!)
Basic command line knowledge
A simple application to deploy (I used a Node.js app)
About 30-45 minutes of your time

Step 1: Launching Your EC2 Instance

Log into the AWS Management Console and navigate to EC2
Click on "Launch Instance"
Pick your Amazon Machine Image (AMI) - I went with Amazon Ubuntu Server 24.04 LTS because it's optimized for EC2 and has good support
Choose an instance type - t2.micro is free tier eligible and works well for small apps
Configure your instance details - I kept most settings at default
Add storage - the default 8GB was enough for my app
Add tags - I just tagged it with Name: MyFirstEC2
Configure security group - This is crucial! I created a new security group and:
Allowed SSH (port 22) from my IP address only
Allowed HTTP (port 80) from anywhere
Allowed HTTPS (port 443) from anywhere
Review and launch - This is when AWS prompts you to create a key pair. Download it and keep it safe.

Step 2: Connecting to Your Instance

Wait for your instance to initialize (it'll show "running" status). Then:

# Connect via SSH
ssh -i your-key-file.pem ubuntu@your-instance-public-dns

For the public dns use your public IPV4 address

Step 3: Setting Up Your Server

Once connected, I ran:

# Update and Upgrade linux machine
sudo apt update && sudo apt upgrade

# Install node version manager (nvm) by typing the following at the command line.
sudo su -
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

# Activate nvm by typing the following at the command line.
. ~/.nvm/nvm.sh

# Use nvm to install the latest version of Node.js by typing the following at the command line.
nvm install node

# Test that node and npm are installed and running correctly by typing the following at the terminal:
node -v
npm -v

# To install git, run below commands in the terminal window:
sudo apt-get update -y
sudo apt-get install git -y

# Just to verify if system has git installed or not
git — version

Step 4: Deploying Your Application
I cloned my repo, installed dependencies, and started my app:

git clone https://github.com/your-username/your-repo.git
cd your-repo
npm install
npm run dev

After installing your project dependencies, enter your start script, for me it is npm run dev.

You should also know that once you close your ssh session the app would stop running, for my own project I am using pm2 as my process manager which is setup in the project. If you don't have it setup use the instructions below

# Install PM2
sudo npm install -g pm2

# Start your app with PM2
pm2 start app.js

# Make PM2 restart on server reboot
pm2 startup

Challenges I Faced
For the most part I didn't face any challenges, spinning up an ec2 instance for the first time was relatively easy.

Best Practices I Learned

Security is paramount: Only open the ports you need, restrict SSH access to your IP
Automate everything: Learn basic bash scripting to automate your setup
Monitor your resources: AWS has great monitoring tools - use them!

Next Steps
Next I'll be sharing how to add environment variables to your project and domain configuration.
If you're just starting with AWS, I highly recommend their documentation - it's surprisingly readable and has great examples.
That's it for now! Feel free to comment with any questions or share your own EC2 experiences. I'm still learning and would love to hear your tips too!