Unit 4: AWS Fundamentals

CSE423 — Virtualization And Cloud Computing 10 min read

I. Orientation

Amazon Web Services (AWS) is a public cloud computing platform launched in 2006 that provides on-demand access to computing, storage, databases, networking, security, analytics, and other IT resources. Instead of purchasing and maintaining physical infrastructure, organizations provision resources from AWS data centers and pay according to usage, reservations, or subscription arrangements.

A. Governing principles of AWS cloud computing

AWS relies on several principles that explain how its services are designed, deployed, and secured.

On-demand provisioning: Users can create resources such as an Amazon EC2 instance or an Amazon S3 bucket through a console, command-line interface, or API without waiting for hardware installation.
Elasticity: Resources can increase or decrease with demand. For example, an Auto Scaling group may add EC2 instances when request traffic rises and remove them when demand falls.
Measured usage: AWS commonly charges according to measurable consumption, such as EC2 instance-hours, S3 storage in gigabytes, or data transfer in gigabytes.
Global infrastructure: AWS resources operate within geographical Regions and isolated Availability Zones, allowing applications to balance latency, resilience, and compliance requirements.
Shared security: AWS secures the underlying cloud infrastructure, while customers secure their data, configurations, identities, and workloads according to the service used.
Least privilege: Identities should receive only the permissions necessary for their tasks. A user who needs to read objects in one S3 bucket should not automatically receive administrator access.
Automation through APIs: AWS services expose programmable interfaces, enabling repeatable deployment using tools such as AWS CLI, SDKs, and infrastructure-as-code services.

II. AWS Cloud Infrastructure — Global Resources for Scalable Computing

AWS cloud infrastructure is the physical and logical foundation on which AWS services operate. It connects data centers, networking equipment, storage systems, and virtualization technologies into a globally accessible platform.

A. AWS cloud infrastructure

AWS cloud infrastructure organizes resources into Regions, Availability Zones, and edge locations to provide performance and fault tolerance.

Regions: A Region is a separate geographic area, such as us-east-1 or eu-west-1. Selecting a Region affects latency, legal requirements, service availability, and pricing.
Availability Zones: Each Region contains multiple isolated Availability Zones, commonly written as us-east-1a or us-east-1b. An Availability Zone consists of one or more discrete data centers with independent power, cooling, and networking.
Regional resilience: Deploying an application across two Availability Zones reduces the effect of a single data-center failure. An application might place EC2 instances in us-east-1a and us-east-1b behind an Elastic Load Balancer.
Edge locations: Edge locations support services such as Amazon CloudFront by caching content closer to users. A user in Singapore may receive cached content from a nearby edge location rather than from an origin server in the United States.
Points of Presence: AWS networking services use edge sites and dedicated connectivity locations to improve delivery, routing, and access to AWS resources.
Virtual networking: Amazon VPC provides logically isolated networks containing subnets, route tables, security groups, and network access control lists. A subnet is associated with one Availability Zone.
High availability: Availability means reducing service interruption through redundancy. Durability is different: Amazon S3 Standard is designed for very high object durability, while availability describes whether the service can be accessed at a given time.

III. AWS Service Categories — Building Blocks of Cloud Solutions

AWS service categories group related capabilities so that users can select appropriate building blocks for an application or organization.

A. AWS service categories

AWS offers services ranging from virtual machines to fully managed software platforms.

Compute: Amazon EC2 provides resizable virtual servers; AWS Lambda runs code without managing servers; Amazon ECS and Amazon EKS support containerized applications.
Storage: Amazon S3 stores objects such as documents and images; Amazon EBS provides block storage for EC2; Amazon EFS supplies shared file storage.
Databases: Amazon RDS manages relational engines such as MySQL and PostgreSQL; Amazon DynamoDB provides a managed NoSQL key-value database; Amazon Aurora is a cloud-optimized relational database.
Networking and content delivery: Amazon VPC provides isolated networking, Elastic Load Balancing distributes traffic, and CloudFront delivers cached content through edge locations.
Security, identity, and compliance: IAM controls permissions; AWS Key Management Service manages encryption keys; AWS WAF filters web requests; AWS CloudTrail records API activity.
Management and governance: Amazon CloudWatch collects metrics and logs; AWS CloudFormation creates resources from templates; AWS Config records resource configuration and compliance status.
Application integration: Amazon SQS provides message queues, Amazon SNS provides publish-subscribe notifications, and Amazon EventBridge routes events between services.
Analytics and machine learning: Amazon Athena queries data in S3 using SQL, Amazon Redshift provides data warehousing, and Amazon SageMaker supports machine-learning workflows.
Managed versus self-managed services: With Lambda, AWS manages much of the runtime infrastructure. With EC2, the customer still manages the guest operating system, installed software, and instance configuration.

IV. AWS Management Console — Graphical Administration of Resources

The AWS Management Console is a browser-based interface for viewing, configuring, monitoring, and troubleshooting AWS resources.

A. AWS Management Console

The console provides service-specific dashboards while preserving the same underlying AWS APIs used by the CLI and SDKs.

