AWS Platform Fundamentals

Introduction and Context

Amazon Web Services (AWS) is a cloud computing platform that provides on-demand access to computing, storage, networking, databases, security controls, monitoring tools, and application services. Rather than purchasing and operating physical servers, an organization can provision resources through software interfaces and pay according to usage, reservations, or contractual pricing arrangements.

For full-stack developers, AWS is not merely a hosting location. It is an ecosystem in which application code, identity, networking, deployment automation, data persistence, observability, and security must work together. A successful deployment therefore requires more than launching an EC2 instance. It requires a coherent architecture that addresses availability, scalability, security, performance, cost, and operational processes.

This chapter introduces the organizational and infrastructure foundations required to deploy web applications on AWS. It concentrates on AWS accounts and Organizations, IAM, Regions and Availability Zones, VPC networking, EC2, Elastic Beanstalk, S3, CloudFront, Route 53, managed databases, and the AWS Well-Architected Framework.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the purpose of AWS accounts, Organizations, Regions, Availability Zones, and VPCs.
2. Apply IAM principles to users, roles, policies, authentication, and authorization.
3. Distinguish the purposes of EC2, Elastic Beanstalk, S3, CloudFront, Route 53, and managed databases.
4. Design a basic, secure architecture for a full-stack web application.
5. Select deployment approaches appropriate to application complexity and operational capability.
6. Apply the AWS Well-Architected Framework to identify design trade-offs.
7. Evaluate availability, security, cost, performance, and governance risks in a cloud deployment.

1. The AWS Resource and Account Model

AWS accounts and Organizations

An AWS account is a security, billing, and administrative boundary. It contains resources such as EC2 instances, S3 buckets, IAM identities, databases, and networks. Account-level limits, billing records, and many security controls are associated with the account.

Although a small project may use one account, professional environments commonly use AWS Organizations. An organization groups multiple AWS accounts under a management account. Accounts can be arranged in organizational units (OUs), such as development, testing, production, security, and logging. Service control policies (SCPs) can restrict the maximum permissions available in member accounts. An SCP does not grant permission; it establishes a permission boundary for accounts within the organization.

A multi-account strategy reduces the impact of accidental changes and separates workloads, billing, and administrative privileges. For example, a developer account should not automatically have permission to delete production databases. Centralized logging and security accounts can also be protected from application administrators.

The management account should not be used for ordinary workloads. Administrative access should use strong authentication, preferably federation or IAM Identity Center, and the root user should be protected with multifactor authentication (MFA). Root credentials should be reserved for tasks that specifically require them.

Regions and Availability Zones

An AWS Region is a geographically distinct area containing AWS infrastructure. Regions are selected according to latency, regulatory requirements, service availability, data-residency requirements, and cost. An Availability Zone (AZ) is an isolated location within a Region, consisting of one or more data centers with independent power, networking, and cooling infrastructure.

Deploying across multiple AZs can reduce the effect of a failure in one AZ. However, multi-AZ architecture does not guarantee immunity from every failure: software defects, incorrect permissions, bad deployments, regional outages, and shared dependencies can still cause disruption.

A useful distinction is:

AWS services may be regional, zonal, or global in scope. EC2 instances are launched into a Region and a specific AZ. S3 buckets are associated with a Region, although the service is accessed through a global namespace. IAM is generally managed at the account level. Developers must read service documentation rather than assume that all resources have identical geographic behavior.

2. Identity and Access Management

AWS Identity and Access Management (IAM) controls who or what can perform actions on which resources. Its central security principle is least privilege: an identity should receive only the permissions needed for its legitimate task, for only as long as those permissions are required.

IAM identities

The principal IAM components are:

• Users: identities traditionally representing individual people. In modern environments, human access is often managed through IAM Identity Center and an external identity provider.
• Groups: collections of users to which policies can be attached.
• Roles: identities that are assumed temporarily by users, AWS services, or external systems.
• Policies: JSON documents describing allowed or denied actions on resources under specified conditions.

Applications should normally use IAM roles rather than storing long-lived access keys in source code. For example, an EC2 instance can assume a role that allows it to read selected objects from one S3 bucket. The application then obtains temporary credentials through the instance metadata service.

Authentication and authorization

Authentication answers, “Who or what is requesting access?” Authorization answers, “Is that principal permitted to perform this action on this resource?” IAM evaluates identity-based policies, resource-based policies, permissions boundaries, SCPs, session policies, and explicit denies. An explicit deny overrides an allow.

A simplified policy concept might permit s3:GetObject on objects under a particular bucket prefix while denying deletion. In production, permissions should specify exact actions, resources, and conditions instead of using broad wildcards such as Action: and Resource: .

