using multiple systems via research, documentation, experimentation. And who is a cloud architect? Cloud architect is a solution architect that is focused solely on architecting technical

solutions using a cloud service. A cloud architect need to understand the following terms and factor them into their designed architecture based on business requirements. First, this is availability. Your ability to ensure a service remains available.

Also known as highly available service or system. Then scalability, your ability to grow rapidly or unimpedant.

Then elasticity, your ability to shrink and grow to meet the demand. Then fault tolerance, your ability to prevent a failure. And disaster recovery, your ability to recover from a failure, also known as highly durable.

A solution architect needs to always consider the following business factors. First, security. Security is the most important thing in any architecture, in any application, security is the most important thing.

So how secure is solution? And cost. Because when we pay as we use and for what we use that we pay for and we are built by minutes, by second, by hour, by day, we always must know the cost of our system.

So how much is this going to cost? So let's deep dive into each term more deeper. First, this high availability.

High availability, this is your ability for your service to remain available by ensuring there is no single point of failure and or ensure a certain level of performance.

Let me show you this diagram. Here we have Route 53. After Route 53, we have elastic load balancer and we have some compute, some instance in

Availability Zone 1, Availability Zone 2, and Availability Zone 3. So elastic load balancer, this is a load balancer, allows you to eventually distribute traffic to multiple servers in one or more data centers. If a data center or server becomes unavailable and healthy, also called, the load balancer

will load the traffic to only available data centers with servers or to available just servers if all servers in one data center. Running your workload across multiple availability zones ensure that if one or two availability

zones become unavailable, your service applications remains available. High scalability. High scalability is your ability to increase your capacity based on the increasing demand

of traffic, memory, and computing power. We have two types of scaling, vertical scaling and horizontal scaling. Vertical scaling, scaling up, named upgrade to a bigger server.

For example, you have one server with two gigabytes of memory. You increase this server to four gigabytes of memory. This named vertical scaling. Horizontal scaling, named scaling out.

Then you have one server with two gigabytes of memory. And now you create three servers with two gigabytes of memory each. So add more servers of the same size.

High elasticity. High elasticity is your ability to automatically increase or decrease your capacity based on the current demand of traffic, memory, and computing power.

To reach this, in AWS, we have auto-scaling groups. This is an AWS feature that will automatically add or remove servers based on scaling rules

you defined based on metrics. Metrics can be scheduled or unscheduled. This means based on metrics what give you, for example, another resource.

Scaling out. Add more servers of the same size, scaling in, removing underutilized servers of the same size. Vertical scaling is generally hard for traditional architecture, so you will usually only see horizontal scaling described with elasticity.

Forward Tori runs. In forward Tori runs, we have two definitions. First, let's say what is forward domain. A forward domain is a section of a network that is vulnerable to damage if a critical

device or system fails. The purpose of a forward domain is that if a failure occurs, it will not cascade outside the domain, limiting the damage possible.

We can have forward domains nested inside forward domains. Second definition, forward level. Forward level is a collection of forward domains.

The scope of a forward domain would be specific servers in a rack, an entire rack in a data center, an entire room in a data center, the entire data center building.

It's up to the cloud service provider to define the boundaries of a domain. In terms of AWS, an AWS region would be a forward level, for example, US East 1 region. An availability zone would be a forward domain.

For example, forward domain, US East 1A availability zone and US East 1B availability zone.

Each Amazon region is designed to be completely isolated from the other AWS regions. This achieves the greatest possible fault tolerance and stability. Each availability zone is isolated, but the availability zones in a region are connected

through raw latency links. Each availability zone is designed as an independent failure zone. A failure zone is AWS describing a forward domain. Failure zone.

Availability zones are physically separated within a typical metropolitan region and are located in lower risk food plains. This creates an uninterruptible power supply, UPC, and on-site backup generation facilities.

Data centers located in different availability zones are designed to be supplied by independent substations to reduce the risk of an event on the power grid impacting more than one

availability zone. Availability zones are all redundantly connected to multiple tier 1 transit providers. Multi-availability zones for high availability.

If an application is partitioned across availability zones, companies are better isolated and protected from issues such as power outages, lightning strikes, tornadoes, earthquakes, and more.

High durability. High durability is your ability to recover from a disaster and to prevent the loss of data. Solutions that recover from a disaster is known as disaster recovery solutions.

Disaster recovery, answering the questions. Do you have a backup? How fast can you restore that backup? Does your backup still work? How do you ensure current live data is not corrupt?

In disaster recovery plan is very important from time to time restore your backup. Because backup can be broken. Application that make backup can broke your backup or even your data can be broken.

And you can and this data can be restored. And this very important to time to time from time to time restore backups to be sure you

don't have broken backups and you can restore your backup and make live your system again. In AWS cloud, we have cloud and do disaster recovery continuously replicates your machines

