Amazon Web Services Fundamentals

Amazon Web Services, or AWS, is a cloud platform. It provides infrastructure and managed services through APIs. You use those services to run applications, store data, connect networks, process events, manage identities, and observe systems.

The useful mental model is not a shopping catalog of service names. AWS is an operating environment with boundaries. An AWS account owns resources and receives charges. A Region places most resources in a geographic area. An Availability Zone is an isolated location inside a Region. An identity makes an API request. A policy decides whether that request is allowed.

This course gives you that map. It does not make you an expert in every AWS service. It helps you ask the right questions before you create the first resource.

What AWS changes

With AWS, you can provision resources through the Management Console, command line tools, SDKs, and service APIs. That speed is useful, but it removes the natural pause that a procurement process once imposed. A small experiment can become an exposed endpoint, a privileged identity, or a recurring charge very quickly.

AWS also shifts some operational work to the service provider. The amount depends on the service. A virtual machine leaves you responsible for its guest operating system and application. A managed database removes more infrastructure work, but you still own access, data handling, configuration choices, and the behavior of your application.

The shared responsibility model is the frame for this division. AWS secures the infrastructure that runs AWS services. You secure your use of those services. There is no service choice that removes the need to understand who can access data, how a workload is configured, or how changes are recorded.

The core boundaries

Account

An AWS account is a primary boundary for resource ownership, permissions, billing, and workloads. One account is enough for an early experiment. As systems and teams grow, separate accounts make it easier to isolate workloads, apply governance, and see costs.

AWS Organizations centrally manages multiple accounts. It groups accounts into organizational units, applies organization policies, and provides consolidated billing. An organization is not a replacement for service-level permissions. It adds another layer of governance around accounts.

Region and Availability Zone

A Region is a separate geographic area. Most AWS resources are regional, so you create and manage them in a selected Region. Choose a Region based on service availability, user latency, legal or regulatory requirements, and the recovery design that the workload needs.

An Availability Zone is an isolated location within a Region. Some resources are zonal. A workload placed in one Availability Zone can fail with that Zone. When a workload needs to remain available through a Zone failure, spread independent capacity across multiple Availability Zones. Cross-Region designs solve different problems and add replication, routing, and operational complexity.

Identity and permissions

Every AWS request runs as a principal. The root user has complete access to the account. Secure it with multi-factor authentication and use it only for tasks that require root credentials.

For people, AWS recommends federation and temporary credentials. IAM Identity Center can centrally manage workforce access across accounts. IAM roles give people, workloads, and AWS services temporary credentials for a session. A role is not tied to one permanent person and does not have standard long-term credentials.

Policies define permissions. They describe actions, resources, and optional conditions. AWS evaluates applicable policies when a principal makes a request. Start with least privilege: grant the actions on the resources that the job needs, then review actual use and tighten the policy.

Service families

AWS services solve different operating problems. You do not need to memorize the catalog. Start with the workload and identify the service family.

• Compute runs virtual machines, containers, or code in response to events.
• Storage keeps objects, files, blocks, backups, or archives.
• Databases store data with different query, consistency, and operational models.
• Networking connects resources, controls traffic, and delivers content to users.
• Security and identity control access, protect data, detect threats, and support audit work.
• Management and governance organize accounts, observe resources, record activity, and apply controls.

A managed service is not automatically the best choice. Compare the required control, operational responsibility, failure behavior, integration needs, and cost model. A service that reduces server maintenance can increase dependence on a specific interface or pricing dimension.

Design and operations

The AWS Well-Architected Framework gives you six recurring design lenses: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. They are not a compliance badge. They are a way to expose tradeoffs before production exposes them for you.

Make the first environment observable. CloudTrail records AWS API activity. Tags give resources ownership and cost-allocation metadata. Billing and Cost Management surfaces spending data and budget status. Service Quotas show account- and Region-level limits that can block a deployment.

Use these controls early. The first public resource, elevated role, or unbounded workload is the cheapest time to review.

A sensible learning path

1. Create an account and secure the root user with multi-factor authentication.
2. Learn the account, Region, Availability Zone, principal, role, and policy vocabulary.
3. Use temporary credentials through an appropriate identity design.
4. Explore one workload through the console, CLI, and API documentation.
5. Learn how the workload records activity, handles failure, and reports cost.
6. Add organizations, multi-account governance, and service-specific architecture only when the workload requires them.

AWS rewards deliberate boundaries. Decide who owns the resource, where it runs, who can change it, how you will observe it, and who receives the bill. The service selection comes after that.