Recommended practices include:

1. Require MFA for human administrative access.
2. Prefer temporary credentials and roles.
3. Avoid root-user access for routine work.
4. Separate development and production permissions.
5. Review unused permissions and access keys.
6. Log API activity with AWS CloudTrail.
7. Store secrets in AWS Secrets Manager or Systems Manager Parameter Store rather than source code or public object storage.

IAM security is also a governance issue. An overly permissive deployment role can allow an attacker who compromises a build system to alter DNS, exfiltrate data, or destroy infrastructure.

3. Virtual Private Cloud Fundamentals

Amazon Virtual Private Cloud (VPC) provides logically isolated networking for resources in a Region. A VPC is assigned an IPv4 CIDR block, such as 10.0.0.0/16. The CIDR notation describes an address range; /16 leaves 16 bits for host addresses, although AWS reserves some addresses in each subnet.

A VPC is divided into subnets. Each subnet belongs to exactly one AZ. A public subnet has a route to an Internet Gateway, but a route alone does not make an application secure or publicly reachable: security groups, network ACLs, public IP addressing, and service configuration also matter. A private subnet has no direct route from the Internet Gateway and is commonly used for application servers and databases.

Typical components include:

• Internet Gateway: enables Internet connectivity for resources with appropriate routes and addressing.
• Route tables: determine where packets are sent.
• Security groups: stateful virtual firewalls attached to resources; inbound rules are evaluated, and return traffic is automatically allowed for permitted connections.
• Network ACLs: stateless subnet-level controls; inbound and outbound rules must be considered separately.
• NAT Gateway: permits resources in private subnets to initiate outbound Internet connections, but does not permit unsolicited inbound connections from the Internet.
• VPC endpoints: provide private connectivity to selected AWS services, potentially reducing Internet exposure and NAT costs.

A standard web architecture places a load balancer in public subnets, application instances in private subnets, and a managed database in isolated or private subnets. The database security group permits traffic only from the application security group on the database port. It should not permit access from 0.0.0.0/0.

Network design must account for address planning, routing, AZ distribution, IPv4 exhaustion, IPv6 requirements, and connectivity to corporate networks. Subnet placement is not a replacement for authorization; application-layer authentication and database permissions remain necessary.

4. Core Compute and Deployment Services

Amazon EC2

Amazon Elastic Compute Cloud (EC2) provides resizable virtual machines. A developer selects an Amazon Machine Image (AMI), instance type, storage, network placement, security groups, and optional user-data initialization. EC2 provides flexibility: teams control the operating system, runtime, agents, and deployment process.

That flexibility creates responsibility. The team must patch the operating system, secure SSH access, configure monitoring, manage capacity, and recover from instance failure. Auto Scaling groups can replace unhealthy instances and adjust capacity, while Elastic Load Balancing distributes requests across healthy targets.

EC2 is suitable when an application requires operating-system control, specialized software, custom networking, or a deployment model not supported by a higher-level service. It is less suitable when a small team wants to avoid server administration.

Elastic Beanstalk

AWS Elastic Beanstalk is a managed application deployment service. A developer supplies application code and configuration; Beanstalk provisions and coordinates infrastructure such as EC2 instances, load balancing, Auto Scaling, and CloudWatch integration. The developer retains access to the underlying resources but does not need to construct every component manually.

Elastic Beanstalk is useful for conventional web applications with supported platforms and a desire for a straightforward deployment workflow. It is not a universal abstraction: complex microservices, unusual networking, and highly customized infrastructure may require direct use of AWS services or infrastructure-as-code tools.

A Beanstalk deployment should still define environment variables securely, configure health checks, separate environments, use immutable or rolling deployment strategies where appropriate, and monitor logs and metrics. “Managed” does not mean “unmanaged”; the application team remains responsible for code, configuration, data, and security decisions.

Choosing between EC2 and Elastic Beanstalk

5. Storage, Content Delivery, and DNS

Amazon S3

Amazon Simple Storage Service (S3) is object storage. Objects are stored in buckets and identified by keys. It is appropriate for images, build artifacts, backups, logs, static websites, and user uploads. It is not a conventional block disk or relational database.

S3 offers high durability through redundant storage, but developers must distinguish durability from availability, authorization, and backup policy. A highly durable object can still be inaccessible because of a denied permission, deleted version, incorrect key, or service configuration.

Important practices include blocking unintended public access, using bucket policies carefully, enabling versioning where recovery from overwrite or deletion matters, encrypting data, applying lifecycle rules, and recording access through appropriate logging. Presigned URLs can grant time-limited access to specific objects without making the whole bucket public.

