使用哪個AWS服務來部署后端？

Question

我有一個網站（靜態坐在S3中），內容是從S3提供的。 我打算寫一個rest api（節點或開放建議）。 當前端進行有角度的$ http調用時（例如，如果我的網站名為example.com），則該調用將類似於相對URL（/ Update）之類的問題。

我不確定究竟應該使用哪種類型的AWS服務來部署后端代碼。

更新

我正在使用Codestar，正在使用Express Web服務。 這是我的template.yml。 和路線。 代碼星級構建可以正常進行，但是部署失敗。

template.yml

    AWSTemplateFormatVersion: 2010-09-09
Transform:
- AWS::Serverless-2016-10-31
- AWS::CodeStar

Parameters:
  ProjectId:
    Type: String
    Description: AWS CodeStar projectID used to associate new resources to team members

Resources:
  HelloWorld:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs4.3
      Role:
        Fn::ImportValue:
          !Join ['-', [!Ref 'ProjectId', !Ref 'AWS::Region', 'LambdaTrustRole']]
      Events:
        GetEvent:
          Type: Api
          Properties:
            Path: /
            Method: get
        PostEvent:
          Type: Api
          Properties:
            Path: /
            Method: post
  GetItemsBylId:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs4.3
      Role:
        Fn::ImportValue:
          !Join ['-', [!Ref 'ProjectId', !Ref 'AWS::Region', 'LambdaTrustRole']]
      Events:
        GetEvent:
          Type: Api
          Properties:
            Path: /api/getItemsBylId/:id
            Method: get

這是我的app.js

var express = require('express');
var app = express();

app.get('/', function (req, res) {
  res.send({
    "Output": "Hello World!"
  });
});

app.get('/api/GetItemsBylId/:id', function (req, res) {
    res.send({
      "Output": "I am up!"
    });
});

這是來自GetItemsBylId的部署錯誤

   Failed to set tags on AWS::Lambda::Function. IAM permissions lambda:ListTags, lambda:TagResource and lambda:UntagResource are required to tag AWS::Lambda::Function resources and to propagate stack level tags.

我很確定這是因為id參數。

更新資料

使用查詢參數解決了標簽問題。 我現在使用的是？id =“”，而不是使用resouce：id。

Answer 1

這里有幾件事情要考慮：

API網關 + Lambda

Lambda是通常認為的無服務器解決方案。 無需擔心基礎架構，您只需編寫代碼，基礎AWS托管資源即可為您運行代碼。 API網關與Lambda集成在一起，允許您將各種REST樣式的URL映射到Lambda函數。

好處

• 快速通話非常划算
• 通過內置的SDK輕松與AWS服務集成
• 使用IAM角色輕松訪問服務，而無需擔心憑據
• 它們中的許多可以並行運行以處理大量呼叫
• 支持多種語言，包括NodeJS
• 不必擔心可用區

缺點

• 有限的資源
• 處理本機編譯的軟件包可能有點麻煩
• 硬限制為5分鍾。 這可能使諸如處理圖像/視頻之類的任務不太可能成為使用候選對象。
• 磁盤空間非常有限

彈性集裝箱服務

利用EC2實例將其刻入容器的一種有趣方式。 如果您習慣處理docker映像，尤其好。

好處

• 處理大文件的更好方法
• 無需擔心Lambda超時
• 能夠分擔EC2實例，以更好地利用全部機器資源並獲得所需的費用

缺點

• 如果您不熟悉Docker / Containers，可能很難理解
• 仍然比Lambda路線更貴
• 如果您要處理較高的IO類型設置，可能需要重新考慮
• 可能需要處理映射路線->服務
• 您必須注意，您的實例不在單個可用區中，從根本上關閉所有服務，直到您可以在另一個可用區中增加新資源為止。

彈性計算（EC2）

我建議針對更多以IO為中心的工作負載進行研究。 有許多可用選項，包括預配置的IOPS，實例存儲，高IO實例類型等。

好處

• 對系統的最大控制權，以及對於傳統VPS托管者而言可能更容易的設置
• 當您需要處理自定義庫，本機代碼，各種語言時，輕松得多
• 附加到EC2實例的IAM角色可用於允許基礎代碼輕松訪問AWS資源
• 許多實例類型可用於高IO，高帶寬和其他需求
• 可以對系統進行定制，然后將其轉換為AMI以實現可重現的系統
• 對於某些解決方案而言，它可能比Docker / Container解決方案更容易使用
• 可以輕松地與負載均衡器/自動伸縮組配合使用，以根據需要進行放大和縮小，同時能夠指向單個端點（負載均衡器），而不必擔心

缺點

