AWS跨帳號傳輸與跨區域傳輸收費定義

   

AWS Region 介紹

AWS 作為雲端商，會在世界各大地區建立基礎設施，比如說東京(Tokyo)就是其中之一。而一個實體地區的概念對到 AWS 的架構中，就是 Region，如下圖。

而在每個 Region 內，會建立多個 Availability Zone ，簡稱 AZ。比如說，在一個 Region 上面我們可以有三個 Availability Zone，如下圖。

Availability Zone 代表著「邏輯資料中心」，因此還不是一種實體的對應，更精確來說，一個 Availability Zone 中，會有著多個「實體資料中心」，也就是實際放上主機與硬體設備等的地方。
如下圖所示，東京地區對應到一個 AWS Region 概念。每個 region 上有著多個 Availability Zone，每個 Availability Zone 裡頭又有著多個實體資料中心，藍色長方體大樓圖像即代表著，在 AZ 中的多個實體資料中心。

AWS Region 與 VPC 關係介紹

那在我們對 Region、Availability Zone、實體資料中心有所概念之後，我們來看到 AWS VPC 這個概念。
VPC 為一種「虛擬的網路區域」，我們會將虛擬資源放入這個網路區域進行管理，比如說 EC2，他會幫我們管理其中的網路流通，如下圖。

在每個 VPC 之中，將可以涵蓋多個 Subnets，Subnet其實也就是一種「更小單位的虛擬網路區域」，如下圖。

而 Subnet 與 AZ 的關係為何？每個 Subnet 都會對應到一個 Availability Zone，而在 AWS 建議的架構中有所謂 High Availability (HA) 的概念，換句話說，也就是要我們把程式部署到不同的 Availability Zone 中。

所以當我們把程式放到 Subnets 之中，我們要確保這些 Subnets 是否對應到不同的 Availability Zone 中，如果是的話，我們就能達到 High Availability (HA)，如下圖：紅線部份代表 Subnet 與 Availability Zone 之間的對應，可以看到此處的 VPC 透過不同 Subnet 對應到多個 AZ，達到了 High Availability (HA)。

 如何分辨AZ

 例如東京區域名稱

本機區域的代碼為其區域代碼

ap-northeast-1

後續跟著一個字母識別符，代表其實體位置。

ap-northeast-1a

ap-northeast-1c

ap-northeast-1d

從 AZ 進到另外一個 AZ 時，in 與 out 都要收費：

所以直接用 US$0.01/GB 的計算是不夠的，得用 US$0.02/GB 來計算

資料來源: https://aws.amazon.com/tw/ec2/pricing/on-demand/#Data_Transfer

IPv4：從公有或彈性 IPv4 地址「傳入」和「傳出」的資料傳輸依每個方向 0.01 USD/GB 的費用計費。

同樣的，如果是 Public IP 與 Elastic IP 也都是雙向收費，跨 VPC 也是雙向收費，所以都要用 US$0.02/GB 來算：

在相同可用區域的 Amazon EC2、Amazon RDS、Amazon Redshift、Amazon ElastiCache 執行個體和彈性網路界面之間傳輸的資料免費。

在相同 AWS 區域的 Amazon S3、Amazon EBS 直接 API*、Amazon Glacier、Amazon DynamoDB、Amazon SES、Amazon SQS、Amazon Kinesis、Amazon ECR、Amazon SNS 或 Amazon SimpleDB 和 Amazon EC2 執行個體之間的直接傳輸的資料免費。如果有其他 AWS 服務在資料傳輸的路徑中，您會被收取其關聯的資料處理成本。這些服務包含 (但不限於) PrivateLink 端點、NAT 閘道和 Transit Gateway。

*對於 Amazon EBS 直接 API，如果使用 FIPS 端點，將收取資料傳輸費。

在相同 AWS VPC 內使用私有 IP 地址從 Amazon Classic 和 Application Elastic Load Balancer「傳入」和「傳出」的資料傳輸，以及 EC2 執行個體和負載平衡器之間的資料傳輸免費。

IPv6：從不同 VPC 的 IPv6 地址「傳入」和「傳出」的資料傳輸依每個方向 0.01 USD/GB 的費用計費。

資料來源:https://docs.aws.amazon.com/zh_tw/vpc/latest/peering/what-is-vpc-peering.html

資料來源https://blog.gslin.org/archives/2022/06/25/10758/aws-%E5%9C%A8%E5%90%8C%E4%B8%80%E5%8D%80%E4%B8%8D%E5%90%8C-az-%E9%A0%BB%E5%AF%AC%E8%B2%BB%E7%94%A8%E7%9A%84%E7%89%B9%E5%88%A5%E5%9C%B0%E6%96%B9/

AWS EC2 console連接權限

檢視序列主控台 (主控台) 的帳戶存取狀態

