GardenCloud & systems

Cloud architecture terms worth separating

Shared responsibility, availability, recovery objectives, scaling, and infrastructure boundaries from an earlier AWS notebook.

Several architecture terms sound similar while answering different questions. This earlier AWS notebook becomes more useful when those questions stay separate.

Responsibility

AWS operates underlying cloud infrastructure; the customer remains responsible for its data and chosen configuration. The exact boundary changes with the service: managing an instance’s operating system is different from using a managed application service. The shared-responsibility model is the reference.

Availability and recovery

High availability aims to reduce disruption and recover service quickly. Fault tolerance aims to keep operating through a defined failure. Neither label removes the need to specify which failures the design handles.

RPO describes the acceptable loss of recent data, expressed as time. RTO describes the acceptable time to restore service. A backup schedule and a successful restore exercise provide different evidence for those objectives.

Scaling

Vertical scaling changes one machine’s resources. Horizontal scaling adds instances and requires the application to coordinate work and state. Horizontal scaling still has practical limits; it is not infinite capacity.

Geography and resources

Regions, Availability Zones, local deployment options, and edge locations serve different placement roles. Old region counts and network-capacity figures are omitted because they are not stable design requirements.

S3 organizes objects into buckets, while CloudFormation describes infrastructure resources in templates. The Well-Architected guidance connects these choices to concrete reliability, security, and operating requirements.

← Back to the garden