into a low cost staging area in your target AWS account and preferred region, enabling fast and reliable recovery in case of IT data center failures. Business continuity plan.

A business continuity plan, BCP is a document that outlines how a business will continue operating during an unplanned disruption in service. In BCP, we have two definitions first, recovery point objective, LPO, the maximum acceptable

amount of data loss after an unplanned data loss incident expressed as an amount of time.

Second definition recovery time objective LTO, the maximum amount of downtime your business can tolerate without incurring a significant financial loss.

So let's see the image. We have lifetime of our application. And in some period of time, appears disaster recovery, recovery point LPO.

So each time each time in our schedule, we make some recovery points. Just make backups, for example, one time in one hour.

But after our backup was made, after some period of time, appears disaster. So we have data lost here. So this data, we have already lost.

After disaster, we have some period of time, and this time called downtime, before we recover our system. And time from disaster to make our system arrive again, named recovery time.

Disaster recovery options. So here we have a graph. And we have four options in general, we have four general options for recovery.

So first, backup and restore option. LPO and LTO, this is hours, takes hours.

For priority use cases, provision all AWS resources after event, restore backups after event. And plus of this option, this very low cost option.

Then pilot right, LPO, LTO takes decades of minutes. Data is alive, services idle, provision some AWS resource and scale after event, after disaster event.

And this solution cost more than backup and restore. Then we have long standby solution. LPO, LTO takes minutes. We have always running system, but smaller, for example, machines with memory for production

version is double than for idle machines. This use for business critical services.

We scale AWS resources after event. And this more cost than pilot right.

Then we have multi-site, active, LPO, LTO, this real time. Because we have zero downtime, near zero data loss, and this for mission critical services.

And this very expensive solution. Because in general, you have two the same applications running, two the same architectures.

So let's see the image, backup and restore. We have AWS cloud, we have region one and region two. And we have only cross region backup. And we have in another region just data.

Then disaster appears. We have redeploy all infrastructure. For example, we have here EBS volumes, instances, LDS instance, DB snapshots, EBS snapshots is actually saved into Amazon Simple Storage.

So also instances this application. We have to use infrastructure as a code approach, redeploy everything in another region, just grab this data, what was the code previously.

Then we have pilot right solution. We have on top route 53. And route 53 always route traffic to Elasti code balancer in region one.

And application works fine with after scaling groups. And this after scale and in region two, resources for front end server and application server

is scaled to zero. After disaster in route 53, we'll throw traffic to another Elasti code balancer in second

region and just scale up our instances, our front end server and application server. And data always asynchronous cross region replicated.

Then we have worm standby. It's very similar to previous solution, except one thing, after scaling groups in second region doesn't scale to zero.

They already up and running, but on very small and very little capacity, for example, in other types of instances or if we scale a number of instances that just one instance,

code can accept immediately connections. And then we have multisite active-active.

We have two the same infrastructure and two the same applications in two different region. Why name active-active? Because route 53, in the same time, balance traffic to Elasti code balancer in region

one and Elasti code balancer to region two. And in the end, Elasti code balancer balance across the front end server and application server. And this is the most effective solution, but this is the most expensive solution.

LTO, LTO is revised. Let's revise. LTO, recovery time objective is the maximum acceptable delay between the interruption

of service and restoration of service. This objective determines what is considered an acceptable time window when service is unavailable and is defined by the organization. LPO, recovery point objective is the maximum acceptable amount of time since the last data

recovery point. This objective determines what is considered an acceptable loss of data between the last recovery point and the interruption of service and is defined by the organization.

So how to choose what option of recovery to take? So we have image on y-axis we have cost and complexity on x-axis we have time to recover.

And when we have request from business about acceptable recovery cost and recovery time objective, we can see what type of recovery we should take.

So here on this image we should take something between pilot ride and backup and restore. So some part of systems, if this is microservices infrastructure, some part of system might be using pilot ride approach and some part of system might be use backup and restore.

If this is not possible to divide system into two types of restore, we can choose one

and but this also this decision made by organization. Let's see a diagram or architecture diagram of simple microservices website with front

end and back end of this website runs on AWS Lambda functions. So we have here a client side, client side request front end from Amazon CloudFront and

sends API access via Amazon API Gateway. From Amazon API Gateway we send request to AWS Lambda, AWS Lambda can request or put

data into DynamoDB, if Lambda request data from DynamoDB it send to Amazon API Gateway and Amazon API Gateway show this data on front end.

AWS Lambda writes works and have its own metrics and this all metrics save in Amazon CloudWatch. In Amazon CloudWatch we can set up CloudWatch alarm with notification.

If error will appear in AWS Lambda, this error will be written in Amazon CloudWatch, then alarm will triggered and send message about Lambda is failed to first AWS Lambda

and Lambda send message to search channel and send to Amazon SNS simple notification service and simple notification service will send email about Lambda status.

Thank you.

Thank you.