qasim@wiki:~$

AWS — Architecture, Services & Security

This section documents production AWS work service by service — how each piece is configured, why, and how they compose into secure, highly available architectures. The reference architecture below is a real design pattern: a WAF-fronted, load-balanced, auto-scaling application tier with a managed database, monitoring, and alerting — the shape behind the high-traffic food-service platforms I run.

Reference Architecture — WAF + ELB + Auto Scaling

AWS Layer 3 architecture: clients and users reach an Application Load Balancer through a Web Application Firewall, traffic flows to an auto-scaling frontend/proxy/API tier behind security-group firewalls, backed by MariaDB with S3, and monitored with CloudWatch and SNS notifications
Production pattern: Client/User → WAF → Application Load Balancer (80/443) → auto-scaling Frontend + Proxy + API tier (443) → MariaDB (3306) with S3, monitoring, and notification services. Security groups enforce least-privilege between every tier.

How traffic flows through it

  1. Client / Users hit the public endpoint over HTTP/HTTPS (ports 80 and 443).
  2. Web Application Firewall (WAF) inspects requests for attack patterns before they reach anything that matters — SQLi, XSS, bad bots — using managed rule groups with scoped overrides.
  3. Application Load Balancer terminates TLS (certificate from ACM) and forwards to healthy targets. Listeners: HTTPS:443 and HTTP:80, each with a default rule forwarding to a target group.
  4. Auto Scaling group runs the Frontend + Proxy + API tier, scaling horizontally on load. Only port 443 is open from the ALB to this tier — a security-group boundary, not a network firewall.
  5. MariaDB sits in a private subnet reachable only on port 3306 from the app tier. S3 holds backups and static assets.
  6. Monitoring & Notification — CloudWatch metrics/alarms feed SNS, which fans out alerts. This is the observability spine of the whole design.
The security story in one line: every arrow in that diagram crosses a security-group boundary, public exposure is limited to the ALB alone, and the database is never reachable from the internet — only from the app tier, only on 3306.

Service Reference

#ServiceWhat it coversStatus
01AWS Landing ZoneMulti-account foundation, Organizations, guardrails.Planned
02IAMIdentity, roles, policies, least-privilege access.Planned
03VPCNetwork isolation, subnets, routing, gateways.Planned
04EC2Compute instances, AMIs, instance types.Planned
05EBSBlock storage, volumes, snapshots, encryption.Planned
06S3Object storage, lifecycle, replication, security.Planned
07ALBApplication Load Balancer, listeners, target groups.Planned
08Auto ScalingScaling policies, launch templates, health checks.Planned
09Route 53DNS, routing policies, health checks.Planned
10ACMCertificate management, TLS provisioning.Planned
11CloudWatchMetrics, alarms, logs, dashboards.Planned
12SNSPub/sub notifications, alert fan-out.Planned
13CloudTrailAPI audit logging, org-wide trails.Planned
14EventBridgeEvent routing, rules, automation triggers.Planned
15AWS ConfigResource compliance, config rules, drift.Planned
16Security HubSecurity posture aggregation, standards.Planned
17GuardDutyThreat detection, anomaly findings.Planned
18KMSEncryption keys, key policies, rotation.Planned
19Secrets ManagerSecret storage, rotation, retrieval.Planned
20Systems ManagerPatching, Session Manager, parameter store.Planned
21Backup StrategyAWS Backup, cross-region, retention.Planned
22Cost OptimizationRight-sizing, savings plans, anomaly detection.Planned
23AWS Security HardeningEnd-to-end account and workload hardening.Ready

Skills demonstrated across this section

VPC & network design IAM least-privilege ALB & Auto Scaling WAF tuning KMS encryption CloudWatch & SNS GuardDuty & Security Hub Cost optimization Backup & DR