7 questions foundWhat are the core categories of AWS services that every cloud beginner should understand before diving into any specific service?
Beginner The core categories include compute services like EC2 and Lambda for running application logic, storage services like S3 and EBS for storing data, database services like RDS and DynamoDB for structured data storage, networking services like VPC for isolating and connecting resources, and security and identity services like IAM for controlling who can access what, and understanding how these broad categories fit together provides the foundation needed before diving deeply into any individual service.
// A typical simple web application uses services from each category:
// EC2 (compute), RDS (database), S3 (storage), VPC (networking), IAM (security)
Real-world example A newcomer to AWS starts by understanding that a typical web application needs compute to run code, a database to store data, storage for files, networking to connect everything securely, and identity management to control access, before learning the specifics of any individual service.
Common follow-ups: Which AWS service should a complete beginner learn first?;How do these core services typically work together in a real application?
EC2 & Compute;IAM
How do compute, storage, database, and networking services typically work together in a simple three tier web application architecture?
Beginner In a typical three tier architecture, a networking layer built with VPC defines isolated private and public subnets, a compute layer using EC2 instances or containers runs the actual application code within those subnets, a database layer using RDS stores structured application data securely in private subnets, and a storage layer using S3 holds static assets like images, with all of these layers connected together through carefully configured security groups and routing rules that control exactly how traffic flows between them.
// Simplified three tier flow
// Public subnet: Load Balancer
// Private subnet: EC2 application servers
// Private subnet: RDS database
Real-world example A startup building its first production application places its EC2 web servers in a public facing subnet behind a load balancer, while keeping its RDS database in a private subnet completely inaccessible from the public internet, following the standard three tier architecture pattern.
Common follow-ups: Why is it a best practice to keep a database in a private subnet rather than a public one?;How does this basic three tier pattern evolve as an application scales?
VPC & Networking;RDS & Databases
How does understanding the AWS shared responsibility model help clarify which security and operational tasks are AWS's responsibility versus the customer's responsibility?
Intermediate The shared responsibility model divides responsibility between AWS being responsible for security of the cloud, meaning the physical infrastructure, hardware, and foundational services, while customers are responsible for security in the cloud, meaning properly configuring their own resources, managing access permissions, encrypting sensitive data, and patching their own operating systems and applications running on services like EC2, and misunderstanding this division is a common cause of security misconfigurations.
// AWS responsibility: physical data centers, host OS patching for managed services
// Customer responsibility: IAM permissions, security group rules, data encryption choices
Real-world example A company assumes AWS automatically secures their S3 bucket permissions, only to discover through a security audit that properly configuring bucket policies to prevent public access was actually their own responsibility under the shared responsibility model, not something AWS handles automatically.
Common follow-ups: How does the division of responsibility change between using EC2 versus a fully managed service like RDS?;What resources are available to help understand exactly where the responsibility boundary lies for a specific service?
IAM;S3 & Storage
How should a beginner decide between using a serverless service like Lambda versus a traditional compute service like EC2 for a new application?
Intermediate The decision typically depends on factors such as how predictable and consistent your workload is, with Lambda being well suited for event driven, intermittent, or unpredictable workloads since you only pay for actual execution time, while EC2 makes more sense for long running, steady state applications, workloads requiring specific operating system level control, or applications that need to maintain persistent in memory state across requests that a stateless Lambda function cannot easily provide.
// Lambda: good fit for infrequent, event driven processing
// EC2: good fit for a continuously running web server with steady traffic
Real-world example A developer building an infrequently used image processing function that only runs when a new file is uploaded chooses Lambda for its pay per use pricing, while choosing EC2 for their continuously running, steady traffic main web application.
Common follow-ups: What are the cost tradeoffs between Lambda and EC2 for a workload with steady, predictable traffic?;Are there workloads that genuinely cannot run on Lambda at all?
Lambda & Serverless;EC2 & Compute
What role does the AWS Well-Architected Framework play in guiding decisions across all of these core services as an application grows in complexity?
Intermediate The Well-Architected Framework provides a structured set of questions and best practices across pillars such as security, reliability, performance efficiency, cost optimization, operational excellence, and sustainability, helping teams evaluate their use of core services like EC2, S3, and RDS against established best practices, ensuring that as an application grows more complex, architectural decisions remain grounded in proven principles rather than being made in an ad hoc, inconsistent manner.
// Well-Architected review questions include:
// 'How do you manage identities for people and machines?'
// 'How do you monitor your workload to detect issues?'
Real-world example A growing engineering team conducts a Well-Architected Framework review of their application after six months in production, using its structured questions to identify that they had never configured Multi-AZ redundancy for their RDS database, a significant reliability gap they promptly corrected.
Common follow-ups: How often should a Well-Architected review be conducted as an application evolves?;Which of the six pillars is most commonly overlooked by teams new to AWS?
Well-Architected Framework;RDS & Databases
How do experienced architects approach selecting the right combination of core AWS services when designing a new, complex system from scratch?
Advanced Experienced architects typically start by clearly defining the specific functional and non functional requirements, such as expected traffic patterns, latency tolerance, data consistency needs, and compliance requirements, then evaluate which combination of core services best satisfies those requirements while balancing tradeoffs like operational complexity, cost, and long term maintainability, often preferring managed services that reduce operational burden unless a very specific requirement genuinely demands more granular control over the underlying infrastructure.
// Example requirement driven decision process
// High write throughput + flexible schema -> DynamoDB over RDS
// Complex multi table joins + strong consistency -> RDS over DynamoDB
Real-world example An architect designing a new system carefully evaluates that their application's need for complex multi table joins and strong transactional consistency makes RDS a better fit than DynamoDB, despite DynamoDB's appeal for other, higher throughput parts of the same overall system.
Common follow-ups: How do you balance choosing the technically best service against a team's existing familiarity and expertise?;What role does total cost of ownership play in these architectural decisions beyond just the sticker price of each service?
Well-Architected Framework;Amazon DynamoDB
How does a mature organization's use of core AWS services typically evolve from an initial simple deployment toward a more sophisticated, resilient, multi account architecture over time?
Advanced A mature evolution typically starts with a single account running a simple architecture using a handful of core services, then progresses toward adding resilience through multiple Availability Zones and Auto Scaling, then toward separating environments into distinct AWS accounts under an AWS Organization for better isolation and governance, and eventually toward a fully mature setup incorporating comprehensive monitoring, automated security compliance through Config and Security Hub, and well established cost governance practices, reflecting lessons learned and increasing operational maturity as the organization and its AWS usage both grow.
// Maturity progression
// Stage 1: Single account, basic EC2 and RDS
// Stage 2: Multi-AZ, Auto Scaling added
// Stage 3: Multi account structure via AWS Organizations
// Stage 4: Full governance, monitoring, and cost optimization
Real-world example A company that started five years ago with a single EC2 instance and a single RDS database now operates a mature, multi account AWS Organization with comprehensive Config compliance rules, centralized logging, and well established cost governance, reflecting years of incremental architectural maturity.
Common follow-ups: What are common warning signs that an organization has outgrown its current single account architecture?;How do you plan and execute this kind of architectural evolution without significant disruption to existing production workloads?
AWS Organizations & Multi Account Strategy;Well-Architected Framework