Ⅰ 如何在aws伺服器上設置ip黑白名單
在網站安全狗IP黑白名單內將本機IP設置為黑名單，通過測試發現在本地訪問網站就提示錯誤信息
IP白名單設置可以通過設置一些值得信賴IP地址為白名單地址，從而使它們能夠順利的訪問網站，用戶可以點擊「啟用」選項開啟白名單功能，不要忘了設置好後需要保存
規則列表，可以新增、修改、刪除禁止訪問IP段及對應的網站規則
具體設置和設置後
可以點擊「修改」和「刪除」對規則進行修改
將一些常見的網路爬蟲設置成白名單，這樣就不會再攔截爬蟲了
在默認設置中已經有添加了一些爬蟲白名單，用戶同時可以在「新增」和「刪除」選項中添加一些自己需要的爬蟲和刪除一些沒用的爬蟲。
IP黑名單是相對白名單進行設置的，目的是為了通過設置一些不良IP地址為黑名單地址，從而限制它們訪問網站。需要先開啟防護功能列表中的監控設置才能正常啟動，同時點擊「啟用」後要記得保存修改
同樣IP黑名單也是採用由指定IP和子網掩碼來劃分IP地址，設置方法和IP白名單的設置是一樣的，用戶可以通過「新增」，「修改」，「刪除」修改規則列表
當被禁止IP訪問用戶的網站時，伺服器就會返回信息，這個信息可以根據自己的情況進行設置
Ⅱ AWS - ECS + Application Load Balancer的思考
我們有一個前端應用項目，這個前端應用用來替換老的Web站點的部分頁面，其結構如下：
用戶的請求首先會到Nginx，由Nginx做反向代理，根據請求路徑轉發到New Web App或者Legacy Website。
在部署這個應用的時候使用到了AWS ECS。下圖為最開始時的部署結構：
從圖中可以看到，應用的DNS（Route53）指向了一個外部可訪問到的負載均衡器（External Classic Load Balancer）。負載均衡器暴露了80埠(用於Http請求)和443埠(用於Https請求)。負載均衡器將80埠和443埠都映射到了AWS EC2 Instance上的80埠。
而由ECS管理的Nginx容器，它將宿主機（EC2 Instance）的80埠映射到了容器的80埠。這樣從External Classic Load Balancer來的請求都會轉發到Nginx容器。
那麼，當用戶請求到達Nginx容器後，由Nginx做反向代理，根據請求路徑將請求轉發到New Web App或者Legacy Website（Legacy Website並不屬於部署結構中，所以並沒有在部署結構圖中畫出）。
假設，這個請求需要轉發到New Web App中，那麼應該怎麼做呢？
由於AWS ECS並沒有服務自動發現機制，所以我們需要給New Web App Container Cluster添加一個內部可訪問到的負載均衡器（Internal Classic Load Balancer）。這個負載均衡器將80埠映射到了AWS EC2 Instance上的3000埠，而在創建Nginx Container的時候會將這個內部負載均衡器關聯起來。所以在請求需要轉發到New Web App中時，直接轉發到這個內部負載均衡器即可。
到此為止，這個方案看似還不錯，但是如果你細心研究，你就會發現它存在一些問題。
有沒有發現，我們將ELB埠映射到了Instance上，而這個映射是固定的。一個Instance上的某個埠一旦被佔用，就無法被其它進程綁定。這就意味著一個EC2 Instance上只能啟動一個Nginx容器、一個New Web App容器，因為它們都需要綁定到特定的EC2 Instance埠號。
那麼，如果說EC2 Instance上有足夠的資源能夠再啟動一個New Web App容器或者Nginx容器，但是由於埠已經被佔用所以這些資源只能被浪費掉。我們必須再啟動一台EC2 Instance給ECS使用，ECS發現這個新的EC2 Instance上沒有綁定過3000或者80埠，並且有足夠的資源（CPU, Memory）啟動New Web App或者Nginx容器，那麼New Web App或者Nginx容器就會在新的EC2 Instance上啟動。
由此，我們可以看到這種部署方式，給我們帶來了這樣的問題，即： 某種類型的容器只能在一個EC2 Instance上啟動一個 。這對於我們來說是一個極大的限制，為了解決這個問題，我們找到了AWS Application Load Balancer（ALB）。
首先，我們將Classic Load Balancer換成了Application Load Balancer，如下圖：
從圖中看，好像並沒有什麼改變。是的，如果還是使用固定埠的話對我們並沒有什麼幫助。但是，ALB有一個特性它可以實現 動態埠綁定 ，這個特性正式我們想要的。
通過，實現動態埠綁定我們的架構變為如下圖所示：
如圖所示，通過動態埠綁定，我們實現了在 一個EC2 Instance上啟動多個同類型的容器 。
Ⅲ 如何管理aws雲伺服器
管理可以由兩個方面構成
第一個是通過AWS控制台的配置，來設置伺服器的伸縮，監控等等。
EC2的使用
第二個是使用PuTTY直接連接EC2，進行管理。
教程：
使用PuTTY連接EC2
希望可以幫到你。
Ⅳ 亞馬遜AWS的雲計算服務有哪些優勢
亞馬遜AWS作為雲計算服務的領軍者， AWS對SaaS解決方案的設計提供了一些雲計算服務最佳實踐。
一、將平台化的功能隔離出來，SaaS產品的更新速度是非常快的，但是我們仍然能夠總結出一些核心的功能是基本不變或者能夠在很多其他新的產品模塊中重用的。我們要將這部分功能分離出來進行平台化改造以服務於更多的其它功能，將這些功能平台化以後也會降低整個系統的耦合性從而支撐更多的SaaS應用的功能。對通用功能的平台服務隔離可以更好的調優和獨立擴展，同時重用核心服務並結合應用框架的使用會極大提升應用開發的效率。
二、優化成本和性能，在傳統的技術架構下這兩者之間往往需要進行一定的平衡，而在AWS雲的架構下的SaaS服務雲模式下往往可以實現魚與熊掌兼得。在每個架構層次實現彈性的橫向擴展可以讓我們實現按使用量付費的模式，而不需要為了獲得強大的性能而提前付出大量的資源成本，同時我們在SaaS的AWS架構下可以使用更小的、平行的資源單位進行擴展，從而更為貼近SaaS環境下的實際資源需求，在合適的場景下盡可能的採用完全由AWS託管的服務(比如Amazon DynamoDB等)來降低SaaS合作夥伴的運維成本並提升效率。
三、針對SaaS解決方案設計的。雲計算服務，首先對於多租戶的設計要針對SaaS應用自身的特點來進行規劃，總體的設計原則是系統會有多個帳號，而一個帳號會對應多個用戶，一個用戶又會對應多個角色;其次是對於系統處理各種請求時要按照優先順序進行分級管理，在通過使用AWS各種服務如SQS、SWF等對系統進行解偶後，對AWS資源集約使用的前提下，對請求分優先順序處理會極大提升SaaS架構的處理能力和穩定性;接下來要對監控加大投入力度，藉助AWS CloudWatch等監控服務，通過粒度更細的監控來控制分布式資源更為有效的彈性伸縮;最後合作夥伴還需要非常了解SaaS應用架構中所有數據的生命周期以及在在各個周期內數據的特點，依據這些特點為數據在AWS的服務中選擇正確恰當的存儲方式以優化技術架構及降低成本。
四、收集一切可以收集的數據並從這些數據中挖掘出價值。AWS基礎架構自身通過CloudWatch服務就可以收集粒度非常細的指標，同時SaaS應用自身也會產生大量日誌及指標數據，這些數據和指標不但要密切監控同時也要全量的妥善保存起來，以便後續的大數據挖掘工作。雲計算服務,不要擔心在傳統模式下數據存儲的高昂成本，在AWS雲的架構模式下有大量諸如Amazon S3、Glacier等成本極低的存儲方式。通過分析這些大量的數據來了解你SaaS服務的客戶，能夠為業務帶來巨大的價值，例如實時自動調整用戶體驗及與之相關的基礎架構，通過使用量的分析改進業務模型等等。
Ⅳ AWS 考試認證心得(SAA)（下）
接上 AWS 考試認證心得(SAA)（上）
這章主要就是AWS-SAA相關知識點的干貨啦，不過這不一定適用於每個人，最好的辦法還是自己按照自己的熟悉薄弱的地方去歸納總結AWS-SAA的考點知識：
個人總結AWS-SAA的考試有八大考點方向，分別是：
先按照大綱弄清每個服務是做什麼的，然後再深入去了解，再對比相似的服務，比如對於存儲這一塊兒就會考S3，EBS，EFS的區別，格子在什麼情況下用，再比如題目會問在某情況下怎麼cost最經濟高效？Spot，Reserved，還是On-demand。建議在這個過程中建議觀看英文文檔，因為有很多專業的詞彙還是要用英文才能描述的更准確。
AWS的考試是十分有技巧的，相信各位同學經歷了中國大大小小的考試，見過大風大浪，這個考試也應該不在話下，哈哈。總的來說就是做英文閱讀！沒錯，就是做閱讀。學會抓關鍵字法，排除法靈活運用。比如這一道題目：
這是道是非常經典的AWS的題目類型，雖然題目很長，但是按照找關鍵字法的話就很快能做出來。快速瀏覽題目找到關鍵詞 highly available ，既然題目要求是HA的，那答案就是D。因為只有D有對應關鍵字的答案---- Multi-AZ 即：多個可用區。（看到HA那麼90%以上選Multi-AZ，因為要保證高可用，必須要在多個可用區部署，反之如果只是單個可用區，那麼服務掛了就不能保證高可用)。所以有很多考題就要學會抓關鍵字去做，這樣就能事半功倍。
1.SMB + on- premises 找 AWS Storage GateWay File gateway (注意是 file )
3.對象存儲： S3 ，S3也可以放static web，常與cloudfront搭配分發
4.「multi-instance，HFC，並行」 = EFS
5.I/O較低，偶爾會有小峰值：EBS通用SSD(gp2) General Purpose
7.吞吐量經過優化的HDD（st1）卷提供了低成本的磁存儲，該磁存儲根據吞吐量而不是IOPS定義了性能。此卷類型非常適合大型連續工作負載，例如Amazon EMR，ETL，數據倉庫和日誌處理。
8.冷HDD（sc1）卷提供了低成本的磁存儲，該磁存儲通過吞吐量而不是IOPS來定義性能。 sc1具有比st1低的吞吐量限制，非常適合大型連續的冷數據工作負載
4 iGB = 200 IOPS
Volume(iGB) : IOPS = 1：50，
EBS 4 IOPS = 1024 kb I/O
I/O : IOPS = 256 : 1
21.Amazon EBS 可看成外接移動硬碟
23.NLB 用於 layer 4
24.ALB 用於layer 7
總之要善於總結這些知識點，之後要做的事就是Mapping，找到關鍵字及匹配答案就能快速完成答題，不然130分鍾65道題時間還是有點緊張。
最後祝大家考試順利，早日通過認證考試！
Ⅵ 如何在AWS上部署千萬用戶級別服務
基礎架構
AWS分布在全球12個區域里
每個區域對應著一個地理位置，裡面含有多個Availability
Zones(可用區)。這些區域設置在北美，南美，歐洲，中東，非洲，亞太區。
每個AZ實質上是單個數據中心，盡管它們可由多個數據中心構建。
每個AZ有著獨立的供電系統和互聯網連接。
不同AZ之間以低延遲網路進行連接，這種快速網路可消除物理位置帶來的速度影響。
每個區域含有至少兩個AZ，共計32個AZs。
藉助AZ可創建高可用性的程序架構。
AWS在全球還分布有53個偏遠區域(Edge locations)
偏遠區域的使用對象是CloudFront，這是Amazon的內容分發網路(CDN)和DNS伺服器。
偏遠區域的存在使得全球用戶都可以享用低延遲網路而不論他們身在何處。建立區塊服務(Block Services)
Amazon透過AWS創建了大量高可用和高容錯的服務，具體的服務清單可點擊這里查看。
繳納一定的費用，你就可以在個人的應用中使用這些服務而不必為高可用性而憂心。
部分服務位於一個AZ中：CloudFront, Route 53, S3, DynamoDB, Elastic Load
Balancing, EFS, Lambda, SQS, SNS, SES, SWF。
即使是使用單個AZ的服務，其高可用架構也是足夠強大的。
1個用戶
在這個時候，開發者=用戶。你的架構看起來是這樣的：
運行單個實例，如t2.micro。你可以為你的伺服器選擇不同的CPU，內存，存儲設備和網路環境。
該伺服器承載了全部web任務，如：web應用，資料庫，管理器等。
使用AmazonRoute 53進行DNS管理。
為該實例附加一個Elastic IP地址。
那麼隨著用戶數的增加，我們需要如何進行升級改造，直至能為千萬用戶提供優質的服務呢？強調文字
優化策略
採用多主機模式
嘗試使用Amazon資料庫服務，如Amazon RDS(關系資料庫)，Amazon DynamoDB(NoSQL資料庫)，Amazon Redshift。
逐步從SQL資料庫轉為NoSQL資料庫，特別是數據量超過5TB，你的應用對低延遲敏感的時候。
使用Elastic Load Balancer(彈性負載均衡器)，它可以對主機進行健康檢測以確保網路的通暢，同時可以幫助實現網路的擴展。
垂直升級
需要更強的實例類型，例如c4.8xlarge或者m3.2xlarge。
停止使用當前的伺服器，換用功能更強大的機器，如：244GB RAM，40核CPU。
某些Amazon服務提供了Provisined IOPS選項以便用戶自行配置變更，這樣一來用戶可以使用類似DynamoDB的擴展服務。
類似上面的做法就叫做垂直升級。但其有個缺點，就是一旦機器出錯，你的網站也會停止運作了。所以要盡量避免單個實例的做法。
自動擴展
如果你一直在為峰值負載而努力，如黑色星期五，那麼其實是在浪費金錢。更好的解決方案
列表內容
是按需分配，這就是Auto Scaling(自動擴展)，在計算機群組中實現自動化的大小變更。
你可以為你的容量池定義最大值和最小值。
CloudWatch是一個管理服務，已內置到所有的Amazon應用中。
CloudWatch事件會觸發擴展。
觸發事件可以是CPU佔用率，時間延遲，網速等等。
你也可以向CloudWatch導入自定義基線，按照你的意願來觸發擴展。
架構分解
使用SOA/微服務，使你的服務層組件化。
這樣做的好處是單獨的服務可以獨立地進行擴展，從而大大增加了靈活性和可用性。
SOA是Amazon提供的重要架構組件。
避免重復勞動
把精力投入到能使你的業務與眾不同的事情上。
Amazon提供了很多高容錯的服務。例如，排隊(SQS服務)，郵件，轉碼，搜索，資料庫，監控等等。所以類似的服務都不必再次編寫了。
用戶數>千萬+
當用戶達到千萬級別的時候，你考慮的策略應該是這樣的：
多AZs模式
在不同層之間執行ELB(彈性負載平衡)。除了web層，在應用層，數據層等層里也需要進行ELB。
能夠自動擴展
使用面向服務的架構
緩存架構內和外的數據
使用Amazon S3和CloudFront。S3用於存儲靜態數據，如js，CSS，圖像等，具有足夠的擴展性。CloudFront可對數據進行緩存。
使用Amazon SES來進行郵件發送。
使用CloudWatch進行監控。
對數據寫入執行如下的策略：
聯結 – 根據功能劃分不同的資料庫。
分表 – 把一個數據集分解到多個主機上。
把部分功能放到其他類型的資料庫上（NoSQL,graph等）。
不斷優化你的應用和整個架構堆棧，針對瓶頸進行分析並找出解決方法。
Ⅶ 在AWS上部署TE Agent並進行測試
ThousandEyes 是一個網路性能監控的SAAS雲服務，結合了各種主動和被動的監控技術，讓您深入了解您提供的以及您消費的應用和服務的用戶體驗。ThousandEyes使用的監控技術包括網路的可達性探測、時延、丟包、抖動、可視化的逐跳路徑分析、可視化的BGP路由分析、DNS監控、HTTP服務監控等。ThousandEyes平台對這些監控收集而來的數據進行分析、交叉關聯，將涉及用戶體驗的方方面面，包括網路和應用的狀況統一的呈現在同一個界面之下，讓您能夠輕松的隔離問題，採取行動，從而快速的解決問題。
ThousandEyes提供了三種Agent進行網路和應用的探測，分別是Cloud Agent、Enterprise Agent和Endpoint Agent。Cloud Agent 由ThousandEyes在全球部署和維護，當前，ThousandEyes在全球200多個城市共部署了400多個 Cloud Agent ，可供全球用戶使用。Enterprise Agent由用戶自己部署，可以部署為虛擬機或者容器，可以安裝在物理硬體，如Intel NCU或者樹莓派中，支持Windows、Linux系統，還可以部署在思科或Juniper的網路設備中，也能通過CloudFormation在AWS雲中自動部署。Endpoint Agent是瀏覽器插件，用戶在訪問網站時，可以自助的使用Endpoint Agent進行測試，由ThousandEyes進行數據分析，從而幫助用戶快速了解其數字體驗，以及快速定位問題所在。用戶可以根據自己的需要來選擇一種或多種Agent進行探測，ThousandEyes平台會自動完成分析和展現，提供網路和應用狀況的洞見分析。
在正式部署之前，快速閱讀了一下 AWS Deployment Guide ，部署過程是通過AWS的CloudFormation創建一個Stack，整個過程全部自動化。
部署的前提是需要設置好SSH Key-pair，VPC網路、公共子網、以及使用CloudFormation部署EC2的許可權。
部署的內容包括：啟動基於Ubuntu的EC2實例，並自動安裝TE Agent，創建Security Group，並基於最小許可權配置Inbound Rules。
首先，在MAC電腦中，執行以下命令，用於創建一個RSA的秘鑰對，並將公鑰拷貝至桌面。
登錄AWS的Console管理界面後，選擇Region，比如us-east-1，定位到EC2—Network Security—Key Pair，在界面右上側的Actions下拉框中，選擇Import key pair，將aws_kp.pub上傳。
在其他的Region，重復上述動作，將key pair上傳，這樣在多個Region創建的EC2可以使用同一個私鑰進行登錄。
部署TE Agent的操作路徑為：在ThousandEyes的界面中，選擇Cloud & Enterprise Agents，再選擇Agent Settings，進一步選擇Enterprise Agents，點擊Add New Enterprise Agent。在右側出現的界面中，選擇IaaS Marketplaces，在該界面中點擊Launch in AWS，跳轉到AWS的登錄界面，並自動進入CloudFormation的界面，該界面已將Stack模板選擇好了。
Stack模板的鏈接：
https://s3-us-west-1.amazonaws.com/oneclick-ea.aws.thousandeyes/aws-ea-oneclick.yaml
該模板包含兩個組件：EC2 Instance 和 Security Group。
按照上文的部署指南填寫表單，並點擊下一步，直至完成部署。
在完成安裝後，可以使用私鑰登錄到虛機，注意：用戶名為 ubuntu，不是ec2-user 或 root。
在兩個不同的Region，us-east-1 和 ap-southeast-1 分別部署一個TE Agent。
大約5分鍾後，即可在app.thousandeyes.com的界面中看到兩個TE Agent上線。
分別執行兩種測試，一個是通過公網IP進行雙向測試，一個是創建VPC Peering後，使用私有地址進行測試，比較兩者之間的差異。
在ThousandEyes的Agent Settings界面中，點擊Agent，在右側的網頁中，選擇Advanced Settings，將地址設置為Agent的公網IP地址。
在Test Settings中，選擇Add New Test，Layer選擇Network，Test Type選擇Agent to Agent。
選擇一個Agent作為Target，另一個Agent作為源，測試方向選擇雙向。
經過一段時間後，ThousandEyes上即可呈現測試結果。
測試持續了一個小時左右，測試結果如下：
AWS us-east-1 to ap-southeast-1 Using Public IP
在可視化的路徑分析圖中，觀察到如下信息：
本次測試的方法同上，只是需要將Agent的IP地址修改為使用私有IP地址，兩個Region的VPC之間建立VPC Peering。
測試結果如下：
AWS us-east-1 to ap-southeast-1 Using Private IP
在可視化的路徑分析圖中，觀察到如下信息：
做完兩次測試，第二天檢查了一下AWS的賬單，預計花費了0.29美金。
https://zwskwtsea.share.thousandeyes.com/
https://aieajezsh.share.thousandeyes.com/
Ⅷ aws 入門：建立含有兩個子網的網站
接觸aws一個月時間，網上看了很多材料，自己做了一個包含兩個公有字網的網站，記錄下大概過程以備忘
1. 在VPC中創建一個vpc
2.在建立好的VPC中，創建兩個公有字網，為什麼要兩個公有字網，因為之後啟用https的話，需要啟用負載均衡，自己只試了alb，alb要求兩個位於不同可用區中的公有字網
3.