# Day 4: Cloud Architecture terminologies

## Solution Architect

A **Solution Architect** is a role in a technical organization responsible for designing solutions that integrate multiple systems. This involves extensive research, documentation, and experimentation to architect the most efficient and scalable technology solutions.

## Cloud Architect

A **Cloud Architect** is a type of solution architect who focuses on designing technology solutions using cloud services. They need to be well-versed in cloud-specific concepts to meet the business requirements effectively. Below are key terms a cloud architect must understand and incorporate into their architecture:

### Availability

The ability to ensure that a service remains accessible, often referred to as **Highly Available (HA)**.

### Scalability

The ability to grow rapidly or without interruption to meet increasing demand.

### Elasticity

The ability to automatically shrink or grow to accommodate varying levels of demand.

### Fault Tolerance

The ability to prevent failure and ensure continuous operation.

### Disaster Recovery

The ability to recover from failures, ensuring that services remain **Highly Durable (DR)**.

## Key Factors for Cloud Solution Architecture

When architecting cloud solutions, two primary factors must be considered:

### 1\. Security

Security is paramount in cloud solutions to protect data and services from potential threats.

### 2\. Cost

A well-designed cloud architecture must also be cost-effective, aligning with the business's financial constraints and objectives.

### Business Continuity Plan (BCP)

A **Business Continuity Plan (BCP)** outlines how a business will continue to operate during an unplanned service disruption. It focuses on two critical metrics:

* **Recovery Point Objective (RPO):** The maximum acceptable amount of data loss after an unplanned data-loss incident, expressed as a duration of time.
    
* **Recovery Time Objective (RTO):** The maximum acceptable amount of downtime a business can tolerate without incurring a significant financial loss.
    

## Disaster Recovery Options (RTO/RPO)

Different disaster recovery strategies offer varying **RTO** and **RPO** values, based on the business's needs:

### Backup & Restore (Hours)

* Back up your data and restore it on new infrastructure after an event.
    
* **Use Case:** Lower-priority services
    
* **Cost:** Low
    
* **RTO/RPO:** Hours
    
* **Actions:** Restore data and deploy resources after the event.
    

### Pilot Light (10 Minutes)

* Data is replicated to another region with minimal services running.
    
* **Use Case:** Less stringent RTO & RPO requirements
    
* **Cost:** Higher than Backup & Restore
    
* **RTO/RPO:** 10 minutes
    
* **Actions:** Start and scale core services after the event.
    

### Warm Standby (Minutes)

* A scaled-down copy of your infrastructure is running, ready to scale up when needed.
    
* **Use Case:** Business-critical services
    
* **Cost:** Higher than Pilot Light
    
* **RTO/RPO:** Minutes
    
* **Actions:** Scale resources after the event.
    

### Multi-Site Active (Real-Time)

* A fully scaled-up copy of your infrastructure is running in another region, ready to take over instantly.
    
* **Use Case:** Mission-critical services
    
* **Cost:** Highest among all disaster recovery options
    
* **RTO/RPO:** Zero downtime, net-zero data loss
    
* **Actions:** Zero downtime and loss, mission-critical services run without interruption.
    

## AWS Application Programming Interface (API)

An **API** (Application Programming Interface) is software that allows two applications or services to communicate with each other. The most common type of API involves **HTTP/S requests**.

### AWS API

AWS APIs use **HTTP** to interact with cloud services. Although users can send **HTTPS requests** directly to AWS APIs, it's easier to use various developer tools, such as **Postman**, to interact with them.

### Developer Tools

Developer tools simplify the process of interacting with AWS APIs, allowing for seamless integration and efficient management of cloud services without manually sending HTTP requests.