在開啟 Amazon EC2 主控台。

在左側導覽窗格中，選擇 EC2 Dashboard (EC2 儀表板)。

EC2 Serial Console access (EC2 序列主控台存取) 

下列螢幕擷取畫面顯示該帳戶被禁止使用 EC2 序列主控台。

資料來源:https://docs.aws.amazon.com/zh_tw/AWSEC2/latest/UserGuide/configure-access-to-serial-console.html#serial-console-iam

AWS 使用 console連接設備，先確認設備所在位置是否有支援

https://aws.amazon.com/tw/about-aws/whats-new/2021/03/introducing-ec2-serial-console/?nc1=h_ls

可參考上列AWS官方文檔

華為雲-CDN提供资源的缓存刷新和缓存预热功能

 

華為雲-CDN提供资源的缓存刷新和缓存预热功能

CDN提供资源的缓存刷新和缓存预热功能。

• 缓存刷新：提交缓存刷新请求后，CDN节点的缓存内容将会被强制过期，当用户向CDN节点请求资源时，CDN会直接回源站请求对应的资源。
• 缓存预热：提交缓存预热请求后，源站将会主动将对应的资源缓存到CDN节点，用户就能直接从CDN节点获取到最新的资源。

https://support.huaweicloud.com/intl/zh-cn/usermanual-cdn/zh-cn_topic_0281233366.html

AWS ElastiCache 的 Redis叢集沒有【日誌】標籤

在修改Redis叢集時，依照官方文件說明第4點可選擇“日誌”索引標籤，但可能會遇到客戶反應在頁面上找不到“日誌”標籤

https://docs.aws.amazon.com/zh_tw/AmazonElastiCache/latest/red-ug/Console_Log.html

原因是客戶建立的Redis叢集引擎版本過低，如官方文件所述：

引擎 6.0 以上版本的 Redis 快取叢集和複寫群組，支援 Redis 慢速日誌。

引擎 6.2 以上版本的 Redis 快取叢集和複寫群組，支援此 Redis 引擎日誌。

https://docs.aws.amazon.com/zh_tw/AmazonElastiCache/latest/red-ug/Log_Delivery.html

【如何建立可傳送日誌的Redis叢集】

在建立叢集時的《步驟1》選【設定和建立新的叢集】

引擎版本選6.0或6.2以上（依日誌需求選擇版本）

《步驟2》進階設定往下拉就會看到日誌相關設定

建立完成後，在叢集資訊頁下方就會看到【日誌】標籤

GCP、AWS、AZURE、阿里雲、騰訊雲，公有雲更換OS系統教學

公有雲如有更換OS系統需求，可能會造成資料遺失。
操作系統更換過程中可能需要停止和重新啟動虛擬機，這可能會導致服務中斷。
在執行更換操作之前，請確保已經備份重要的數據並知曉相關的風險。
另外，根據不同的雲服務提供商和平台，步驟和界面可能會有所不同，因此請參考相關的官方文檔和指南進行操作。

 1.GCP（Google Cloud Platform）:

登錄到Google Cloud Console（https://console.cloud.google.com）。

選擇VM執行個體→停止虛擬機，選擇“編輯”以修改VM的設置。

新增硬碟，選擇需要的操作系統並建立新硬碟後，掛載新的硬碟作業系統

啟動虛擬機並驗證更換是否成功。

2.AWS（Amazon Web Services）:

EC2建立完成後便無法更改作業系統，建議重新建置新的EC2後，掛載舊硬碟資料至新執行個體上。

3.Azure（Microsoft Azure）:

虛擬機器建立完成後便無法更改作業系統，建議重新建置新的虛擬機器後，掛載舊硬碟資料至新執行個體上。

4.阿里雲（Alibaba Cloud）:

登錄到阿里雲管理控制台（https://home.console.aliyun.com）

找到需要重裝系統的ECS實例，先停止實例：點擊“更多”“實例狀態”“停止”（如果實例已經停止，請忽略此步驟）
點擊“更多”“磁盤和鏡像”“更換系統盤”

ECS實例更換系統盤後，磁盤ID會變更，原系統盤會被釋放

5.騰訊雲（Tencent Cloud）:

登錄到騰訊雲控制台（https://console.cloud.tencent.com）。

選擇您的CVM實例。

點擊雲服務器主機之後，找到右側更多操作裡面有個【重置應用】

更換鏡像接著進入系統重裝鏡像修改界面，選擇公共鏡像。根據需求選擇需要的OS系統，接著點擊確定

點擊開始重裝系統之後，如圖開始進入重裝操作系統界面。之前的數據將全部格式化。

等待片刻之後，系統更換完成。

阿里雲 Dynamic Content Delivery Network（DCDN）服務切換加速區域

 在阿里雲Dynamic Content Delivery Network（DCDN）服務針對地區做更換節點

