Architecture Stack: AWS Fundamentals

This is a conversation between Alex (Engineering Manager) and Jordan (Senior Architect) exploring AWS fundamentals as the foundation for modern platform delivery, covering compute, storage, and networking services that enable scalable systems.

Part 1: The Shift from On-Premises to Cloud

Alex: "Jordan, we've designed amazing systems in L1. But where does all this live? I mean, physically, where are the servers?"

Jordan: "That's where L2 comes in. Platform Delivery. How we actually run everything. And for most companies, that means AWS."

Alex: "AWS?"

Jordan: "Amazon Web Services. The cloud infrastructure provider. Instead of owning physical servers in a data center, we rent compute power, storage, and networking from AWS."

Alex: "Why not own servers?"

Jordan: "Because it's expensive and complex. You have to:

Buy servers (capital cost upfront)
Set up power, cooling, fire suppression
Install networking hardware
Maintain and replace hardware as it fails
Scale up when you need more capacity
Scale down if capacity goes unused (wasted money)"

Alex: "That's a lot of operational overhead."

Jordan: "Exactly. AWS handles all that. You say 'I need 10 servers'. AWS spins them up in minutes. You say 'I need less'. They spin down. You pay only for what you use."

Alex: "That's better?"

Jordan: "Much better. It's called cloud computing."

Part 2: What Is AWS?

Alex: "But AWS is huge. Where do we start?"

Jordan: "Think of AWS as a massive toolkit of services. Instead of building everything from scratch, you rent pre-built components."

Alex: "Like what?"

Jordan: "Compute (servers). Storage (databases, file systems). Networking (load balancers, firewalls). Monitoring (alerting, logging). Security (encryption, access control). Hundreds of services."

Alex: "How do we organize that?"

Jordan: "The core services sit on three pillars:

Compute: Where your applications run. EC2 (virtual servers), ECS (container orchestration), Lambda (serverless functions), Fargate (managed containers).

Storage: Where your data lives. S3 (object storage), EBS (block storage for databases), RDS (managed relational databases), DynamoDB (NoSQL), EFS (file systems).

Networking: How services communicate. VPC (virtual network), ALB (load balancer), CloudFront (CDN), Route 53 (DNS)."

Alex: "That's just compute, storage, and networking?"

Jordan: "Those three are foundational. Everything else builds on top of them. Once you understand those, the rest makes sense."

Part 3: Why AWS Instead of On-Premises?

Alex: "What are the concrete advantages?"

Jordan: "Several:

Scalability: Need to handle 10x traffic spike? Add more capacity instantly. With on-premises, you'd need to buy hardware, ship it, rack it, configure it. Takes weeks or months.

Cost Efficiency: You pay for what you use. No capital investment. No wasted capacity. If traffic drops, you scale down and save money. With servers you own, costs are fixed regardless.

Geographic Distribution: AWS has data centers (regions) around the world. Run your application in Europe, Asia, North America simultaneously. Users get low latency everywhere. With owned servers, you'd need to operate data centers globally.

Reliability: AWS handles redundancy, backups, disaster recovery. Hardware fails? AWS replaces it. Your data is protected. You don't worry.

Speed to Market: Instead of spending 6 months procuring and setting up infrastructure, you launch in hours. Competitive advantage.

Security & Compliance: AWS invests billions in security. Compliance certifications (SOC2, PCI-DSS, HIPAA). Hard to match with on-premises infrastructure."

Alex: "So it's not just technology, it's business agility?"

Jordan: "Exactly. Cloud is about speed and flexibility, not just infrastructure."

Part 4: The Traditional Approach (On-Premises Data Centers)

Alex: "What did companies do before cloud?"

Jordan: "Owned and operated data centers. Bought servers, stored them in rented warehouse space, connected them to the internet. Hired teams to maintain hardware, manage cooling, handle security."

Alex: "How big are we talking?"

Jordan: "Large companies might have multiple data centers, each with thousands of servers. Staffing costs were enormous. Capital costs were enormous. Operational complexity was enormous."

Alex: "What were the problems?"

Jordan: "Inflexibility. Capacity planning was a nightmare. Predict demand 12 months out. Buy servers. Deploy. If demand is less than expected, you wasted money. If demand exceeds, you can't scale fast enough. Boom or bust."

