Cloud Technology and Services
Organizing the catalog
Group services by job. Compute: EC2 (instance families tuned for general purpose, compute, memory, storage, accelerated), Lambda (serverless functions), ECS/EKS with Fargate (containers), Elastic Beanstalk (platform that deploys your app). Storage: S3 (object, virtually unlimited), EBS (block volumes for one instance, tied to an Availability Zone), EFS (shared file system for Linux), Glacier classes (archive), Storage Gateway (hybrid). Databases: RDS and Aurora (managed relational), DynamoDB (serverless NoSQL key-value), Redshift (analytics warehouse). Networking: VPC with public and private subnets, security groups and network ACLs, Elastic Load Balancing, Route 53 (DNS), CloudFront (CDN), Direct Connect and Site-to-Site VPN (hybrid links). Management: CloudFormation (infrastructure as code), CloudWatch, Trusted Advisor.
Traps that decide questions
- Security groups are stateful and allow-only; network ACLs are stateless and support allow and deny, evaluated in numbered order.
- S3 is object storage - you cannot mount it as a disk. EBS attaches to one instance in one Availability Zone; EFS is shared across many.
- DynamoDB is not relational; if the stem says joins or SQL, pick RDS/Aurora.
- CloudFront caches content at edge locations; it is not a load balancer.
- CloudFormation provisions infrastructure; it does not monitor it.
Worked example
A team must store compliance backups for seven years, rarely read, and retrieval within 12 hours is acceptable. Match the access pattern to a storage class: S3 Glacier Deep Archive, the lowest-cost archive tier. If the requirement were millisecond access to frequently used data, Standard would win. Cheapest is only correct when retrieval time allows it.
Rule of thumb: choose a service by its access pattern, durability, and management burden rather than by name recognition. Object = S3, block = EBS, file = EFS, relational = RDS/Aurora, key-value at scale = DynamoDB, warehouse = Redshift.