Cloud Foundations on AWS

Transcript

1. CLOUD FOUNDATIONS Cloud Foundations on AWS From infrastructure to architecture COMPUTE STORE CONNECT PROTECT 01
2. What should you leave with? Not a service catalog. A mental model. 01 What cloud changes 02 How AWS is organized 03 How core building blocks fit 04 How to reason about a basic architecture 02
3. About me! Sena Yakut, Senior Security Engineer @Trendyol AWS Security Hero 03
4. The journey We will build the cloud picture one layer at a time. 1 2 3 4 5 6 Traditional IT Cloud AWS Building blocks Security Architecture 03
5. 01 From Traditional IT to Cloud Cloud changes the operating model before it changes the technology. 04
6. From procurement to API The biggest shift is how infrastructure is consumed. TRADITIONAL CLOUD Forecast capacity Request capacity Buy hardware Provision by API Rack & configure Scale with demand Wait weeks / months Pay for usage 05
7. Elasticity ≠ Scalability Related ideas, different questions. SCALABILITY ELASTICITY Can the system handle growth? Can capacity expand and contract with demand? Scale up or scale out as demand increases. Add when needed. Release when not. Cloud makes capacity a variable, not a purchase order. 06
8. How much do you want to manage? Service models are really abstraction choices. IaaS PaaS SaaS More control More abstraction Consume the product VMs · Networks · Storage Runtime · Managed platform Complete application 07
9. 02 Understanding AWS Geography is part of architecture. 08
10. AWS → Region → Availability Zone A simple hierarchy with big architectural consequences. AWS REGION AZ 1 AZ 2 RESOURCES AZ 3 EC2 RDS ALB 09
11. Choosing a Region There is no single 'best' Region. Latency Closer to users Resilience DR strategy Compliance Data & regulation Services Feature availability Cost Regional pricing 10
12. Design for failure One Availability Zone should not be your whole application. AVAILABILITY ZONE 1 AVAILABILITY ZONE 2 APPLICATION APPLICATION DATABASE / REPLICA DATABASE / REPLICA Redundancy is a design choice. 11
13. 03 Compute Different abstractions, same question: where does the application run? 12
14. Amazon EC2 A virtual server you can shape around the workload. AMI Template OS + software INSTANCE CPU + memory Your virtual server SECURITY Network access Security Group EC2 gives flexibility, but you manage more of the stack. 13
15. Traffic changes. Capacity should too. Load balancing distributes. Auto Scaling adjusts. EC2 #1 AUTO SCALING USERS LOAD BALANCER EC2 #2 Add capacity when demand rises. Remove it when demand falls. EC2 #3 14
16. Virtual machines → Containers → Serverless Move the management boundary, not the business problem. EC2 ECS / EKS Lambda Virtual machines Containers Serverless More infrastructure control Package & orchestrate apps Run code on demand 15
17. Which compute should I reach for? Choose the abstraction that matches the workload. EC2 ECS / EKS Lambda USE IT FOR USE IT FOR USE IT FOR Legacy app migration Custom OS / agent Long-running backend Microservices Containerized APIs Portable app runtime File processing API handlers Scheduled automation NOT THE BEST FIT NOT THE BEST FIT NOT THE BEST FIT Tiny event-driven jobs Simple one-off functions Always-on server workloads Ask first: how much infrastructure do I actually need to manage? 37
18. 04 Storage Object, block, and file storage solve different problems. 16
19. S3 vs EBS vs EFS Start with the access pattern. S3 OBJECT Files, logs, backups, assets, data lakes EBS BLOCK Persistent volumes for EC2 EFS FILE Shared filesystem for multiple clients 17
20. Amazon S3 Buckets contain objects. The simplicity is the superpower. image.jpg FOUNDATIONAL IDEAS Durability BUCKET logs/ Storage classes backup.zip Versioning Encryption & access 18
21. Where should this data live? The access pattern usually answers the storage question. Amazon S3 Amazon EBS Amazon EFS USE IT FOR USE IT FOR USE IT FOR Images & videos Backups & archives Logs & static assets EC2 boot volume Application disk Persistent block storage Shared filesystem Multiple compute clients Linux file workloads NOT THE BEST FIT NOT THE BEST FIT NOT THE BEST FIT EC2 operating-system disk Shared storage across many hosts Massive object collections 38
22. Use case: photo upload pipeline Serverless shines when work begins with an event. USER S3 UPLOAD LAMBDA RESIZE / SCAN S3 OUTPUT No server needs to sit idle waiting for the next image. Event → compute → result 40
23. 05 Networking Build an isolated network, then decide what may talk to what. 19
24. The VPC mental model Public and private are routing decisions. VPC 10.0.0.0/16 AZ 1 AZ 2 PUBLIC PRIVATE PUBLIC PRIVATE ALB APP ALB APP 20
25. A safer request path Expose the entry point, not every workload. INTERNET ALB APP DATABASE Public edge → private application → private data 21
26. 06 Databases Managed services trade infrastructure work for service-level abstractions. 22
27. Relational or NoSQL? Choose from the data model and access pattern. AMAZON RDS Relational databases SQL-oriented workloads Backups · Multi-AZ · replicas AMAZON DYNAMODB NoSQL key-value / document Managed scaling Low operational overhead 23
28. 07 Identity & Access Every request begins with an identity and ends with an authorization decision. 24
29. WHO → can do WHAT → on WHICH RESOURCE This is the IAM mental model. WHO WHAT IAM Role RESOURCE s3:GetObject Specific S3 bucket Least privilege = only the access required for the job. 25
30. Prefer roles over embedded credentials Temporary credentials shrink the credential problem. WORKLOAD IAM ROLE AWS SERVICE No hard-coded long-lived access key required. 26
31. 08 Security Cloud security is shared, but responsibility never disappears. 27
32. Shared Responsibility Model The boundary moves depending on the service. AWS CUSTOMER Security OF the cloud Security IN the cloud Facilities · hardware · foundational infrastructure Identity · data · configuration · applications 28
33. Four security questions Map services to problems, not memorization. KMS How do we manage encryption keys? GuardDuty What suspicious activity is happening? WAF What web requests should be blocked? Inspector Where are workload vulnerabilities? 29
34. CloudWatch vs CloudTrail Operational visibility and audit visibility answer different questions. AMAZON CLOUDWATCH AWS CLOUDTRAIL What is happening to my systems? Who did what in my AWS environment? Metrics · logs · alarms AWS API activity 30
35. Use case: who changed the bucket? Operational monitoring and audit history are different tools. ADMIN / ROLE CloudTrail WHO changed it? Which API call? CloudWatch Is the system unhealthy? Should an alarm fire? Change S3 policy 41
36. 09 Putting It Together The services matter less than the relationships between them. 31
37. A basic highly available AWS application Everything we introduced now has a place. VPC S3 APPLICATION LOAD BALANCER USERS ROUTE 53 IAM AZ 1 AZ 2 APP / EC2 APP / EC2 CW RDS RDS CT 32
38. Use case: an e-commerce application Now the resource names map to jobs. USERS Route 53 ALB EC2 / ECS RDS S3 Product images IAM Service access CloudWatch Logs & alarms Orders → relational data → RDS Product assets → objects → S3 39
39. Well-Architected is a way of thinking A working system is only the beginning. 1 2 3 4 5 6 Operational Excellence Security Reliability Performance Efficiency Cost Optimization Sustainability Can we operate it, secure it, recover it, scale it, and afford it? 33
40. From Building Servers to Building Systems The mental model to keep. COMPUTE Run STORAGE Store NETWORK Connect & isolate DATABASE Manage data IAM Control access SECURITY Protect MONITORING Observe 34
41. A quick resource decision map You do not need to memorize 200+ services. Run a traditional / custom server workload EC2 Run containerized microservices ECS / EKS React to an event with short-lived code Lambda Store files, backups, logs, media S3 Give an EC2 instance persistent disk EBS Share a filesystem across compute EFS Store relational application data RDS Control what a workload can access IAM Role See metrics, logs, alarms CloudWatch Audit AWS API activity CloudTrail 42
43. Five things to remember 01 Cloud is an operating model, not just a remote data center. 02 AWS architecture is built from a small set of foundational concepts. 03 High availability and security are design decisions. 04 Managed services reduce work, not responsibility. 05 Understand how the pieces fit. Do not memorize the catalog. 35
44. Questions? Cloud Foundations on AWS 36