Introduction to AWS Cloud + Account Setup + MFA + IAM User Creation

Part of my AWS learning journey — transitioning from Systems Engineer to Cloud/DevOps. This session builds the mental model for everything that follows — what cloud computing is, how AWS is structured, and how to set up an account securely from day one.

---

📋 Topics Covered

---

What is Cloud Computing?

Imagine needing a powerful server to run your application. Normally you'd buy the hardware, install it in your office, hire someone to manage it, and pay electricity bills — even when it's sitting idle at 2 AM.

Cloud computing flips this. You rent compute power, storage, and networking over the internet — use it when you need it, pay only for what you consume, return it when done. No hardware procurement, no data center to manage, no idle servers wasting money.

AWS (Amazon Web Services) is the world's largest cloud platform — offering 200+ services for compute, storage, databases, networking, AI, and more, all accessible over the internet.

The four key characteristics of cloud computing:

---

AWS Certification Roadmap

Understanding where certifications fit helps you plan your learning path. AWS has four levels:

Foundational

• AWS Certified Cloud Practitioner (CLF-C02) — ideal starting point for all roles, validates broad cloud concepts

Associate Level (pick based on your role)

• Solutions Architect Associate (SAA-C03) — most popular, covers designing AWS architectures
• Developer Associate (DVA-C02) — building and deploying applications on AWS
• SysOps Administrator Associate (SOA-C02) — managing and operating AWS systems

Professional Level

• Solutions Architect Professional — advanced architecture and multi-account design
• DevOps Engineer Professional — CI/CD, automation, governance at scale

Specialty

• Security, Networking, Data Analytics, Machine Learning, and more — domain-specific deep dives

🎯 Recommended path for Cloud/DevOps transition: Cloud Practitioner → Solutions Architect Associate → DevOps Engineer Professional. This is the clearest signal to employers that you have both breadth and depth.

---

On-Premise DC vs Cloud DC — Similarities & Comparison

What They Share

Both on-premise data centers and cloud data centers use the same underlying building blocks:

• Compute — physical servers or virtual machines
• Storage — hard drives, SSDs, storage arrays
• Networking — routers, switches, load balancers, firewalls
• Security controls — access management, encryption, monitoring
• Application layers — operating systems, middleware, databases

The difference is not what exists — it's who manages it and how it scales.

Where They Differ

CapEx vs OpEx — the financial shift: On-premise means capital expenditure — a large upfront investment in hardware that depreciates over time. Cloud means operational expenditure — a recurring cost that scales with actual usage. For most businesses, this shift significantly improves cash flow and reduces financial risk.

💡 DevOps relevance: When you propose cloud migration in an organization, this comparison is the business case. Cost reduction, speed, and eliminating maintenance burden are the three arguments that resonate with decision makers.

---

Cloud Hardware & Server Components

AWS owns and operates massive physical data centers around the world. Inside these data centers:

Physical servers — high-density computing hardware running your workloads.

Storage arrays — enterprise-grade disk systems providing durable, high-performance storage (the foundation of EBS, S3, etc.).

Networking equipment — custom-built routers, switches, and fiber-optic cabling connecting everything inside and between data centers.

Virtualization — the technology that lets one physical server run many isolated virtual machines simultaneously. AWS uses its own custom Nitro System — purpose-built hardware and software stack that offloads networking and storage from the host CPU, giving VMs near bare-metal performance.

How one physical server becomes many virtual machines:

One Physical Server (AWS hardware) runs the Nitro hypervisor, which creates isolated EC2 instances. Your EC2 Instance A, your EC2 Instance B, and another customer's instance all run on the same physical hardware — completely isolated from each other. Neither customer can see the other's data or affect the other's performance.

Three compute delivery models built on this:

---

Cloud Service Models — IaaS, PaaS, SaaS

These three models define how much of the infrastructure stack AWS manages versus how much you manage. Think of it as different levels of a restaurant.

IaaS — Infrastructure as a Service

AWS manages: physical hardware, networking, virtualization
You manage: operating system, runtime, application, data

AWS Example: EC2 — you get a virtual machine, you install the OS packages, configure the server, and deploy your application.

Analogy: Renting an empty flat. The building (physical infrastructure) is provided and maintained. You furnish it, decorate it, and maintain everything inside yourself.