• 成本將是一個問題
• 持續監控以確保您的實例類型滿足您的需求，並且您不會未充分利用所支付的費用
• 定價模型可能有點奇怪，因為它是按小時而不是按月計費的。 但是，有一些費用估算計算器，可以讓您知道您的每月估算費用。
• 如果使用負載平衡（最理想的方式），則會產生額外費用
• 盡管Auto Scaling組可以幫助您實現自動化，但必須考慮放置服務器的可用區域。 不過，這是要考慮的另一個成本點。
• 您可以管理基礎操作系統，包括更新

彈性豆莖

這是EC2方面的一個很好的接口。 如果您只有要運行的代碼，而寧願其他事情來決定運行代碼的位置/方式，則可能很有用。

好處

• 消除了許多基本用例的猜測
• EC2 + Load Balance具有的大多數相同優點

缺點

• 由於資源是抽象的，因此您需要更加小心所產生的成本
• 可能會使對基礎資源的修改變得更加困難（盡管此時您可能處於無需使用Elastic Beanstalk即可管理事物的級別）

現在，關於數據庫，您可能需要存儲東西：

DynamoDB

NoSQL數據存儲。 如果您可以將數據存儲為鍵值對而又無需大量相互關聯數據，那么這價格是合理的。 免費套餐的限制也不錯。

好處

• 管理讀寫負載的簡單方法
• 非常快
• 如果需要，可以使用緩存
• 價格非常優惠的免費套餐

缺點

• 不適合使用具有很多關系的結構化數據以及需要查詢這些關系的條件
• 有索引，但是如果您需要其他索引，則可以開始付款
• 對於那些不習慣NoSQL的人可能會感到困惑
• 免費套餐開始按小時和按GB定價
• 查找可處理流行關系數據庫的SDK / API容易得多

簡單數據庫

顧名思義，這是一個相當簡單的數據庫。 這對於處理較小的工作負載或臨時存儲數據的位置非常有用。

好處

• 可以處理結構化數據
• 根據特定的使用時間范圍向您收費，而不是像EC2那樣對所有實例始終收費
• 免費套餐適用於小負載

缺點

• 如果您要存儲大量數據（1GB的免費套餐限制），那將不是理想的選擇
• 定價模式可能會有點混亂
• 如果您需要進入較高的讀/寫工作流程，則不建議使用
• 如果您需要結構化數據並幾乎一直都在訪問它，那么使用RDS解決方案可能更好

RDS

您對大多數人熟悉的數據庫的期望。 包括MySQL，Aurora（亞馬遜自定義的MySQL），PostgreSQL，Oracle，SQL Server。

好處

• 與許多人習慣於處理數據庫的方式更加匹配
• 比DynamoDB更擅長處理結構化數據
• 由於它由流行的數據庫支持，因此使數據導入/導出更加容易，尤其是當您要在本地檢查數據時
• SQL客戶端在大多數編程語言中都是相當標准的，因此與之進行接口將變得容易得多

缺點

• 與DynamoDB的免費套餐相比沒有那么出色
• 根據需求可能會變得昂貴
• 調整IO性能還有更多的事情要做

我認為我已經談到了基本的優點和缺點，但是很可能缺少一些在評論之后讓我想起的項目。 我也強烈建議您查看所有鏈接的站點，以更好地了解服務以及滿足您需求的內容，因為我可以提供的答案太多了。

Answer 2

確實沒有足夠的信息可以給您一個好的答案。 這取決於您的后端需要做什么以及如何擴展。 如果您只需要提供簡單的功能，則無需進行整個EC2實例操作，AWS Lambda函數是一種很好，簡單且非常便宜的方法。 Lambda函數支持Node.js（以及Python，C＃和Java）。

這是一種無需過多承諾即可嘗試的好方法。 如果您確定需要更合適的服務器環境或需要執行諸如寫入文件系統之類的代碼，則代碼應易於移至運行Node的EC2實例。

將API托管在子域（即api.example.com）上而不是與S3存儲桶位於同一域下可能更容易，但是如果您需要它們全部位於同一域下，則可以通過設置S3來實現網關中的代理。 （ http://docs.aws.amazon.com/apigateway/latest/developerguide/integrating-api-with-aws-services-s3.html ）

Answer 3

您應該簽出AWS Codestar 。

只需按一下按鈕，您將擁有一個完全運行的CI / CD管道和可用於開發的公開端點。

Answer 4

我建議使用無服務器。 我也嘗試了Codestar，但遇到了限制錯誤

AWS CodeStar在處理您的請求時遇到錯誤：無法在IAM中創建或更新一個或多個策略。 項目中的資源數量已超出IAM策略大小限制。.使用其他參數重試，或聯系AWS支持。

支持人員說，我的template.yml中沒有大約19個函數的解決方法，但是當我添加更多函數時，會出現此錯誤，我不知道如何解決此問題，沒有項目可以最多包含19個函數。