Alex: "No middle ground?"

Jordan: "Not really. And disasters were catastrophic. A data center fire? Years of data loss. Had to have redundant data centers, which doubled costs."

Alex: "So cloud solved these problems?"

Jordan: "Completely. You get flexibility (scale up/down instantly), reliability (AWS handles redundancy), and cost efficiency (pay per use)."

Part 5: AWS Compute Services

Alex: "Let's get specific. What are the compute options?"

Jordan: "Several approaches:

EC2 (Elastic Compute Cloud): Traditional virtual servers. You pick the size (CPU, RAM, disk), choose an operating system, run applications. Full control but you manage updates, security patches, configurations.

ECS (Elastic Container Service): Container orchestration. You provide Docker containers, ECS manages where they run. Simpler than managing individual servers but you still configure.

EKS (Elastic Kubernetes Service): Kubernetes on AWS. Industry-standard container orchestration. Powerful but complex. We use this.

Lambda: Serverless compute. You upload code. AWS runs it when needed. You don't think about servers at all. Great for event-driven workloads.

Fargate: Managed containers. Kubernetes abstracts servers. Fargate abstracts even more. You say 'run this container', Fargate handles everything."

Alex: "Which do we use?"

Jordan: "EKS for our main services. Kubernetes gives us control and flexibility. Lambda for background jobs and event processors."

Alex: "Why Kubernetes instead of just Fargate?"

Jordan: "Kubernetes is portable. If we ever need to move off AWS, Kubernetes works on any cloud. Fargate is AWS-specific lock-in."

Part 6: AWS Storage Services

Alex: "What about data storage?"

Jordan: "Multiple tiers:

S3 (Simple Storage Service): Object storage. Upload files, get a URL. Durable, cheap, scalable. Good for user-generated content, backups, logs.

EBS (Elastic Block Store): Block storage. Attach to EC2 instances. Like a hard drive. For databases, application data, anything that needs fast disk I/O.

RDS (Relational Database Service): Managed databases. PostgreSQL, MySQL, Oracle. AWS handles backups, updates, failover. You just connect and query.

DynamoDB: NoSQL database. Fast, scalable, pay-per-request. Good for high-volume transactional data (user sessions, carts, real-time counters).

EFS (Elastic File System): Shared file system. Multiple servers can access same files. Like a network drive.

Glacier: Archive storage. Very cheap but slow access. For data you rarely need but must keep (compliance)."

Alex: "So there's a hierarchy?"

Jordan: "Yes. S3 is cheap but slow. EBS is faster but more expensive. RDS/DynamoDB are databases with built-in optimization. Pick based on access patterns."

Alex: "How do we decide which?"

Jordan: "Ask: What's my access pattern? If I rarely access it (archives), Glacier. If I need millisecond access (databases), DynamoDB or RDS. If I'm storing files, S3. If I need a shared filesystem, EFS."

Part 7: AWS Networking Services

Alex: "How do services talk to each other?"

Jordan: "Through AWS networking services:

VPC (Virtual Private Cloud): Your isolated network on AWS. Think of it as a walled-off slice of AWS infrastructure. You define subnets, security groups, routing.

ALB (Application Load Balancer): Distributes traffic across servers. User requests come to ALB. ALB decides which server handles it. Enables high availability and scaling.

Security Groups: Firewalls. Define which traffic is allowed. Service A can talk to Service B, but not C. Port 443 is open, port 22 is closed.

Route 53: DNS (Domain Name System). Maps ravinvasudev.com to AWS load balancer IP. Users type domain, Route 53 directs them.

CloudFront: CDN (Content Delivery Network). Cache content at edges globally. Users download from nearest edge, super fast.

NAT Gateway: Allows private servers to reach the internet without being directly accessible from internet."

Alex: "That's complex."

Jordan: "It is. But most platforms abstract this. You don't manually configure firewalls. Tools do it for you."

Part 8: Regions, Availability Zones & Resilience

Alex: "You mentioned AWS has multiple data centers?"

Jordan: "Yes. AWS is organized into regions (geographic areas) and availability zones (separate data centers within regions)."

Alex: "Why?"

