Solution Architecture AWS

 Before we get started with this task, let's give you some more context on AWS. 

AWS has myriad services for doing all kinds of things! While you don’t need to be familiar with them all, outlined below are a few that give you a sense of what type of services we provide and how they are billed. 

Please have a read through the services below and click next once you're done. It's likely that you'll need to use some of this information on the next part of this task - but you can easily navigate back and forth as required!

 CodePipeline
This will build code and can deploy it to various AWS services. It is charged per pipeline. Can be used with Elastic Beanstalk for blue/green no-downtime deployments.

Elastic Load Balancing
Distributes traffic across application servers, such as EC2, Lambda or Fargate. Can use health checks to know which servers should service requests. Charges are based on the number of hours the load balancer runs and (at a high level) the amount of traffic it services. The actual charging rules can be quite complex.

RDS
Relational database hosting platform. Charged in the same way as EC2 (i.e. a virtual machine with a set amount of resources). Servers can be resized but must be restarted to do so.

Route 53
AWS' domain and DNS management.

 S3
Store objects in the cloud. Charged based on the amount of data being stored, how it’s stored, and for retrieval. 

 AWS provides a few ways of executing applications, from virtual machines, to container executors to function executors.

EC2
Scalable virtual servers. Charged based on resources of the virtual servers (RAM, CPU, storage), per hour. Servers can change their resource allocation but must be restarted to apply them.

Fargate
Run containerized applications (e.g., Docker images). Charges are based on the resources assigned to the container (RAM, CPU, etc.) and how long it runs for. Very scalable but can require manual orchestration.

Lambda
An application is uploaded to Lambda and only executed when triggered, for example, on HTTP request or via S3. For example, a Lambda instance would run to just service a single HTTP request. Charging is based on the amount of memory the Lambda uses and how long it runs for, plus the number of requests. Sometimes data transfers can also be charged depending on which region(s) a Lambda is fetching data from. Highly scalable up and down. Not suited for serving static content.

Lightsail
Virtual machines, like EC2 but simpler to set up. Charges are based on the resources of the Lightsail virtual machine. Virtual machines' resources can’t be changed, instead the machines must be cloned to a new instance and restarted. 

Elastic Beanstalk
Ties together EC2, RDS and Elastic Load Balancing with simple configuration and deployment. Its primary advantage is how it can facilitate the autoscaling of EC2 instances. Billing is based on a combination of the EC2, RDS and ELB that you use. Deployment is made easy with CLI tools, and we can use rolling deployments so there is no downtime. It has support for several languages including Python, NodeJS, Java and Go.

 For extra redundancy, services can be deployed across multiple availability zones (AZ). This means that requests can fall over from one AZ to another in the case of infrastructure failure. In general, the cost of a service is multiplied by the number of availability zones it’s in.

You should be able to tell the customer why you have chosen Elastic Beanstalk and what components it contains, and the purpose of these. The AWS resource pages for each service contain descriptions of how they are charged.

• CodePipeline
• Elastic Load Balancing
• RDS
• Route 53
• S3
• Elastic Beanstalk

The concrete pricing differs in each region, however, the method of price calculation is the same. For example, an EC2 instance in Region A may cost more than the same instance in Region B, however, both are billed at an hourly rate. The AWS pricing calculator at https://calculator.aws/ can also give some guidance.

 Okay let's get started on the email to Lilly. In the email, you will need to show an architecture diagram and explain: 

• what each part of the architecture is,
• why it was chosen, and
• how the costs are calculated and how they may vary month-to-month - remember you don’t need to give concrete numbers, just an overview!

Your team has come together and decided on the architecture approach. Outlined below is all the information you need to draft your email - you can also refer back to Step 2 to learn about AWS services. 

Read the information and write your response in the text box below. Your response should be approx. 600-700 words. 

We'll show you an example answer on the next step, but we encourage you to give it a go first! .

 When deciding on the right AWS solution, your team considers these points:

• The company is a startup. We are lucky because we can provide more of a greenfield approach, and they are more likely to be able to make changes to their application stack. Compared to an enterprise, where change can take a long time, and they may end up only being able to migrate part of their system at a time.
• Again, being a startup, it is probably easy to migrate their data into AWS.
• They have a single server and already experience downtime, so they are probably OK with some downtime during migration and setup.
• Being a mixed API and web app they will need to host some static content as well.

 In this case, we will recommend a solution based on Elastic Beanstalk based on these requirements:

• The customer has a Python application that Elastic Beanstalk has support for.
• The customer will need to scale, and this is one of the fundamental features of Elastic Beanstalk.
• They want to remove downtime when deploying and Elastic Beanstalk’s Blue/Green deployment can assist with this.

The AWS Elastic Beanstalk documentation provides some more information if you want to learn about it! 

 The services we will use are listed below: 

• Route 53
• Elastic Load Balancing
• Elastic Beanstalk with Autoscaling EC2 Group
• RDS
• S3
• CodePipeline

An additional availability zone for redundancy is proposed but is not necessary.

 Importantly, the team recognizes that Elastic Beanstalk is not the only product that we could recommend for this customer! AWS is an open platform and encourages creativity when building solutions. We need to be aware of the pros and cons of each solution and how they will best fit each customer.

Other options like Lambda or Fargate can be more complex to set up. Lightsail and EC2 can be easy but they don’t provide that automatic scaling; the customer can end up paying more because they are running virtual machines that are often not at capacity. However, each of these services also has its own advantages, and depending on the application that’s being built we can provide different recommendations and discuss the options more in-depth with the customer before coming up with the final design.