CloudFront

Amazon CloudFront is a content delivery network (CDN). It caches content at edge locations closer to users and forwards cache misses to an origin such as S3, an Application Load Balancer, or a web server. CloudFront can reduce latency and origin load, terminate TLS, enforce viewer protocols, and integrate with security controls such as AWS WAF.

Caching requires careful design. Static assets with content hashes in their filenames can have long cache lifetimes. Frequently changing API responses need shorter lifetimes or explicit cache invalidation strategies. Sensitive, personalized responses should not be cached accidentally.

Route 53

Amazon Route 53 provides DNS hosting, domain registration, and health-check-based routing capabilities. DNS translates names such as api.example.com into records pointing to destinations. Route 53 can route traffic to CloudFront distributions, load balancers, or other endpoints using record types and routing policies.

DNS changes are not always immediately visible because resolvers cache records according to their time to live (TTL). A low TTL may make changes propagate more quickly but can increase DNS query volume. DNS health checks are useful but do not replace application monitoring or end-to-end testing.

6. Managed Databases

A managed database service such as Amazon RDS or Amazon Aurora reduces operational work for provisioning, backups, patching, monitoring, and failover. It does not remove the need for schema design, query optimization, access control, migration planning, or data governance.

Relational databases are appropriate when transactions, structured relationships, and strong consistency are central. A typical web application may use PostgreSQL or MySQL through RDS. Multi-AZ deployment maintains a standby in another AZ for failover; it should not be confused with read scaling. Read replicas are designed primarily for read traffic and reporting, and their replication behavior must be understood.

Database design decisions include:

• private subnet placement;
• encryption at rest and in transit;
• automated backups and point-in-time recovery;
• retention requirements;
• connection pooling;
• parameter and secret management;
• migration compatibility;
• monitoring of CPU, storage, connections, latency, and locks.

Backups are not sufficient unless restoration is tested. A backup that cannot be restored within the required recovery time has limited operational value.

7. A Reference Full-Stack Architecture

A practical architecture for a single-page application with an API and relational database may use the following flow:

1. Users resolve the application domain through Route 53.
2. CloudFront serves static frontend assets from S3.
3. API requests are sent to a CloudFront behavior or a separate API domain.
4. A load balancer distributes requests to application instances in private subnets.
5. The application accesses an RDS database in private subnets.
6. IAM roles provide application access to S3, logging, and other AWS services.
7. CloudWatch collects logs, metrics, alarms, and operational dashboards.
8. CloudTrail records API activity for governance and investigation.

This design separates static content, compute, and data. It also reduces direct exposure of application servers and databases. However, it introduces operational complexity: DNS, certificates, cache policies, subnet routing, deployments, secrets, migrations, and monitoring must all be managed coherently.

8. The AWS Well-Architected Framework

The AWS Well-Architected Framework provides six pillars for evaluating cloud workloads:

The framework is not a checklist that produces one universally correct architecture. It exposes trade-offs. For example, multi-AZ deployment can improve reliability but increase cost and complexity. A CDN may improve performance while requiring careful cache invalidation. A serverless or managed service may reduce operations work but constrain customization.

A useful design process is:

1. Define business requirements, users, data sensitivity, recovery objectives, and expected traffic.
2. Identify threats, failure modes, compliance constraints, and operational responsibilities.
3. Select managed services where they reduce undifferentiated work.
4. Design for observability, automation, and recoverability.
5. Test failure scenarios and restoration procedures.
6. Review costs and architecture continuously as usage changes.

Two recovery concepts are especially important. Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured in time. Recovery Time Objective (RTO) is the target maximum time required to restore service. These are business requirements, not merely technical settings. A system requiring an RTO of minutes may need a different design from one that can tolerate a day of downtime.

9. Deployment and Infrastructure as Code

Manual console configuration is useful for learning but difficult to reproduce reliably. Infrastructure as Code (IaC) expresses resources and configuration in declarative templates, using tools such as AWS CloudFormation or Terraform. IaC supports review, version control, repeatability, and environment consistency.

A professional deployment pipeline commonly includes source control, automated tests, security scanning, artifact creation, infrastructure validation, deployment to a non-production environment, approval or automated promotion, and monitoring after release. Blue-green, canary, rolling, and immutable deployment strategies provide different balances between speed, risk, cost, and rollback capability.

Configuration should be separated from code where appropriate. Secrets must not be committed to repositories or embedded in container images. Deployment roles should have narrowly scoped permissions, and production deployments should produce an auditable record.

10. Illustrative Case: Deploying a Student Marketplace

Background