DevOps use case: Spin up EC2 instances, configure them with Ansible, deploy with Terraform. Maximum control, maximum responsibility.

---

PaaS — Platform as a Service

AWS manages: hardware, OS, runtime, middleware
You manage: application code and data only

AWS Example: AWS Elastic Beanstalk, AWS RDS — you provide your application or database, AWS handles all the infrastructure and platform configuration underneath.

Analogy: A furnished flat with appliances included. You just bring your belongings (code/data). Maintenance, plumbing, and infrastructure are handled for you.

DevOps use case: Deploy a Python Flask or Node.js application to Elastic Beanstalk. The platform handles auto-scaling, load balancing, and patching.

---

SaaS — Software as a Service

AWS/provider manages: everything
You manage: just using the application

AWS Example: Amazon WorkMail, Amazon Chime
Other Examples: Gmail, Zoom, Slack, Salesforce

Analogy: Staying in a 5-star hotel. You use the facilities (restaurant, gym, room) — someone else manages everything behind the scenes.

DevOps use case: Use SaaS tools like Datadog for monitoring or PagerDuty for alerting — no servers to manage, just configure and use.

---

Service Model Summary

IaaS → Most control, most responsibility on you — closest to traditional on-premise

PaaS → Balanced — you focus on your application, the platform handles infrastructure

SaaS → Least control, least responsibility — fully managed, just use the product

🎯 Cert tip: In the SAA-C03 exam, when a scenario says "the team doesn't want to manage the operating system" → PaaS (RDS, Elastic Beanstalk). "The team needs full OS-level control" → IaaS (EC2). "The team just needs an application to use" → SaaS.

---

Cloud Deployment Models — Public, Hybrid, Private

These define where your infrastructure lives, not what services it uses.

Public Cloud

Everything runs on AWS. No on-premise hardware involved. The application was either built natively in the cloud or migrated from existing infrastructure.

Best for: Startups, new applications, web apps with no compliance restrictions.

AWS example: A startup builds its entire product on EC2, RDS, and S3 from day one.

---

Hybrid Cloud

A mix of cloud and on-premise infrastructure, connected so both sides can communicate. This is the most common model in large enterprises.

Why companies use it: Regulatory requirements may force certain data to stay on-premise (customer financial records, health data), while less sensitive workloads move to the cloud for scalability and cost.

AWS example: A bank keeps customer transaction data on-premise (regulatory compliance) but runs its customer-facing web portal and analytics workloads on AWS. Connected via AWS Direct Connect or VPN.

---

On-Premises (Private Cloud)

Infrastructure deployed entirely within your own data center using virtualization technologies (VMware, OpenStack). Also called private cloud. No external cloud provider involved.

Best for: Government agencies, defense organizations, healthcare — where data cannot leave physical premises under any circumstances.

The trade-off: You get dedicated resources and full physical control, but lose cloud benefits — no automatic scaling, no global reach, high upfront cost.

💡 Interview tip: When asked "what deployment model does your current company use?" — Hybrid is the most common real-world answer for enterprises. Pure public cloud is increasingly common for startups and new products.

---

Benefits of AWS

---

AWS Global Usage & Infrastructure

AWS serves organizations from individual developers to global enterprises — Netflix, Airbnb, NASA, government agencies, hospitals, and millions of startups all run on AWS. It's used across industries: web applications, analytics, data warehousing, machine learning, gaming, financial services, and enterprise software.

The Three Levels of AWS Geography

Region — a geographic area with a cluster of AWS data centers. Currently 33+ Regions worldwide. Each Region is independent — a failure in Mumbai does not affect Singapore. Data stays within a Region unless you explicitly move it.

Availability Zone (AZ) — one or more physical data centers within a Region, each with independent power, cooling, and networking. Each Region has a minimum of 2 AZs, typically 3. Connected via high-speed, low-latency fiber-optic links. Designed to be physically separated enough to survive local disasters.

Edge Location / Point of Presence — cache servers in 400+ cities worldwide. Used by CloudFront (CDN) and Route 53 (DNS) to deliver content close to end users. Not full Regions — no compute or storage, just caching for low-latency delivery.

Why AZs matter:

Single AZ deployment: if that AZ has an outage, your app goes down.