Service navigation: The console lists services such as EC2, S3, IAM, and VPC. The search bar helps locate a service without navigating through every category.
Region selection: A Region selector appears in the console header. Creating an EC2 instance in ap-southeast-1 does not create it in us-east-1; many resources are Region-specific.
Resource creation: Wizards guide users through settings such as instance type, AMI, key pair, subnet, storage volume, and security group when launching an EC2 instance.
Resource inspection: Resource pages display identifiers, status, tags, networking details, monitoring graphs, and configuration settings. Tags such as Environment=Production support organization and cost allocation.
Permissions: The console makes requests through AWS APIs using the signed-in identity. A user who cannot call ec2:RunInstances cannot launch an instance through the console.
CloudShell and CLI access: AWS CloudShell provides a browser-based shell with AWS CLI access. The command below lists S3 buckets available to the current identity:

BASH

aws s3 ls

Operational caution: Console actions can create billable resources. A running EC2 instance or unattached EBS volume may continue generating charges until stopped or deleted.

V. Shared Responsibility Model — Security Duties in the Cloud

The Shared Responsibility Model divides security obligations between AWS and the customer. Responsibility changes according to the service and deployment model.

A. Shared Responsibility Model

AWS is responsible for security of the cloud, while customers are responsible for security in the cloud.

AWS responsibility: physical infrastructure: AWS protects data centers, physical hosts, networking equipment, power systems, and the virtualization layer. Customers do not manage the physical server running an EC2 instance.
Customer responsibility: customer data: Customers decide what data to store, how to classify it, who may access it, and whether it should be encrypted.
Customer responsibility: guest operating system: For EC2, customers patch the operating system, configure host firewalls, install updates, and secure applications. AWS does not automatically patch a customer’s Windows or Linux installation.
Service-dependent responsibility: With Amazon RDS, AWS manages much of the database operating system and platform maintenance, but customers still manage database users, permissions, network access, and data.
Different abstraction levels: EC2 requires more customer management than Lambda. Lambda removes server administration, but customers remain responsible for function code, dependencies, IAM permissions, and sensitive information.
Configuration responsibility: A service can be secure by design but misconfigured by a customer. Making an S3 bucket public or assigning an overly broad IAM policy creates customer-side exposure.
Evidence and auditing: Customers should review CloudTrail events, configuration findings, and access logs to verify that resources are used as intended.

VI. Identity and Access Management (IAM) — Controlling AWS Access

AWS Identity and Access Management (IAM) is a global service used to control authentication and authorization. Authentication establishes who or what is requesting access; authorization determines which actions are permitted.

A. Identity and Access Management (IAM)

IAM uses identities and policies to grant controlled access to AWS resources.

Root user: The root user is created with the AWS account and has unrestricted account-level authority. It should not be used for routine work. Root credentials should be protected with MFA.
IAM users: An IAM user represents a person or application identity with long-term credentials. Human users are generally better managed through federated access or IAM Identity Center.
IAM groups: Groups collect users with similar permissions, such as Developers or Auditors. Policies can be attached to the group rather than repeatedly assigned to individual users.
IAM roles: A role is an identity with permissions that can be assumed temporarily. An EC2 instance role allows software on the instance to call AWS services without storing access keys in source code.
Policies: Policies are JSON documents containing Effect, Action, Resource, and optional Condition elements.

JSON

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*"
}

Here, Allow grants the s3:GetObject action on every object in reports-bucket.

Policy evaluation: An explicit Deny overrides an Allow. If no policy grants an action, the request is implicitly denied.
Least privilege: A reporting application needing only object reads should receive s3:GetObject, not s3:* or AdministratorAccess.
Trust and permission policies: A role’s trust policy defines who may assume it; its permissions policy defines what the role may do after assumption.
Resource-based policies: Some services, including S3, support policies attached directly to a resource. These can grant access to another account or identity.

VII. AWS Account Security — Protecting the Account Boundary

AWS account security combines strong authentication, controlled permissions, monitoring, and cost governance. It protects both the account itself and the resources deployed within it.

A. AWS account security

Account security begins with protecting privileged credentials and establishing controls that detect misuse.

Protect the root user: Enable MFA, remove unnecessary root access keys, and use the root user only for tasks that require it, such as changing certain account settings.
Use multi-factor authentication: MFA requires an additional factor beyond a password. Hardware security keys or authenticator applications reduce the risk of password-only compromise.
Prefer temporary credentials: IAM roles and AWS STS provide short-lived credentials. Temporary credentials reduce the exposure period compared with permanent access keys.
Secure access keys: Never place access keys in application source code, public repositories, or unencrypted configuration files. Use IAM roles, environment controls, or AWS Secrets Manager.
Apply least privilege: Review permissions regularly and remove unused policies. IAM Access Analyzer can identify unintended external access and help refine permissions.
Use centralized access: AWS IAM Identity Center supports workforce access through managed identities, permission sets, and single sign-on across accounts.
Enable logging: AWS CloudTrail records management events such as CreateUser, RunInstances, and PutBucketPolicy. CloudWatch can alert on suspicious activity.
Monitor configuration: AWS Config evaluates resource settings, while GuardDuty analyzes signals for threats such as unusual API calls or compromised credentials.
Separate environments: Development, testing, and production should be separated using accounts, roles, or permission boundaries. This limits the effect of accidental changes.
Control spending: AWS Budgets can alert when actual or forecasted costs exceed a threshold, such as 80% of a monthly budget. Billing alarms help identify unexpected resource creation.
Secure the network: Place private workloads in private subnets, restrict inbound security-group rules, and allow only required ports. For example, an application server may accept HTTPS on port 443 while blocking public SSH access.
Plan recovery: Backups, versioning, cross-Region replication, and tested restoration procedures protect against deletion, corruption, and regional disruption. Security includes maintaining availability and recoverability, not only preventing unauthorized access.