Jordan: "Resilience and latency. If one data center fails, others in the region are unaffected. For global reach, you replicate in multiple regions. Users in Europe connect to European region, getting low latency."

Alex: "How many regions?"

Jordan: "Over 30 worldwide and growing. US East, US West, Europe, Asia, Middle East, South America."

Alex: "Do we use multiple regions?"

Jordan: "For production, yes. We run in at least two availability zones in our primary region (auto-failover). For disaster recovery, we replicate to another region. If primary region fails, users failover to secondary."

Alex: "That sounds expensive?"

Jordan: "It is. But downtime is more expensive. Business continuity is worth the investment."

Part 9: Implementation Strategy

Alex: "How do we actually use AWS?"

Jordan: "First, you decide: what compute, storage, and networking do I need?

For microservices: EKS for container orchestration, RDS for databases, S3 for files, ALB for load balancing, VPC for networking.

For serverless: Lambda for functions, DynamoDB for data, API Gateway for APIs, CloudWatch for logging.

For data processing: S3 for raw data, EC2 for processing, RDS for results.

Then you configure everything: Define VPC, create subnets, set security groups, launch instances/containers, configure load balancer, set up DNS, enable monitoring."

Alex: "That's manual work?"

Jordan: "It can be. But that's where Infrastructure-as-Code (IaC) comes in. Instead of clicking AWS console, you write code (Terraform, CloudFormation) that defines your infrastructure. Version control it, deploy it, manage it like code."

Alex: "We'll talk about IaC in L3?"

Jordan: "Exactly. L2 is 'what services do you use'. L3 is 'how do you define and manage them'."

Part 10: Managed vs Unmanaged Services

Alex: "I notice some services are 'managed' (RDS, Fargate) and some aren't (EC2, EBS)?"

Jordan: "Good observation. Managed services handle operations for you. RDS: AWS manages backups, patches, failover. You just connect and query."

Alex: "What's the downside?"

Jordan: "Less control. You can't tune every setting. And sometimes lock-in: RDS is AWS-specific. EC2 is more flexible: you can run any OS, any software."

Alex: "So it's a trade-off?"

Jordan: "Yes. Managed services are faster to deploy but less flexible. Unmanaged are more flexible but require more effort. Choose based on needs."

Alex: "For databases?"

Jordan: "RDS is the default. Most companies don't need the flexibility of self-managed databases. AWS handles maintenance, leaving you to focus on application logic."

Part 11: Monitoring, Logging & Observability

Alex: "How do you know if services are healthy?"

Jordan: "AWS CloudWatch. Collects metrics, logs, and events from all services.

Metrics: CPU usage, memory, disk, network traffic. Dashboard shows in real-time.

Logs: Application output, error logs. Centralized storage for analysis.

Alarms: When metrics exceed thresholds, trigger alarms. Send SMS, email, or trigger automated actions."

Alex: "Do you need additional tools?"

Jordan: "CloudWatch is included with AWS but can be limited. Large companies use third-party monitoring (Datadog, New Relic, Splunk) for deeper insights."

Alex: "How detailed does monitoring get?"

Jordan: "Very. You can see metrics per service, per container, per request. With distributed tracing (Jaeger, AWS X-Ray), you can see request flow through 20 microservices end-to-end."

Part 12: Cost Management

Alex: "AWS billing is confusing, right?"

Jordan: "It can be. Hundreds of services, each with different pricing models. But principles are simple:

Compute: Pay per hour (EC2) or per invocation (Lambda) or per container (ECS/EKS).

Storage: Pay per GB stored per month.

Data Transfer: Pay to send data out of AWS (but not in).

Common mistake: Running servers 24/7 that aren't needed. Development/test environments left running. Unused storage accumulating.

