Design high-performing architectures

Storage

Storage types

EBS volume types

• HDD volumes (st1, sc1) can’t be boot volumes. EBS is in one AZ, so snapshots (incremental, stored in S3) move data to another AZ or Region. Fast Snapshot Restore removes first-use latency. Volumes can be resized and retyped while attached. EBS-optimized instances give dedicated bandwidth to storage.
• Instance store is physically attached NVMe, giving the highest IOPS and lowest latency, but data is lost if the instance stops, fails or terminates. Use it for caches, buffers and scratch data, or for replicated systems that tolerate node loss.
• Performance needs more than 64,000 IOPS from one instance: stripe several volumes (RAID 0) or use an instance store.

EFS and FSx

• EFS vs EBS: EFS is shared across AZs and instances (a file system); EBS is one disk in one AZ. EFS vs S3: EFS is a mounted POSIX file system; S3 is an object API. EFS One Zone is cheaper with less resilience.

S3 performance

• S3 supports at least 3,500 write (PUT/COPY/POST/DELETE) and 5,500 read (GET/HEAD) requests per second per prefix, with no limit on the number of prefixes. Spread heavily used keys over several prefixes and parallelise.
• Multipart upload: recommended above 100 MB and required above 5 GB (max object 5 TB), uploads parts in parallel and retries single parts. Byte-range fetches parallelise downloads.
• S3 Transfer Acceleration speeds uploads from far-away clients by entering through the nearest edge location and travelling the AWS backbone. Use it when users upload to a distant bucket over the internet.
• CloudFront speeds repeated downloads. S3 Express One Zone is a single-AZ class with single-digit millisecond latency for the most latency-sensitive workloads.
• S3 is strongly consistent for reads after writes and listing. SSE-KMS requests count against KMS request quotas on very busy buckets (S3 Bucket Keys reduce this).

Hybrid and scalable storage

• AWS Storage Gateway connects on-premises to AWS storage with local caching: S3 File Gateway (NFS/SMB files stored as S3 objects), FSx File Gateway (low-latency on-prem access to FSx for Windows), Volume Gateway (iSCSI block volumes: cached keeps the data in S3 with hot data locally, stored keeps everything locally and backs up to S3) and Tape Gateway (virtual tape library replacing physical tapes).
• DataSync automates and speeds one-off or scheduled transfers between on-premises (NFS, SMB, HDFS), other clouds and S3, EFS, FSx, with verification and bandwidth control. Transfer Family exposes S3/EFS over SFTP/FTPS/FTP. Snow Family devices move data offline (check current availability for new orders). Direct Connect gives a steady high-bandwidth link.
• To scale for future needs choose services that grow without provisioning: S3 (unlimited), EFS (elastic), DynamoDB on-demand, Aurora storage (auto-grows to 128 TiB), RDS storage autoscaling.

Compute

EC2 instance families

• Suffix hints: g = Graviton (Arm, better price-performance, usually about 20% cheaper), d = local NVMe, n = enhanced networking, a = AMD. Nitro is the hypervisor and hardware platform, and EBS/network performance depends on instance size.
• Placement groups: cluster (one AZ, lowest latency and highest throughput between instances, for HPC and tightly coupled), spread (each instance on separate hardware, up to 7 per AZ per group, for a few critical instances), partition (groups on separate racks, for Kafka, Cassandra, HDFS). Enhanced networking (ENA) and Elastic Fabric Adapter (EFA) raise network performance for HPC and ML.
• Hibernation saves RAM to an encrypted EBS root volume, so a long-booting app resumes where it left off. Burstable T instances are cheap for low average CPU but throttle if credits run out (unlimited mode avoids it with extra charge).
• Right-size: use Compute Optimizer and CloudWatch to pick type and size. Memory and disk metrics need the CloudWatch agent.

Scaling

• EC2 Auto Scaling keeps the right number of instances across AZs from a launch template. Policy types:

• Warm pools hold pre-initialised instances for slow-starting applications. Lifecycle hooks run actions at launch and terminate. Mixed instances groups blend On-Demand and Spot across instance types.
• AWS Auto Scaling (the console plan) covers ECS, DynamoDB, Aurora replicas and Spot Fleets with the same target tracking idea. Application Auto Scaling is the API behind it.
• Identify scaling metrics from the bottleneck: CPU for compute-bound, ALBRequestCountPerTarget for web tiers, SQS queue depth per instance for queue workers, memory (custom metric) for memory-bound.
• Decouple so parts scale separately: SQS or Kinesis between web and worker tiers, caching in front of databases, static content on S3 and CloudFront.

Serverless, containers and batch

• Lambda performance: memory sets CPU (about 1,769 MB equals one vCPU), so raising memory often shortens runtime and can lower cost. Timeout up to 15 minutes. Cold starts matter for latency: use provisioned concurrency or SnapStart (Java, Python, .NET). Reserved concurrency caps and protects. Lambda in a VPC can reach private resources. For long or heavy jobs use Fargate or Batch.
• Fargate vs EC2 launch type: Fargate for no infrastructure management; EC2 for GPU, special instance types and Spot-heavy cost control. ECS is simplest, EKS for Kubernetes.
• AWS Batch runs batch jobs (thousands of jobs) on managed EC2, Spot or Fargate compute with queues and priorities. Use it for “run many independent compute jobs and manage the fleet for me”.
• Elastic Beanstalk: upload code, AWS provisions EC2, load balancer and scaling. EMR: managed Spark, Hadoop and Presto clusters for big data. Outposts put AWS infrastructure on premises for low-latency local processing. Local Zones and Wavelength put compute near cities and 5G networks. VMware Cloud on AWS runs vSphere workloads.

