Amazon Web Services is a platform for renting technology as programmable services. Instead of ordering a physical server and wiring it into a network, you ask for services through an API. Compute, storage, databases, queues, and many other capabilities can arrive in minutes.
That speed is useful, but it changes the work rather than removing it. AWS operates the cloud infrastructure. You still decide access, data location, failure recovery, monitoring, and the cost boundary for each design.
This introduction starts with architecture decisions. Service names appear only where they clarify a choice, keeping the guidance useful as AWS adds products.
Traditional infrastructure is purchased for an expected peak and kept for years. Cloud infrastructure is requested when needed, changed through software, measured continuously, and charged according to a service pricing model. This makes experimentation and scaling faster, but a careless experiment can also become a recurring bill.
The important shift is from owning equipment to managing services. Capacity planning still matters, but it becomes a recurring engineering decision rather than a one-time hardware purchase.
| Traditional approach | AWS approach | What does not disappear |
|---|---|---|
| Buy servers for forecast demand | Provision capacity on demand | Performance testing and capacity limits |
| Large upfront purchase | Usage-based or committed pricing | Budgeting and cost ownership |
| Manual changes on individual machines | API-driven and automated changes | Review, testing, and rollback |
| One datacenter is the default | Multiple Regions and Availability Zones are available | Architecture for failure and data recovery |
Consider a small online shop. A customer enters a domain name, downloads the site, signs in, views a product, and places an order. AWS does not provide one mandatory “online shop” product. You assemble services around the request path and the operational needs of the business.
A possible design is Route 53 for DNS and CloudFront for edge delivery. It might use an Application Load Balancer, ECS or EC2, RDS, S3, SQS, and CloudWatch. Lambda or DynamoDB could replace parts of that design when their operating model fits better.
| Question | Typical AWS capability | Design concern |
|---|---|---|
| How does the user reach us? | Route 53, CloudFront, Elastic Load Balancing | DNS, TLS, caching, filtering, and origin health |
| Where does code run? | EC2, Lambda, ECS, EKS, App Runner | Control, scaling, startup time, and operational effort |
| Where is state kept? | S3, EBS, RDS, DynamoDB, ElastiCache | Data model, durability, consistency, and recovery |
| How is work decoupled? | SQS, SNS, EventBridge, Step Functions | Retries, ordering, duplicate delivery, and failure handling |
| How do operators know? | CloudWatch, CloudTrail, Config, X-Ray | Metrics, logs, traces, API history, and configuration drift |
An AWS account is more than a login. It is a boundary for resources, permissions, quotas, and billing. Production, development, security tooling, and shared infrastructure are often placed in separate accounts so that one mistake does not expose or disrupt everything.
AWS Organizations manages multiple accounts under one organization. Organizational units group accounts, while service control policies and resource control policies can place guardrails around what identities or resources are permitted to do. These guardrails limit permissions; they do not grant permissions on their own.
A Region is a geographic area in which AWS operates infrastructure. Most resources are regional, and choosing a Region affects latency, legal or data-residency requirements, service availability, and price. Some newer Regions must be enabled before an account can use them.
An Availability Zone is an isolated location within a Region. Deploying application capacity across zones can reduce the effect of a single-location failure, but only if routing, compute, and data layers are configured to use that redundancy. Edge locations support services such as CloudFront and Route 53 closer to users; they are not substitutes for Regions.
| Scope | Useful decision framework | Common mistake |
|---|---|---|
| Account | Security, resource, quota, and billing boundary | Putting every environment in one account |
| Region | Geographic deployment area | Creating a resource in the wrong Region and assuming it disappeared |
| Availability Zone | Failure-isolation location inside a Region | Running every critical component in one zone |
| Edge location | AWS presence near users for selected global services | Treating an edge cache as the source of truth |
The Management Console, AWS CLI, SDKs, CloudFormation, and third-party infrastructure tools all call AWS service APIs. The console is useful for discovery; the CLI is useful for repeatable inspection and small operations; SDKs let applications call AWS; infrastructure as code describes complete environments.
A professional workflow does not forbid the console. It avoids leaving important production configuration known only to the person who clicked it.
Every AWS API request has a principal: a person, role session, AWS service, or application identity. IAM evaluates policies to determine whether that principal may perform an action on a resource under the request conditions.
AWS recommends temporary credentials for people and workloads. Human users normally federate through an identity provider, while EC2 instances, Lambda functions, and ECS tasks receive temporary credentials from IAM roles. Long-lived access keys should be exceptional, not the default tutorial shortcut.
| Identity need | Preferred approach | Avoid |
|---|---|---|
| Employee console and CLI access | Federation through IAM Identity Center or an identity provider | Shared IAM users |
| Application running on AWS | IAM role attached to the compute service | Keys stored in code or environment files |
| Cross-account access | Assume a role with a narrow trust policy | Copying credentials between accounts |
| Emergency account recovery | Protected root or break-glass process with MFA | Routine use of root credentials |
A Virtual Private Cloud is a regional network in which you define IP ranges, subnets, routes, gateways, and traffic controls. A subnet is called public when its routing can support direct internet access; the label itself does not expose a resource.
Security groups are stateful controls attached to network interfaces. Network ACLs are stateless subnet controls. Route tables decide where packets are sent. DNS decides which name becomes which address. When connectivity fails, inspect the entire path instead of opening every firewall rule.
The useful question is not “Which AWS service is best?” but “Which operating model fits this workload?” EC2 provides server control. Containers package an application and can run on ECS or EKS. Lambda runs event-driven functions without server management. Managed platforms such as App Runner reduce more infrastructure work.
Data choices follow access patterns. S3 stores objects, EBS provides block storage for EC2, EFS provides shared file storage, RDS and Aurora provide relational databases, and DynamoDB provides a managed key-value and document model. A cache improves speed but should not accidentally become the only durable copy of business data.
| Need | Good starting candidates | Question that separates them |
|---|---|---|
| Full operating-system control | EC2 | Are you prepared to patch and operate the instance? |
| Packaged long-running application | ECS on Fargate or EC2 | Do you need host control or only task execution? |
| Short event-driven work | Lambda | Can the work be stateless, retry-safe, and bounded? |
| Relational transactions and SQL | RDS or Aurora | Which engine, availability, and connection limits apply? |
| Objects, files, and static assets | S3, EFS, or EBS | Does the application need object, shared-file, or block semantics? |
AWS describes security as responsibility “of” the cloud and responsibility “in” the cloud. AWS protects facilities, hardware, and the underlying infrastructure. Customers protect their identities, data, workload configuration, and access paths.
The exact line depends on the service. On EC2, you manage the guest operating system and installed software. With RDS, AWS operates more of the database infrastructure. With Lambda, AWS operates the servers and runtime infrastructure. In every case, you still own your code, data classification, permissions, and configuration choices.
| Area | AWS responsibility | Customer responsibility |
|---|---|---|
| Physical infrastructure | Facilities, hardware, and foundational networking | Selecting appropriate Regions and services |
| Identity | IAM service availability and security | Users, roles, policies, MFA, and access review |
| Data | Durability mechanisms promised by the service | Classification, encryption choices, backup, retention, and deletion |
| Workload | Managed infrastructure according to the service | Code, dependencies, configuration, exposure, and testing |
AWS services can provide highly available building blocks, but an application is reliable only when its complete dependency path can tolerate expected failures. Multi-AZ compute is not enough if the database is single-zone, DNS points to one endpoint, or a deployment can break every instance at once.
Define recovery time objective (how quickly service must return) and recovery point objective (how much data loss is acceptable). Then choose redundancy, backups, replication, queues, retries, and failover tests that meet those targets.
CloudWatch collects metrics, logs, alarms, and dashboards for many AWS services and applications. CloudTrail records AWS API activity. AWS Config tracks resource configuration and compliance history. Tracing tools such as X-Ray or OpenTelemetry-compatible systems help follow a request across components.
These signals answer different questions. A high error-rate metric says customers are affected. An application log may explain the error. A trace can reveal the slow dependency. CloudTrail can show who changed the security group shortly before the incident.
AWS pricing is service-specific. An EC2 design may include instance time, EBS volumes, snapshots, load balancing, public IPv4 addresses, and data transfer. A serverless design may include invocations, duration, queue requests, logs, database requests, and network charges.
Pay as you go does not mean cheap by default. It means cost follows configured capacity and usage. Budgets alert on thresholds, Cost Explorer helps analyze trends, tags and accounts help allocate ownership, and Savings Plans or reservations can reduce stable eligible usage after right-sizing.
The AWS Well-Architected Framework organizes design reviews around six pillars. They are not a scorecard to complete once; they are prompts for finding trade-offs and operational risks as a workload evolves.
| Pillar | Question to keep asking |
|---|---|
| Operational excellence | Can the team deploy, observe, operate, and improve the workload safely? |
| Security | Are identities, data, and systems protected with evidence? |
| Reliability | Can the workload recover from infrastructure and application failure? |
| Performance efficiency | Does the architecture use resources that fit current demand and technology? |
| Cost optimization | Is spending visible, owned, and proportional to business value? |
| Sustainability | Can the workload reduce unnecessary resource use while meeting requirements? |
Beginners often jump between services and remember screenshots instead of systems. A better sequence starts with account safety and API identity, then follows one small application through network, compute, storage, deployment, monitoring, and cleanup.
Proficient users should repeat the same project with stronger constraints: private connectivity, least privilege, infrastructure as code, multi-AZ behavior, recovery testing, cost allocation, and an incident runbook. The service list changes; the engineering questions become deeper.
| Stage | Build or verify | Skill gained |
|---|---|---|
| 1. Account | MFA, federated access, CLI profile, budget | Safe identity and cost context |
| 2. Static delivery | Private S3 origin behind CloudFront | Object storage, DNS, TLS, and caching |
| 3. Application | Small API on Lambda or ECS | Compute choice, runtime identity, and logs |
| 4. Data | RDS or DynamoDB based on an access pattern | Data modeling, permissions, backup, and limits |
| 5. Automation | Recreate the environment as code | Repeatability, review, and rollback |
| 6. Failure | Break a dependency and restore service | Troubleshooting, resilience, and recovery |
Sign in with your normal workforce identity, not the root user. Keep this tour read-only. First understand the console context, then create resources with confidence in the correct account and Region.
Console layouts change over time, but the account, Region, search, service navigation, notifications, and CloudShell concepts remain useful. Treat the console as a view over AWS APIs rather than as a separate version of AWS.
| Step | Why you do it | What happens and the expected result |
|---|---|---|
| 1. Confirm the account and role | Prevents changes in the wrong environment | Open the account menu and verify the account ID or alias and current role. They should match the lab account you intended to use. |
| 2. Select a Region | Most resources belong to one Region | Use the Region selector and choose the Region approved for the lab. Regional service pages now query that location. |
| 3. Search for EC2 | Shows how services are organized | Open the EC2 console and inspect the Resources summary. You should see counts for the selected Region; do not launch an instance yet. |
| 4. Open S3 | Demonstrates a service with global console navigation | The bucket list can span Regions. Each bucket still has a specific Region, so inspect the Region column rather than assuming the current selector controls it. |
| 5. Open CloudShell where available | Provides an authenticated shell without storing local access keys | Run aws sts get-caller-identity. The returned account and ARN should agree with the console identity checked in step 1. |
| 6. Check billing access | Makes cost ownership visible from the start | Open Billing and Cost Management if your role permits it. Read-only or no access is a permissions outcome, not a reason to switch to root. |
Organizations rarely move every system to AWS for one reason. They usually adopt it workload by workload, selecting an operating model that matches business constraints, team skill, recovery targets, and regulation.
| Scenario | Why AWS may fit | When to pause or choose differently |
|---|---|---|
| New digital product | A small team can combine managed compute, databases, delivery, and monitoring without buying hardware | Requirements are still unknown; start small rather than designing for imaginary global scale |
| Seasonal commerce | Capacity can expand around demand and contract afterward | Scaling is useful only after load tests, quotas, database capacity, and cost controls are addressed |
| Enterprise application migration | EC2 and managed data services can provide a staged path away from owned hardware | Licensing, latency, unsupported appliances, or tightly coupled dependencies may make relocation expensive |
| Backup and disaster recovery | Independent Regions and durable storage support several recovery strategies | A copied backup is insufficient without tested restoration, access, networking, and application runbooks |
| Data processing and analytics | Object storage and managed processing services can separate storage from temporary compute | Sensitive data, transfer volume, retention, and query patterns must be understood before ingestion |
Most early AWS incidents are not caused by obscure technology. They come from losing track of identity, location, exposure, ownership, or lifecycle. Build a habit that makes those five facts visible.
| Mistake | Why it causes trouble | Better habit |
|---|---|---|
| Using the root user for daily work | Root has unrestricted account authority and is difficult to constrain | Protect root with MFA and use federated roles for routine access |
| Copying access keys into code | Keys leak through repositories, logs, images, and shared machines | Use temporary credentials and workload roles |
| Opening inbound access to everyone | A public address range invites automated scanning and attack | Expose only required ports through the intended entry point |
| Building in one Availability Zone by accident | A location failure can remove the entire request path | Map every critical dependency to its failure domain |
| Assuming stopping means free | Disks, snapshots, addresses, gateways, and logs may continue to incur charges | Read each service pricing dimension and delete resources that are no longer needed |
| Learning only through console clicks | The result is difficult to review, reproduce, or recover | Repeat the lab with CLI inspection and infrastructure as code |
When an AWS action fails, do not immediately add permissions or open network rules. First classify the failure as identity, location, configuration, network path, capacity, application behavior, or service health. Then collect evidence at that layer.
| Symptom | First checks | Evidence to collect |
|---|---|---|
| AccessDenied | Caller identity, requested action, resource ARN, policy conditions, and explicit denies | Exact error, request ID, CloudTrail event, and policy evaluation context |
| Resource appears missing | Account, role, Region, filters, and whether the service is global or regional | Caller ARN, selected Region, resource tags, and CLI describe output |
| Application times out | DNS, routes, security groups, NACLs, endpoint health, and dependency latency | Connection test, load balancer metrics, flow logs, application logs, and trace |
| Deployment succeeds but users see errors | Health check depth, configuration, secrets, schema compatibility, and downstream limits | Deployment marker, error rate, logs, traces, and rollback result |
| Unexpected bill | Cost by service, account, Region, usage type, and tag | Cost Explorer grouping, resource inventory, recent API activity, and owner confirmation |
A diagram is not production readiness. Before launch, the team needs measurable targets, named owners, controlled access, repeatable deployment, observable customer paths, tested recovery, and an agreed cost envelope.
Not every workload needs multi-Region active-active architecture. Extra redundancy adds data-consistency, testing, and operating cost. Choose the simplest design that meets documented business requirements, then test the assumptions that make it acceptable.
These commands answer the two questions that prevent a surprising number of mistakes: which account am I using, and which Region will the next command target?
aws sts get-caller-identity
aws configure get region
aws account list-regions \
--region-opt-status-contains ENABLED_BY_DEFAULT ENABLED \
--query "Regions[].RegionName" \
--output tableStart with read-only inventory. The commands below reveal existing buckets, VPCs, and recent API events without creating resources.
aws s3api list-buckets \
--query "Buckets[].Name" \
--output table
aws ec2 describe-vpcs \
--query "Vpcs[].{VpcId:VpcId,Cidr:CidrBlock,Default:IsDefault}" \
--output table
aws cloudtrail lookup-events \
--max-results 10 \
--query "Events[].{Time:EventTime,Name:EventName,User:Username}" \
--output tableBefore opening the console, write the request path and the failure assumptions. This short design note is more valuable than a screenshot of completed resources.
Workload: product catalogue API
Entry:
- Route 53 resolves api.example.com
- API Gateway accepts HTTPS requests
Compute:
- Lambda runs stateless request handlers
- execution role can read one DynamoDB table
Data:
- DynamoDB partition key: productId
- point-in-time recovery enabled
Operations:
- alarm on API 5xx errors and Lambda throttles
- structured logs include requestId
Failure assumptions:
- a request may be retried
- duplicate writes must be safe
- deployment must be reversibleNo. Learn the major capability groups and the questions that separate their operating models. Most engineers use a focused subset deeply and look up unfamiliar services when a requirement calls for them.
Learn enough EC2 to understand virtual machines, networking, and operating-system responsibility. Then compare it with Lambda or a managed container platform so you can see which operational work each model removes and which constraints it introduces.
No. AWS provides services and controls that can support those outcomes. Your architecture, permissions, configuration, recovery testing, monitoring, and cost management determine whether the workload actually achieves them.
Explore 500+ free tutorials across 20+ languages and frameworks.