1.點擊阿里雲控制台選取全站加速(或是使用搜尋查找DCDN)

2.進入域名管理頁面

3.找到需要設置節點的域名，點擊“配置”按鈕，進入域名管理頁面

4.點選加速區域中的"修改配置"進行加速區域更換

部分配置及地區限制可參考如下

AWS EC2底層硬體故障

最近剛好碰上EC2無預警自動重啟的情況。

點選EC2，查看有異常的機器。

進入EC2後點選左邊的EC2全域檢視。

進入後查看有建立的執行個體有哪些，接著確認要查詢的EC2所在區域並點選。

進入後在搜尋欄位輸入要查詢的資源ID並點選。

進入該主機後點選下方的監控。

於監控頁面內發現在5/2有出現狀態檢查失敗1個的訊息，並且CPU與網路當下都處於失連的狀況。

原廠回覆:此為底層硬體發生不可預期的故障，故系統自動重啟實例轉移至其它底層硬體並恢復，確認於轉移後的底層硬體正常運行。

另外依照過往經驗AWS不會主動發送非預期故障的通知信息，若想針對EC2異常監控進行設定。

建議可針對各台 EC2 的 system health check 進行監控，並在有異常時透過 SNS 寄發通知 [1]。

以下實作方式：

(1) 選取您想要監控非預期故障的 EC2 機器，選擇狀態檢查標籤，然後選擇動作 > 建立狀態檢查警示。

(2) 警示通知可以選取現有 Amazon SNS topic，或是輸入名字以新增 SNS topic

(3) 在 Type of data to sample，可以選擇 Status check failed:system 以只檢查底層硬件故障，或保留 Status check failed:either 以監控所有的檢查失敗。

(4) 若您想在 cloudwatch dashboard 上監控，可以選擇 Add to dashboard (新增至儀表板)

建立完 cloudwatch alarm 之後，您就能透過 cloudwatch alarm 發送通知到 SNS 上。

並將信件寄送至 SNS topic 訂閱的信箱中 [2]。

參考文件：

[1] https://docs.aws.amazon.com/zh_tw/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#using-cloudwatch-new-console2

[2] https://docs.aws.amazon.com/zh_tw/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html

原廠建議為了減輕未來此類底層硬體故障的影響，可建立CloudWatch告警監控EC2實例，以利及時發現問題並通報處理。

原廠提供的參考連結:

