Answers: <p>The AWS answer would be to use appropriate services for each component.</p>
  <p>E.g. Put the database on an RDS - they have multiple choices. Deploy the front-end using Fargate and Lambda.</p>
  <p>There are 2 issues to consider:</p>
  <p><strong>1. The learning curve.</strong></p>
  <p>Getting up to speed on AWS technology - and keeping up with them as they make minor tweaks that break lagacy deployments - can get very expensive, time-wise.</p>
  <p>OTOH, once you're an expert at these technologies, you can leverage them with amazing results.</p>
  <p><strong>2. The costs:</strong></p>
  <p>While you develop you will be using the free-tier mostly, and the costs will be minimal.</p>
  <p>Once you move into production, you have have to start using &quot;real&quot; machinery, and even if you don't, most services have an expiration for their free tier: 12 months and/or a certain amount of usage.</p>
  <p>At that point the costs start ballooning. from small-change to 3 or even 4-figure numbers for a small installation.</p>
  <hr />
  <p>The other approach is to do it the way you'd do it without AWS.</p>
  <p>You didn't give me much details, but if you're deploying something simple, you may want to spin up an EC2 instance, install a LAMP server and use it for both front &amp; back end.</p>
  <p>You can then use the Lifecycle Manager to back up the entire machine daily.</p>
  <p>However, if you have to scale this up in a big way, you'll have to start from scratch.</p>
  <hr />
  <p>So, what do you choose?</p>
  <p>The answer depends on your resources: time, money and manpower, as well as how you see this growing from a one-off project to a long term heavily used installation that needs redundancy, load balancing and the ability to scale dynamically.</p>
  <p>You could also look at something like AWS Beanstalk, which is easier to implement and redeploy, but not as dynamic, as their serverless approach.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-09-22T14:10:33.377Z
Answers: 2020-09-22T14:10:33.377Z
Answers: Danny Schoemann
Body: <p>I have just recently started to consider using AWS for my SPA Web Apps. And I have read a lot about different types of how web apps could be hosted on AWS. I have looked into Lambda, S3 Static hosting. EC2. But can't seem to figure out how to exploit AWS and it services the best possible way.</p>
  <p>My Web App consists of a front-end written in Vue js. Which uses a Backend API written in Laravel. The front-end and backend are isolation so they don't have to be placed on the same machine. So I guess that could bring some good opportunities for using the different AWS products? The Database is only connected to the Backend Api so the Frontend is static. I'm also openminded to changing to another type of database if that would fit better into the AWS environment. But I don't know if I should separate the Frontend and API into different services.</p>
  <p>Thanks in advance!</p>
  
Tags: <amazon-web-services>
Title: AWS hosting of SPA Web App
UserDisplayName: Kristoffer Mikkelsen
ThreadText: # AWS hosting of SPA Web App
  
  (Asked by: username_0 on 2020-09-16)
  
  I have just recently started to consider using AWS for my SPA Web Apps. And I have read a lot about different types of how web apps could be hosted on AWS. I have looked into Lambda, S3 Static hosting. EC2. But can't seem to figure out how to exploit AWS and it services the best possible way.
  
  My Web App consists of a front-end written in Vue js. Which uses a Backend API written in Laravel. The front-end and backend are isolation so they don't have to be placed on the same machine. So I guess that could bring some good opportunities for using the different AWS products? The Database is only connected to the Backend Api so the Frontend is static. I'm also openminded to changing to another type of database if that would fit better into the AWS environment. But I don't know if I should separate the Frontend and API into different services.
  
  Thanks in advance!
  
  **Tags:** amazon-web-services
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-09-22. Score: 1
  
  The AWS answer would be to use appropriate services for each component.
  
  E.g. Put the database on an RDS - they have multiple choices. Deploy the front-end using Fargate and Lambda.
  
  There are 2 issues to consider:
  
  **1. The learning curve.**
  
  Getting up to speed on AWS technology - and keeping up with them as they make minor tweaks that break lagacy deployments - can get very expensive, time-wise.
  
  OTOH, once you're an expert at these technologies, you can leverage them with amazing results.
  
  **2. The costs:**
  
  While you develop you will be using the free-tier mostly, and the costs will be minimal.
  
  Once you move into production, you have have to start using "real" machinery, and even if you don't, most services have an expiration for their free tier: 12 months and/or a certain amount of usage.
  
  At that point the costs start ballooning. from small-change to 3 or even 4-figure numbers for a small installation.
  
  ---
  
  The other approach is to do it the way you'd do it without AWS.
  
  You didn't give me much details, but if you're deploying something simple, you may want to spin up an EC2 instance, install a LAMP server and use it for both front & back end.
  
  You can then use the Lifecycle Manager to back up the entire machine daily.
  
  However, if you have to scale this up in a big way, you'll have to start from scratch.
  
  ---
  
  So, what do you choose?
  
  The answer depends on your resources: time, money and manpower, as well as how you see this growing from a one-off project to a long term heavily used installation that needs redundancy, load balancing and the ability to scale dynamically.
  
  You could also look at something like AWS Beanstalk, which is easier to implement and redeploy, but not as dynamic, as their serverless approach.
  
  
  ---
  
  