Multi-AZ deployment: if one AZ fails, the other continues serving traffic. This is High Availability — one of the most fundamental cloud architecture concepts.

Global reach benefits:

• Low latency — deploy in the Region closest to your users
• Data residency compliance — keep data within a specific country's borders
• Disaster recovery — replicate to a second Region as a backup

🇮🇳 For India: Use ap-south-1 (Mumbai Region). Lowest latency for Indian users, and data stays within India for compliance.

---

🧪 Lab — AWS Account Setup + Enable MFA

Step 1 — Create Your AWS Account (Free Tier)

Free Tier highlights (12 months for new accounts):

• EC2: 750 hours/month of t2.micro or t3.micro
• S3: 5 GB storage
• Lambda: 1 million requests/month
• RDS: 750 hours/month of db.t2.micro

Setup steps:

1. Go to https://aws.amazon.com → click "Create an AWS Account"
2. Enter your email address and choose a unique account name
3. Create a strong password — this is your Root user password, protect it
4. Enter contact information (personal or business)
5. Add a valid credit/debit card — AWS verifies with a $1 charge (reversed within a few days)
6. Phone OTP verification
7. Select Free tier support plan

⚠️ First action after account creation: Enable MFA on the Root account before doing anything else.

---

Step 2 — Enable MFA on Root Account

Why Root needs MFA immediately:

The Root user has unrestricted access to every resource, every service, every billing detail in your account. If someone steals your Root password, MFA is the only thing standing between them and complete account takeover.

Three MFA types:

Steps to enable:

1. Sign in to AWS Console as Root user
2. Click your account name (top-right) → Security Credentials
3. Scroll to Multi-factor authentication (MFA) → Assign MFA device
4. Enter a device name (e.g., MyPhone)
5. Select Authenticator app → Next
6. Install Google Authenticator or Authy on your phone
7. Scan the QR code shown in the Console
8. Enter two consecutive 6-digit OTP codes from the app
9. Click Add MFA → Done ✅

Recommended apps: Google Authenticator · Authy · Microsoft Authenticator

---

Step 3 — Why Not Use Root for Daily Work

The Root account is like a master key that opens every door in the building. You keep it locked in a safe and only use it for emergencies — not for everyday tasks.

In AWS, the emergencies where you need Root are rare: changing account email, managing billing, certain account-level settings. Everything else should be done via an IAM user.

---

📝 Assignment — Create an IAM User

What is IAM?

IAM (Identity and Access Management) is AWS's access control system. It answers: who can do what on which resource?

When you create an IAM user, that user starts with zero permissions — they can log in but cannot access any service. Permissions are granted by attaching policies.

Key IAM Concepts

Create an IAM User — Steps

1. IAM Console → Users → Create User
2. Enter username (e.g., tejas-admin) — use meaningful names
3. Enable Console access → set a custom password
4. Attach permissions — three common policies:

1. Review → Create User
2. Download the credentials CSV — this is the only time you can download it
3. Test login using the IAM sign-in URL: https://[your-account-id].signin.aws.amazon.com/console
4. Enable MFA on the IAM user too

Three ways to grant IAM permissions:

Method 1 — Direct to user: attach policy directly. Quick but hard to manage at scale.

Method 2 — Via Group: create a group, attach policy to group, add user to group. Best for teams.

Method 3 — Via Role: user assumes a role temporarily to get specific permissions. Best for temporary or cross-service access.

IAM Best Practices

• Never use the Root account for daily tasks
• Always use IAM users or roles for all work
• Apply the Principle of Least Privilege — give only the minimum permissions needed
• Enable MFA on all IAM users, not just Root
• Never share credentials — every person gets their own IAM user
• Download and store the credentials CSV securely — not in Slack, not in email

---

⚡ Quick Revision

Cloud Characteristics
On-Demand · Scalable · Elastic · Pay-as-you-go

Service Models

• IaaS (EC2): you manage OS, runtime, app — AWS manages hardware
• PaaS (Elastic Beanstalk, RDS): you manage app and data — AWS manages everything else
• SaaS (Gmail, WorkMail): you just use the product — provider manages everything

Deployment Models