A fictional student team has built a marketplace where users browse listings, upload images, send messages, and purchase items. The initial prototype runs on one virtual machine with a local database and stores uploaded images on the server disk.

Problem

The prototype has several risks: a single server is a single point of failure; local files may be lost when the server is replaced; the database is publicly reachable; deployment is manual; and image delivery is slow for geographically distant users.

Analysis

The workload requires durable object storage, transactional data, authenticated application access, controlled administrative access, and a deployment process that can be repeated. The team has limited operations experience, so managed services are preferable. The application is not yet large enough to justify a highly distributed microservice architecture.

Approach and solution

The team deploys the frontend as static assets in S3 and distributes them through CloudFront. Route 53 provides the public domain, while TLS certificates are configured for secure connections. The API runs on Elastic Beanstalk across at least two AZs behind a load balancer. The database is migrated to a private, Multi-AZ RDS deployment. Images are uploaded to S3 using server-authorized presigned URLs, so application servers do not need to handle every file transfer.

The application receives an IAM role that permits access only to the required S3 bucket and prefix. Database credentials are stored in Secrets Manager. Security groups permit database traffic only from the application security group. CloudWatch alarms monitor error rate, latency, instance health, database storage, and connection count. CloudTrail and centralized logs support investigation.

The team creates separate development and production accounts within an AWS Organization. Infrastructure is represented in version-controlled templates, and a pipeline deploys tested artifacts. Database migration scripts are reviewed and tested against a restored backup before production release.

Outcome

The architecture removes the local-file dependency, reduces direct Internet exposure, improves content latency, and makes replacement of application instances safer. It also introduces recurring costs and operational responsibilities, including cache behavior, secrets rotation, database maintenance, and monitoring. The team documents these responsibilities rather than assuming that AWS automatically solves them.

Learning points

The case demonstrates that cloud architecture is an exercise in controlled trade-offs. Managed services reduce some infrastructure work, but security, data modeling, deployment quality, observability, and recovery testing remain application-team responsibilities.

11. Challenges, Limitations, and Governance

Cloud platforms can create technical and organizational risks. Resource sprawl may produce unexpected cost. Publicly exposed storage or databases can cause data breaches. Misconfigured IAM roles can allow privilege escalation. Vendor-specific services may create switching costs. Multi-service architectures can make debugging more difficult because a request crosses DNS, CDN, load balancing, application, and database boundaries.

Governance should address account provisioning, naming and tagging, approved Regions, data classification, retention, encryption, vulnerability management, incident response, and cost budgets. AWS Budgets, cost allocation tags, and billing alarms can support financial accountability, although alarms are not a complete cost-control system.

Ethical responsibilities include protecting personal data, limiting collection to legitimate purposes, retaining information only as needed, and ensuring that access logs and monitoring do not become uncontrolled surveillance. Regulatory obligations depend on jurisdiction and industry; teams must consult applicable legal and compliance experts rather than treating a cloud-provider certification as a universal compliance guarantee.

Artificial intelligence services may be integrated into AWS applications, but AI use introduces additional concerns: training-data rights, personally identifiable information, model bias, explainability, prompt injection, output validation, and cost control. AI should be added only when it serves a defined requirement and can be monitored safely.

Best Practices Checklist

• Use separate accounts or environments for development and production.
• Protect root credentials and require MFA.
• Prefer IAM roles and temporary credentials.
• Place databases in private subnets and restrict security-group sources.
• Store files in S3 rather than on ephemeral application instances.
• Encrypt data in transit and at rest where appropriate.
• Automate deployment and infrastructure configuration.
• Enable logging, metrics, alarms, and audit trails.
• Test backups, failover, rollback, and incident procedures.
• Review architecture and costs continuously using the Well-Architected pillars.

Chapter Summary

AWS provides a layered platform for deploying full-stack applications. Accounts establish security and billing boundaries, while AWS Organizations supports multi-account governance. Regions provide geographic placement and Availability Zones provide fault isolation within a Region. VPCs, subnets, route tables, security groups, and gateways form the network foundation.

EC2 offers control over virtual machines; Elastic Beanstalk simplifies conventional application deployment; S3 provides durable object storage; CloudFront distributes content; Route 53 supplies DNS; and RDS or Aurora provides managed relational databases. These services must be combined with IAM, secrets management, monitoring, backups, and deployment automation.

The AWS Well-Architected Framework encourages balanced decisions across operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Cloud architecture is not the elimination of responsibility. It is the deliberate allocation of responsibility between the provider and the application team, supported by automation, governance, and continuous evaluation.

Key Terms

Account: An AWS boundary for billing, security, resources, and administration.

AWS Organizations: A service for centrally managing multiple AWS accounts.