Databases

Choosing a database

RDS and Aurora performance

• Storage and engine: gp3 is the default, io2/Provisioned IOPS for heavy I/O. Instance size and memory-optimised classes for large working sets. Storage autoscaling grows storage automatically.
• Read replicas offload reads (reports, dashboards) but are asynchronous (replica lag). The application must point reads at the replica endpoint. Aurora offers a reader endpoint that load-balances across replicas and custom endpoints. For writes, scale up the instance, shard, or move to Aurora/DynamoDB.
• RDS Proxy pools and shares connections, which helps Lambda and spiky apps that exhaust connection limits, and speeds failover. Aurora Serverless v2 scales capacity in fine ACU steps for variable load, and can scale to zero.
• Aurora Global Database puts low-latency local reads in other Regions. Aurora Limitless shards writes. Aurora I/O-Optimized removes per-I/O charges for I/O-heavy workloads.
• Multi-AZ is availability, not performance.

DynamoDB capacity and access patterns

• Capacity modes: on-demand (pay per request, unpredictable traffic, no planning) or provisioned (set read/write capacity units with auto scaling, cheaper for steady load).
• 1 RCU = one strongly consistent read per second for items up to 4 KB (an eventually consistent read costs half). 1 WCU = one write per second up to 1 KB. Item max 400 KB. Transactions use double.
• Choose a partition key with high cardinality to avoid hot partitions. Add global secondary indexes for other query patterns (local secondary indexes share the partition key and must be created with the table).
• DAX is a write-through in-memory cache for DynamoDB with microsecond reads and no application rewrite beyond the client. DynamoDB Streams capture changes for Lambda. TTL deletes expired items for free.
• Use DynamoDB when access is by key and scale is unpredictable. Use a relational database when you need joins, ad hoc SQL and strong relational integrity.

Caching

• Cache patterns: lazy loading (read-through on miss) and write-through. Cache read-heavy, rarely changing data to cut database load and latency. ElastiCache Serverless scales automatically. Redis supports AUTH, encryption in transit and at rest.

Engines and migration

• Homogeneous migration (Oracle to Oracle, MySQL to Aurora MySQL) uses AWS DMS alone, with CDC for ongoing replication and minimal downtime. Heterogeneous migration (Oracle to PostgreSQL) uses the Schema Conversion Tool / DMS Schema Conversion first to convert the schema, then DMS to move data. MySQL vs PostgreSQL: both open source; PostgreSQL has richer types and extensions, MySQL is simple and widely used, and Aurora supports both.
• Capacity planning: estimate peak reads and writes, item or row size, connections and working set. Then choose instance class, Provisioned IOPS, capacity units or ACUs.

Networking and content delivery

Edge services

• CloudFront: OAC to keep S3 private, TTLs and cache policies, invalidations, signed URLs/cookies, geo restriction, WAF, price classes, Lambda@Edge and CloudFront Functions for lightweight edge logic (header rewriting, redirects, auth), and HTTPS to viewers and origins. A CloudFront origin can be S3, an ALB, API Gateway or any HTTP server.
• Route 53 latency routing sends users to the closest Region. Elastic Load Balancing spreads traffic inside a Region.

Load balancer choice

Use ALB for HTTP microservices and path-based routing, NLB for TCP/UDP, static IPs, extreme throughput and PrivateLink, and GWLB to insert firewalls and inspection appliances. Classic Load Balancer is retired.

Designing the VPC and connecting networks

• Plan IP addressing: choose non-overlapping CIDRs from the start (overlap blocks peering, VPN and Transit Gateway), leave room for growth, and use enough subnets per tier per AZ. Use IPv6 or an egress-only gateway where IPv4 is scarce.
• Subnet tiers: public (load balancers, NAT), private (app), isolated/data (databases). Place resources near users and each other: same AZ for chatty low-latency pairs (with a cluster placement group), multiple AZs for resilience.
• Connection options:

• Hybrid DNS uses Route 53 Resolver inbound and outbound endpoints. Global designs combine CloudFront, Route 53 latency or geolocation routing, and per-Region stacks. VPC Reachability Analyzer debugs paths.

Data ingestion, transformation and analytics

Streaming and ingestion

• Pick Data Streams when you build custom consumers, need ordering, replay or sub-second processing; Firehose to just land the data in S3 or Redshift with no code. Match shard count or capacity mode to ingest rate, and use a high-cardinality partition key.
• Data ingestion patterns depend on frequency: continuous streaming (Kinesis, MSK), micro-batches (Firehose buffer), scheduled batches (Glue, DataSync, AppFlow), and one-off bulk (Snow Family, DataSync). Secure ingestion points with IAM, VPC endpoints, KMS and TLS.

Transfer sizing

Rule of thumb: a fully used 1 Gbps link moves roughly 10 TB a day. Tens of TB with no spare bandwidth, or a poor link, favours offline devices; steady recurring transfers favour DataSync over Direct Connect or VPN. Combine S3 multipart and Transfer Acceleration for single large objects over the internet.

Transformation and analytics

A standard lake: ingest (Firehose, DMS, DataSync) → S3 (raw, curated) → Glue (catalog and ETL) → Athena, Redshift or EMR (query) → QuickSight (visualise), governed by Lake Formation.