• Public Cloud: everything on AWS, no on-premise
• Hybrid Cloud: mix of cloud + on-premise (most common in enterprises)
• Private Cloud: entirely on-premise using virtualization

AWS Global Infrastructure

• Region: geographic area, 33+ worldwide, fully isolated
• AZ: data center(s) within a Region, minimum 2 per Region, connected via fiber
• Edge Location: CDN cache in 400+ cities, used by CloudFront and Route 53

AWS Account Security

• Root → lock with MFA, use only for account-level emergencies
• IAM User → for all daily tasks
• Principle of Least Privilege → minimum required permissions, nothing more

IAM Policies

• AdministratorAccess → full control
• PowerUserAccess → all services, no IAM management
• ReadOnlyAccess → view only

Free Tier (12 months)

• EC2: 750 hrs/month (t2.micro)
• S3: 5 GB storage
• Lambda: 1 million requests/month

---

💼 Interview Questions

Q1: What is cloud computing? What are its four key characteristics?
Cloud computing is the delivery of compute, storage, networking, and managed services over the internet on a pay-as-you-go basis. The four key characteristics are On-Demand (instant access), Scalability (grow with demand), Elasticity (auto scale up and down), and Pay-as-you-go (pay only for what you use).

Q2: What is the difference between IaaS, PaaS, and SaaS? Give AWS examples of each.
IaaS (EC2) provides raw infrastructure — you manage the OS, runtime, and application. PaaS (Elastic Beanstalk, RDS) abstracts the infrastructure — you manage only the application and data. SaaS (WorkMail, Gmail) is fully managed — you just use the product. As you move from IaaS to SaaS, you manage less but also control less.

Q3: What is the difference between a Region, an Availability Zone, and an Edge Location?
A Region is a geographic cluster of AWS infrastructure (e.g., Mumbai ap-south-1). An Availability Zone is one or more physically isolated data centers within a Region — each with independent power and networking. An Edge Location is a CDN cache server in a major city, used by CloudFront and Route 53 for low-latency content delivery — not a full Region.

Q4: Why should you never use the Root account for daily AWS tasks?
The Root account has unrestricted access to everything — billing, resource creation, account deletion. If compromised, an attacker has complete control with no recovery path. IAM users with specific, scoped permissions should be used for all daily operations, following the Principle of Least Privilege.

Q5: What is the Principle of Least Privilege?
Granting users and services only the minimum permissions needed to perform their job — nothing more. This limits the blast radius if an account is compromised — an attacker with a developer's credentials can only do what a developer can do, not delete databases or access billing.

Q6: What is MFA and why is it especially important on the Root account?
MFA (Multi-Factor Authentication) requires a second verification factor — an OTP from an authenticator app — in addition to the password. It's especially critical on the Root account because Root has unrestricted access to everything. Even if the password is stolen, an attacker cannot log in without physical access to the MFA device.

Q7: What is the difference between a Public, Hybrid, and Private cloud?
Public cloud means everything runs on a cloud provider like AWS — no on-premise infrastructure. Hybrid cloud connects cloud resources with existing on-premise infrastructure — the most common enterprise model. Private cloud means all resources are deployed on-premise using virtualization, with no external cloud provider involved.

Q8: How would you secure an AWS account from day one?
Enable MFA on Root immediately. Create an IAM user for all daily work. Apply AdministratorAccess only to admin users — use least privilege for others. Set up CloudTrail for audit logging. Enable billing alerts to catch unexpected charges. Never store access keys in code repositories.

---

🔬 Practice Tasks

1. Create an AWS Free Tier account and complete the MFA setup on the Root account using Google Authenticator or Authy.

2. Create an IAM user with AdministratorAccess. Log in as that user. Verify you can access EC2 and S3 consoles. Verify you cannot access billing (Root-only by default).

3. Create an IAM Group called DevOpsTeam. Attach PowerUserAccess to the group. Create a second IAM user and add them to the group. Log in as that user and confirm the permissions.

4. Go to AWS Console → Billing → Free Tier. Review what you've used against the free limits. Set up a billing alert for $5 threshold.

5. Without notes, write the complete list of first actions you'd take when setting up a new AWS account for a production project.

---

AWS Session 1 — Introduction to AWS Cloud | Cloud + DevOps learning journey — Systems Engineer → Cloud/DevOps Engineer