[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#system-status-checks

[2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html#cloudwatch-recovery

[3] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingAlarmActions.html#AddingRecoverActions

 

 

AWS 執行個體存放區(instance-store)只適合暫時存放數據，不適合存取重要的檔案經驗分享-資料遺失

 剛好之前有EC2主機有資料移失做個分享:

Q.Instance/system status checked failed 異常原因，可能因以下原因造成:

網路連線中斷/系統電力中斷/實體主機的軟體問題/實體主機上會影響網路連線的硬體問題

Q. 什麽重啟方式會導致數據丟失？

若您只是 reboot instance，資料並不會遺失。只要您有 stop 您的機器，由於此行為會導致實體機器更換，因此您的 instance store 資料也會遺失。僅有存放在如同 EBS、EFS 中的資料，才會被一起遷移至新的機器。

所以:重要的數據，請存放於  Amazon S3、Amazon EBS 或 Amazon EFS，而 "執行個體存放區(instance-store)" 只適合暫時存放數據，不適合存取重要的檔案。

如工作上接手管理AWS- EC2 名字帶有 "DB" 的字樣的 EC2 需確認使用到 c5d 及 i3 機器，如有重要資料需要保存，也請務必記得另外存放一份到 S3、EBS、EFS ...等永久的儲存空間中，以免有更多資料遺失。

EC2重啟後 disk無法掛載

A:宿主機(physical host)" 出現硬件的非預期故障(Hardware issues)時"，資料必然會不見。 "沒有任何方式" 可以恢復您在 "執行個體存放區(instance-store)" 的數據。

1》reboot是指系統層的reboot指令嗎？ aws後台 重啟實例 = 系統層 reboot指令 是嗎？

是的，不論是機器內 OS 執行 reboot，或是透過 AWS console 點選 "重啟實例 "，皆不會更換您的宿主機。由於宿主機不會更換，因此 instance store 及其資料不會丟失。

2》如果在系統層 執行shutdown指令，數據會丟失嗎？

會，shutdown 指令如同在 AWS console 點選  "停止實例"，會更換宿主機。

由於宿主機會更換，instance store 也會被更換，導致其資料會丟失。

3》如果在系統層 執行shutdown指令 + aws後台 執行 啟動現有實例，數據會丟失嗎？

會，如同 2》說明，shutdown 指令如同在 AWS console 點選  "停止實例"，會更換宿主機。

由於宿主機會更換，instance store 也會被更換，導致其資料會丟失。

建議可針對各台 EC2 的 system health check 進行監控，並在有異常時透過 SNS 寄發通知 [1]。

以下實作方式：

(1) 選取您想要監控的 EC2 機器，選擇狀態檢查標籤，然後選擇動作 ， 建立狀態檢查警示。

(2) 警示通知可以選取現有 Amazon SNS topic，或是輸入名字以新增 SNS topic

(3) 在 Type of data to sample，可以選擇 Status check failed:system 以只檢查底層硬件故障，或保留 Status check failed:either 以監控所有的檢查失敗。

(4) 若您想在 cloudwatch dashboard 上監控，可以選擇 Add to dashboard (新增至儀表板)

建立完 cloudwatch alarm 之後，您就能透過 cloudwatch alarm 發送通知到 SNS 上。

並將信件寄送至 SNS topic 訂閱的信箱中 [2]。

參考官方說明：

[1] https://docs.aws.amazon.com/zh_tw/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#using-cloudwatch-new-console2

[2] https://docs.aws.amazon.com/zh_tw/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html

GCP Metrics Explorer查看流量總和

在GCP的監控中，指標瀏覽器可用來確認業務使用和應用程式的效能

1. 在GCP搜尋列搜尋Metrics Explorer就可進入到如下選單中

2. 接著選擇要查看的資源名稱及標籤

3. 選擇要查看的時間範圍，有預設的或是也可以選Custom自訂時間 

4. 點開SHOW ADVANCED OPTIONS

5. 校正函式選擇sum

6. 這邊可點選要用哪種圖示顯示

AWS Region與VPC關係介紹及NACL與SG介紹和網路安全配置

一、以下為Region與VPC關係介紹

1. Region(地區)：雲端商會在世界各大地區建立基礎設施，例如東京，而一個實體地區 的概念對到AWS的架構中，即為Region。

2. Availability Zone(邏輯資料中心)：簡稱AZ，一個Region上面可以有三個AZ，但其為 邏輯資料中心，故還不是一個實體的對應，一個AZ中會有多個實體資料中心， 也就是實際放上主機與硬體設備的地方。

3. VPC(虛擬的網路區域)：虛擬資源將放入這個網路區域進行管理，例如EC2， VPC會幫我們管理其中的網路流通。

4. Subnet(更小單位的虛擬網路區域)：每個VPC中可以涵蓋多個Subnet，而每個Subnet都會 對應到一個AZ。

AWS 定價計算工具

AWS有提供線上服務估價的網頁，點選下列網址就可連至AWS 定價計算工具

https://calculator.aws/#/addService

可選擇以地區來搜尋可用的服務

或是直接搜尋所有服務

然後在搜尋列上打上欲查詢的服務名稱，找到想要的服務後點選設定就會進入對應服務試算價格的頁面

Google Cloud Platform GCP以主控台創建VM Compute Engine執行個體及透過SSH連線

1. 登入完成後會出現此介面，選擇左上方目錄標籤，會出現Cloud總覽，點選Cloud總覽，在點擊VM執行個體。

2.進入介面後，點選建立執行個體

3.選擇:區域部份優先選擇離你需要的服務最近的地點即可，離越近伺服器越穩定，系列、機器類型和硬碟選擇最低階即可。

4.建立完成後，會回到這個畫面，點選啟用後，在SSH標示旁有個小箭頭，點下去就會有下拉清單供選擇要如何SSH連線，我們這邊選擇使用瀏覽器開啟。

5.點選開啟後就會出現此畫面代表成功連線。

Google Cloud BigQuery傳輸問題

在 GCE VM 上，使用 Python Client BigQuery API查詢資訊時，如果有遇到Network 導出傳輸速率非常慢的情形。可以先嘗試排除配置不足的傳輸問題，但如仍有此情況。則可以安裝Google Cloud BigQuery Storage。

 

因目前Google Cloud 上 BigQuery 的用戶主要為以下兩種訪問的方式：

1.使用 tabledata.list 或 jobs.getQueryResults REST API 方法存取基於記錄的分頁。 BigQuery API以分頁方式提供結構化的行響應，適合小型結果集。

2.使用 BigQuery 提取作業批量導出數據，將表數據以各種文件格式（如 CSV、JSON 和 Avro）導出到 Cloud Storage。數據的導出受到每日配額和導出過程的批處理性質的限制。

而透過BigQuery Storage Read API 提供了第三個對先前選項的改進。 當使用 Storage Read API 時，結構化數據以二進制序列化格式通過網絡發送。 這使得一組結果的多個使用者之間可以有額外的並行性。
但Storage Read API 不提供與管理 BigQuery 資源（例如數據集、作業或表）相關的功能。