AWS has services for many kinds of workloads, but a useful design starts with a few questions: what runs your code, where does its state live, how does it connect, and which operational tasks will your team own?
This overview explains the AWS building blocks that commonly answer those questions. It focuses on how to choose between them, because service names alone do not make an application secure, resilient, or cost-effective.
How AWS building blocks fit together
Start with the workload and its boundaries
AWS resources are created in an account and, for most services, a Region. A Region is a separate geographic area; Availability Zones (AZs) are isolated locations within a Region. A subnet belongs to one AZ, while a VPC is a Regional virtual network. Choose a Region based on requirements such as data residency, latency, service availability, and cost, then decide whether the workload needs to span AZs or Regions. Multiple locations can reduce exposure to some failures, but they add configuration, data replication, and recovery work. AWS describes the relationship between Regions and Availability Zones.
The amount AWS operates also varies by service. With an EC2 instance, you manage the guest operating system and application software. With a managed database or object store, AWS operates more of the underlying platform, while you still control your data, permissions, network configuration, and application behavior. That division is the AWS shared responsibility model; the details depend on the service and how you use it.
Core AWS services at a glance
These categories are a starting map, not a required stack. A small workload may use only a few of them; add services when they solve a specific need.
Need
Common building blocks
Decision to make
Run application code
Amazon EC2, Amazon ECS or EKS, AWS Fargate, AWS Lambda
How much control do you need over servers, containers, and runtime?
Store application data
Amazon S3, Amazon EBS, Amazon EFS or Amazon FSx
Does the application need objects, a disk-like volume, or a shared file system?
Query application state
Amazon RDS or Aurora, Amazon DynamoDB
Are relational transactions and queries, or key-based access patterns, the better fit?
Which paths must be reachable, from whom, and across which locations?
Control and observe
IAM, IAM Identity Center, Amazon CloudWatch, AWS CloudTrail, AWS Config
Who can act, what should be recorded, and how will the team detect problems?
AWS also offers purpose-built services for analytics, machine learning, messaging, and migration. These extend the foundation for specific workflows; select them when the workload needs their capabilities rather than treating them as a default stack.
Choose compute for the amount of control you need
Compute services run application code. The main trade-off is control over the runtime and capacity versus the operational work of maintaining them. AWS's compute decision guide compares virtual machines, containers, and serverless options.
Amazon EC2 for virtual servers
Amazon EC2 provides virtual machines that you configure with an operating system, instance type, storage, and network access. Choose EC2 when software expects a server, needs operating-system control, or has a specific compute or memory profile. You are responsible for guest OS updates, application deployment, instance access, capacity planning, and recovery design. A single instance in one AZ is a single point of failure for that part of the workload.
Scale replaceable EC2 fleets with Auto Scaling
EC2 Auto Scaling can replace instances and adjust the size of a configured group as demand changes. Scaling helps only when the application can use added instances safely; keep durable state outside replaceable instances and test the behavior of deployments and failures. For instance types, AMIs, storage, and pricing, see our Amazon EC2 guide.
Containers with Amazon ECS, EKS, and Fargate
Containers package an application and its dependencies. Amazon ECS and Amazon EKS schedule and manage container workloads; ECS uses AWS's container orchestration APIs, while EKS provides a managed Kubernetes control plane. Both can use EC2 capacity or AWS Fargate. Fargate runs containers without requiring you to manage the underlying server fleet, but you still configure images, task or pod resources, networking, permissions, logging, and application scaling. Use Kubernetes when its APIs and ecosystem meet a real requirement; it brings additional operational concepts to manage.
AWS Lambda for event-driven code
AWS Lambda runs functions in response to supported events without requiring you to provision servers. It can fit short, event-driven processing and application endpoints, especially when request volume varies. Lambda reduces server management; it does not remove the need to design permissions, retries, timeouts, concurrency limits, dependencies, and downstream capacity. Its pricing is based on requests and execution duration, while connected services can add their own charges.
Choose storage by how the application reads and writes data
Object, block, and file storage expose different interfaces and semantics. They are not interchangeable meanings of “disk space.” AWS's storage decision guide summarizes the workload fit of each type.
Type
AWS examples
How applications use it
Object
Amazon S3
Store and retrieve named objects through AWS APIs or SDKs; useful for uploads, static assets, backups, and data sets.
Block
Amazon EBS
Attach a volume to compute and use it like a disk; useful for operating systems, application files, and database volumes.
File
Amazon EFS, Amazon FSx
Mount a shared file system when applications rely on file paths and file-system behavior, such as NFS or SMB.
Amazon S3 for object storage
Amazon S3 stores objects in buckets. An object has data, metadata, and a key; a key can look like a folder path, but S3 is accessed through an API and is not a general-purpose mounted file system. Use it when an application can store and retrieve objects, such as customer uploads, exports, static assets, backups, and analytics data.
S3 storage classes have different access, availability, retrieval, and minimum-duration characteristics. Choose one using the application's access pattern and recovery needs, not the storage price alone. See AWS's current S3 storage class guidance. For a practical EC2, EBS, and S3 walkthrough, see our guide to using EC2 and S3 together.
Archive with S3 Glacier storage classes
S3 Glacier is a family of S3 storage classes for less frequently accessed data. S3 Glacier Instant Retrieval supports real-time reads; Flexible Retrieval and Deep Archive store objects in archive tiers that must be restored before reading. Retrieval time, minimum storage duration, and retrieval charges vary by class, so match the class to how quickly you may need the data back. Archived copies still need appropriate retention and restore testing. AWS lists the current S3 Glacier class behavior and trade-offs.
Amazon EBS for block storage
Amazon EBS provides block volumes for use with EC2. A volume behaves like a disk after the operating system formats it, and remains a separately managed resource with its own lifecycle and charges. EBS volumes are scoped to an AZ; snapshots provide a backup mechanism, but they do not replace a restore test. Check attachment, deletion, and snapshot settings when planning instance replacement or cleanup.
Amazon EFS and Amazon FSx for file storage
Use a file service when software expects directories, mounted paths, and shared file access. Amazon EFS provides a managed NFS file system commonly used by Linux workloads. Amazon FSx offers managed file systems for particular protocols and software needs, including Windows file shares. Pick the service by protocol, compatibility, performance, and access pattern; a file system has different costs and behavior from an S3 bucket or EBS volume.
Choose a database from the data model and access patterns
A managed database reduces some infrastructure operations, but it does not choose a schema, make queries efficient, or decide the recovery point your application can accept. Start with transactions, relationships, query patterns, consistency needs, and recovery objectives. AWS's database decision guide compares purpose-built options.
Amazon RDS for managed relational databases
Amazon RDS manages supported relational database engines. A relational database is a natural fit when the application relies on SQL, relationships, constraints, or transactions across related records. Choose an engine and deployment based on compatibility, query behavior, recovery requirements, and cost.
RDS automates parts of database provisioning and maintenance. You still configure database accounts and network access, plan backups and retention, and validate that the application reconnects and recovers as intended. Multi-AZ deployments support availability across zones; they are not a substitute for a tested backup and restore plan.
Amazon Aurora as an RDS engine option
Amazon Aurora is a managed relational database engine offered through Amazon RDS, with MySQL-compatible and PostgreSQL-compatible editions. Compatibility does not mean the engines have identical features, versions, or operating characteristics; check application compatibility and the supported features in your Region before choosing it.
Amazon DynamoDB for key-value and document data
Amazon DynamoDB is a managed key-value and document database. It can suit workloads that can be expressed through known key-based access patterns. Table keys, indexes, consistency settings, and capacity mode shape how the application queries data, responds to changes in demand, and incurs cost. DynamoDB is not a drop-in replacement for a relational database when the application depends on joins or flexible ad hoc SQL queries.
Use a cache only for a defined access pattern
An in-memory cache such as Amazon ElastiCache can reduce repeated reads or support a low-latency access pattern. A cache adds decisions about expiration, invalidation, stale data, failover, and cost. Treat it as a derived copy of data unless the application has deliberately designed it to own state.
Choose analytics services by the data workflow
Analytics services answer different questions at different stages. Amazon S3 often holds source data, but querying files, preparing datasets, running distributed frameworks, and processing an event stream are separate jobs.
Use Athena for queries and Redshift for warehouse workloads
Amazon Athena runs SQL queries against data in S3 in place, which can fit interactive analysis without loading a copy into database tables. Amazon Redshift is a data warehouse for repeated analytical queries and reporting; it can also query data stored in S3. They are not exclusive choices: select based on query patterns, data layout, workload management, and cost, and measure the queries that matter.
Prepare and catalog data with AWS Glue
AWS Glue provides data integration capabilities for discovering, cataloging, preparing, and transforming data. Its Data Catalog holds metadata about data stored elsewhere; Glue jobs perform the actual reads and transformations. A crawler can infer metadata, but it does not validate business quality or transform the records. For a practical S3-to-Parquet batch job, see our AWS Glue tutorial.
Run Apache Spark or Hadoop jobs with Amazon EMR
Amazon EMR provides managed ways to run distributed data-processing frameworks such as Apache Spark and Hadoop. It can suit existing framework workloads that need those programming and execution models. EMR offers different deployment modes, so compare the control, scaling, and operational work of the mode you choose with a managed job service such as Glue.
Ingest and process streaming data
Amazon Kinesis Data Streams collects continuous records from producers so applications can consume them as a stream. For stateful stream processing and analysis, Amazon Managed Service for Apache Flink provides a managed processing runtime. Ingestion and processing remain separate decisions: consider retention, ordering, replay, delivery guarantees, and how consumers handle duplicates and failures. The older Amazon Kinesis Data Analytics for SQL service reached end of support on January 27, 2026; AWS lists it among services in full shutdown.
Machine learning is another workload area, with different services for applications built around foundation models and for developing or customizing models. AWS's current Amazon Bedrock or Amazon SageMaker AI guide explains where those services differ and when they can be used together.
Connect services with VPC networking and content delivery
A VPC is a logically isolated virtual network that you define. It has subnets, route tables, and gateways; each subnet belongs to one AZ. A subnet is public when its associated route table has a route to an internet gateway. Individual resources also need suitable public addressing and network rules to communicate with the internet. A common web design places an internet-facing load balancer in public subnets and keeps application and database resources in private subnets. See AWS's guide to adding internet access to a subnet.
Security groups control traffic to network interfaces. A NAT gateway can let resources in private IPv4 subnets initiate outbound internet connections without accepting unsolicited inbound connections, but it adds hourly and data-processing charges. VPC endpoints provide private connectivity to supported AWS services; the endpoint, IAM, resource, and network policies still need to allow the request. In every design, both a network path and permission must be present: an IAM policy does not create a route, and a route does not grant access to data.
For public web content, Amazon CloudFront can cache and deliver content closer to viewers. A common design uses a private S3 bucket as the origin and Origin Access Control (OAC) to let the distribution read it. Follow AWS's current guide to restrict access to an S3 origin rather than assuming that a public bucket is required.
Secure identities, data, and service configuration
Use identities and permissions deliberately
AWS Identity and Access Management (IAM) policies determine which actions an identity can perform on which resources and under what conditions. Use IAM Identity Center or a federated identity provider for workforce access, and IAM roles with temporary credentials for workloads where supported. Limit each permission set or role to the actions the person or application needs. Avoid putting long-lived access keys in application code or on EC2 instances. AWS maintains current IAM security best practices.
Apply the shared responsibility model to each service
AWS protects the facilities and foundational infrastructure that run its services. Customers remain responsible for how they configure services and use them: protecting credentials, setting access rules, handling and classifying data, and meeting their own legal and compliance obligations. On EC2, that includes the guest operating system and installed software. On a managed service, AWS operates more of the stack, but the customer still chooses data, permissions, retention, and application safeguards. “Managed” describes an operating boundary; it is not a guarantee that an application is secure or compliant.
Add security services for specific controls
Some workloads need additional controls with distinct jobs. AWS Key Management Service (AWS KMS) manages cryptographic keys and their access policies for supported integrations; choose key settings to match data protection and control requirements. AWS WAF evaluates HTTP(S) requests against rules you configure for supported web resources. Amazon GuardDuty analyzes supported AWS data sources and logs to produce threat findings. These services complement sound identity and application design: WAF is not a fix for vulnerable code, and GuardDuty findings still need an investigation and response process. See the current AWS KMS concepts, AWS WAF behavior, and GuardDuty overview.
Operate and monitor the workload
Amazon CloudWatch for application and resource signals
Amazon CloudWatch collects metrics and logs from supported AWS resources and applications. Teams use them to inspect workload behavior, create alarms, and investigate operational issues. Decide which signals indicate user impact and make sure the application emits useful logs; collecting data by itself does not establish that the service is healthy.
AWS CloudTrail for account activity
AWS CloudTrail records supported AWS account activity and API calls, which helps answer who made a change, when it happened, and through which identity. Logging scope, event types, destination, retention, and associated charges depend on configuration. CloudTrail serves an audit role, while CloudWatch is commonly used for application and resource monitoring.
AWS Config for resource history and rules
AWS Config can record supported resource configurations and evaluate them against rules. It helps teams review configuration history and identify resources that do not match defined requirements. Config findings need an owner and remediation process; the service does not make every resource compliant automatically.
Track cost drivers before optimizing
Pay-as-you-go pricing gives flexibility, but it does not mean AWS will always cost less than another option or that only active compute is billed. Charges depend on the service and its meter: compute time, provisioned database capacity, storage, requests, snapshots, retrieval, public IPv4, NAT processing, and data transfer can all matter. Estimate the workload before launch, then review actual usage as the application changes.
AWS Cost Explorer helps analyze historical and current cost and usage, and can create forecasts. AWS Budgets can alert when actual or forecast spending reaches a threshold; a budget is an alerting tool, not a hard spending cap. Use the Cost Explorer guide, AWS Budgets documentation, and the AWS Pricing Calculator to plan and review costs.
A practical web application path
Consider a small web application that serves pages, accepts requests, and stores customer data. One possible design is:
Deliver content: CloudFront serves cacheable static assets from a private S3 bucket. Dynamic requests go to an application endpoint.
Run code: the application runs on EC2, containers, or Lambda, chosen by runtime needs and the team's capacity to operate it. An Application Load Balancer is useful for web targets that need HTTP routing and health checks.
Keep data in the right place: use RDS or Aurora for relational transactions, DynamoDB for key-based access patterns, and S3 for uploaded objects. Use EBS for instance disks; add shared file storage only if the application needs file-system semantics.
Control access and observe behavior: use workload roles for AWS API calls, restrict network paths, and send application signals to CloudWatch. Record account activity with CloudTrail and decide whether configuration history or rules from Config are needed.
This is an example, not a checklist. A static site may need no application server; a queue-driven worker may have no public load balancer; a relational data model may not fit DynamoDB. Our 3-tier architecture guide shows how presentation, application, and data responsibilities can map to AWS while keeping logical tiers distinct from subnet boundaries.
Build from the smallest useful set of services
Begin with the application's runtime, data model, and required access paths. Then choose services that fit those needs, assign clear operational ownership, estimate their full cost, and test the recovery behavior the workload requires. Expand the design when a measured or documented need calls for another service; a smaller, well-understood set of components is easier to operate than a catalog assembled without a workload in mind.