2020ironman 12th – Modern Web – Day09 – Amazon Lightsail 轉 AWS EC2

分享

為何要轉換?

AWS 官方說明 <-連結->

其實就主機資源這件事情是最容易理解的

但就真實應用情境上來說

如果你希望有真實的網路環境使用

可以建立真正的私有網段或者是控制路由等等的功能

Lightsail是無法協助的

因為他的VPC是簡約版的

如果需要完整的周邊功能比如控制路由或與AWS其他幾百項的服務完整結合都還是要轉換到EC2的

轉換方式

轉換方式是由主機產生Snapshot再將這個轉換成AWS EC2 AMI

所以主機一定是需要一段時間停機的

製作方式只要進到主機的控制介面中切換至Snapshots就可以看到『Create snapshot』的按鈕了

這時候點選『Create snapshot』後輸入名稱及點選Create即可產生snapshot

要注意點選Create後會有一瞬間主機會是暫停的狀況來產生快照

會發生SSH斷線或者服務連不到的狀況幾秒

如果你的環境不能當下不能停機要注意這狀況喔

建立過程需要數分鐘(等待)

建立完成

點選右邊的點點就可以看到

點選『Export to Ec2』

確認轉換

告警頁面

這邊資訊很重要因為用這邊開啟的主機如果有用過SSH登入會殘留原先的key

建議建立EC2後要刪除

刪除方式如連結文章下半段 <--連結-->

如何找到該AMI

進到AWS登入後的首頁進入EC2

點選『AMIs』選擇『Owned by me』尋找與Lightsail snapshot 同名的『AMI Name』

這樣就可以開始建立AWS EC2了

Read more

雲端架構延遲問題:為什麼AP與DB不能放太遠?

雲端與地端的架構差異認知不足導致的性能陷阱 前言 許多企業在上雲初期,經常基於成本考量或錯誤認知,將應用程式伺服器(AP)與資料庫(DB)部署在不同區域。這種做法在地端環境中影響較小,但在雲端環境中卻會造成嚴重的性能問題。本文透過台北-東京的實際案例,說明距離對雲端架構的致命影響。 核心問題: * 地端思維:同個機房內不同區域延遲可忽略 * 雲端現實:跨區域延遲可達數十毫秒 * 結果:連線建立時間從毫秒級暴增到秒級 1. 地端 vs 雲端的延遲差異 1.1 地端環境的延遲特性 傳統地端機房: 同機房不同機櫃:RTT < 1ms 同城市不同機房:RTT < 5ms 同國家不同城市:RTT < 20ms 地端架構師的經驗: * AP和DB分別放在不同機櫃:幾乎無延遲影響 * 災備機房放在不同城市:RTT約10-15ms,可接受 * 習慣性認為「網路延遲不是問題」

By Albert Yu