Best practice: Turn off non-production when not in use. Delete old snapshots. Monitor unused resources. Right-size instances (don't pay for more CPU/RAM than needed)."

Alex: "How do teams control costs?"

Jordan: "Several approaches:

Reserved instances: Commit to 1-3 years, get discount.
Spot instances: Buy spare capacity cheaply, but AWS can reclaim it.
Auto-scaling: Scale down when traffic is low.
Tags and cost allocation: Tag resources by team/project, see who's spending what.
Regular audits: Monthly cost reviews, identify waste."

Alex: "It requires discipline?"

Jordan: "Yes. Cloud is pay-as-you-go. Without discipline, bills skyrocket."

Part 13: Security in AWS

Alex: "Is AWS secure?"

Jordan: "AWS invests more in security than any company can individually. But you need to configure it correctly. AWS follows 'shared responsibility model':

AWS responsibility: Infrastructure, hardware, network security, physical data center security.

Your responsibility: Access control (who can do what), encryption (encrypt sensitive data), network configuration (security groups), monitoring (detect intrusions)."

Alex: "What do we do?"

Jordan: "Best practices:

Enable MFA (multi-factor authentication) for all users.
Use IAM roles (not root accounts) with least-privilege access.
Encrypt data at rest and in transit.
Use VPCs to isolate networks.
Enable CloudTrail (audit logs of all actions).
Scan for vulnerabilities.
Assume breach (design as if attacker got in, minimize damage)."

Alex: "That's ongoing work?"

Jordan: "Absolutely. Security is continuous."

Part 14: When to Use AWS vs Alternatives

Alex: "Are there alternatives?"

Jordan: "Yes. Google Cloud Platform (GCP), Microsoft Azure, DigitalOcean, self-managed. AWS dominates though."

Alex: "Why?"

Jordan: "First-mover advantage. Most mature ecosystem. Most services. Most talent. Most case studies. Most documentation."

Alex: "So we use AWS by default?"

Jordan: "Unless you have a specific reason not to. Some organizations use Azure because they're Microsoft-heavy. GCP is good for ML/data. But AWS is the de facto standard for enterprise cloud."

Alex: "Is there a downside to AWS dominance?"

Jordan: "Vendor lock-in. AWS services are tightly integrated, making it hard to switch. But portability isn't a realistic concern for most companies. You pick AWS and commit."

Part 15: Bridging to Next Layer

Alex: "We've covered AWS services: compute, storage, networking. What's next?"

Jordan: "L2 continues with Kubernetes (orchestrating containers across AWS), ArgoCD (deploying applications), Helm (packaging applications), DevSecOps (automating security)."

Alex: "So AWS is the foundation, and Kubernetes sits on top?"

Jordan: "Exactly. AWS provides the raw infrastructure. Kubernetes is the orchestration layer that makes it manageable at scale."

Part 16: The Bottom Line

Alex: "If I pitch this to executives?"

Jordan: "AWS is the foundation of modern platforms. Instead of owning data centers, we rent flexible, scalable infrastructure that grows with our business. Compute scales instantly for traffic spikes. Storage is durable and globally accessible. Networking handles millions of simultaneous connections. We pay only for what we use, and AWS handles all the operational burden. This means our teams can focus on applications, not infrastructure."

Alex: "And the commitment?"

Jordan: "We're committing to cloud. No going back to on-premises. We're betting that cloud infrastructure is the future. The upside is massive agility and scalability."

Alex: "Ready for Kubernetes?"

Jordan: "Absolutely. Now that we understand the AWS infrastructure, let's see how to manage containers at scale."

Key Takeaways

| Aspect | Details | | ----------------------- | ------------------------------------------------------------------------------------------- | | Core Concept | Renting scalable compute, storage, and networking from AWS instead of owning data centers | | Primary Benefit | Instant scalability, cost efficiency, reliability, geographic distribution, speed to market | | Best For | Companies of all sizes, any workload type | | Main Challenge | Complexity of services, cost management, avoiding vendor lock-in | | Compute Tiers | EC2 (full control), ECS (container), EKS (Kubernetes), Lambda (serverless) | | Storage Tiers | S3 (objects), EBS (block), RDS/DynamoDB (databases), EFS (file), Glacier (archive) | | Network Foundations | VPC, ALB, Security Groups, Route53, CloudFront | | Resilience Strategy | Multiple availability zones, multi-region replication, managed services with failover |

L2 Series Progress

AWS Fundamentals (infrastructure foundation) ← You are here
Kubernetes & EKS (container orchestration)
ArgoCD (GitOps deployments)
Helm (application packaging)
DevSecOps (security automation)

Ready for the next L2 topic: Kubernetes & Container Orchestration (how to manage containers at scale)? Or go deeper into AWS?