Availability Zone: An isolated infrastructure location within an AWS Region.

Region: A geographic AWS infrastructure area containing multiple Availability Zones.

IAM: AWS Identity and Access Management for authentication and authorization.

Role: A temporary-credential identity assumed by users, services, or external systems.

Least privilege: Granting only the permissions necessary for an approved task.

VPC: A logically isolated virtual network in AWS.

Subnet: An IP address range within a VPC associated with one Availability Zone.

Security group: A stateful virtual firewall attached to AWS resources.

EC2: AWS virtual machine compute service.

Elastic Beanstalk: A managed application deployment service that provisions supporting infrastructure.

S3: AWS object storage using buckets and object keys.

CloudFront: AWS content delivery network and edge caching service.

Route 53: AWS DNS and domain-management service.

RDS: Managed relational database service from AWS.

IAM policy: A document specifying permitted or denied actions on resources.

RPO: Maximum acceptable data loss measured as a period of time.

RTO: Target maximum time for recovering a service.

Well-Architected Framework: AWS framework for evaluating cloud workload design across six pillars.

Review Questions

Short Answer Questions

1. Why are multiple AWS accounts often used in a professional organization?
2. What is the difference between an AWS Region and an Availability Zone?
3. Why should application code normally use IAM roles rather than embedded access keys?
4. What is the purpose of a private subnet?
5. How do S3 and CloudFront serve different purposes?

Long Answer Questions

1. Explain how IAM policies, roles, MFA, and least privilege work together to secure an AWS deployment.
2. Describe a secure VPC architecture for a web application with an API and relational database.
3. Compare EC2 and Elastic Beanstalk, including their operational benefits and limitations.
4. Explain the six pillars of the AWS Well-Architected Framework and give one design consideration for each.
5. Discuss why backups, monitoring, and infrastructure as code are necessary even when managed AWS services are used.

Analytical / Application Questions

1. A team stores user uploads on the local disk of one EC2 instance and allows the database to accept connections from the Internet. Identify the risks and propose an AWS-based redesign.
2. An application must continue operating if one Availability Zone fails, but the organization has a strict cost limit. Analyze the trade-offs of multi-AZ compute, database deployment, caching, and operational complexity.
3. A deployment pipeline has permission to perform every action on every AWS resource. Analyze the security implications and design a least-privilege alternative.

Multiple Choice Questions with Answers

Question 1

Which AWS construct is primarily used to group multiple accounts for centralized governance?

A. AWS Organizations

B. Amazon CloudFront

C. Amazon Route 53

D. Amazon S3

Correct Answer: A. AWS Organizations

Question 2

Which identity type is generally preferred for allowing an EC2 application to access S3 without storing long-lived keys in source code?

A. Root user

B. IAM role

C. IAM group

D. Distribution list

Correct Answer: B. IAM role

Question 3

What is the principal purpose of an Availability Zone?

A. To provide a separate billing account

B. To provide fault isolation within a Region

C. To replace IAM policies

D. To store DNS records globally

Correct Answer: B. To provide fault isolation within a Region

Question 4

Which service is designed primarily for object storage?

A. Amazon RDS

B. Amazon EC2

C. Amazon S3

D. Amazon Route 53

Correct Answer: C. Amazon S3

Question 5

Which component allows instances in a private subnet to initiate outbound Internet connections without accepting unsolicited inbound connections?

A. NAT Gateway

B. IAM role

C. CloudFront distribution

D. S3 bucket policy

Correct Answer: A. NAT Gateway

Question 6

Which service distributes cached content through edge locations?

A. Amazon RDS

B. Amazon CloudFront

C. Amazon Organizations

D. Amazon VPC

Correct Answer: B. Amazon CloudFront

Question 7

What does an explicit deny in an IAM policy evaluation do?

A. It is ignored if an allow exists

B. It overrides an applicable allow

C. It applies only to billing resources

D. It grants temporary credentials

Correct Answer: B. It overrides an applicable allow

Question 8

Which Well-Architected pillar focuses most directly on recovering from failures?

A. Reliability

B. Sustainability

C. Cost optimization

D. Performance efficiency

Correct Answer: A. Reliability

Question 9

A database is placed in a private subnet and its security group allows traffic only from the application security group. What principle does this most directly demonstrate?

A. Least-privilege network access

B. Public content caching

C. DNS registration

D. Root-user administration

Correct Answer: A. Least-privilege network access

Question 10

What does RTO describe?

A. The maximum acceptable amount of data loss

B. The target time to restore service

C. The number of replicated database rows

D. The cache duration for a DNS record

Correct Answer: B. The target time to restore service