用 nslookup查詢 IP及DNS
nslookup 成功
成功的 nslookup 指令將從 DNS 伺服器會回傳一或多個 IP 位址。
nslookup 失敗
若指令失敗，將不會回傳任何 IP 位址。常見原因包含：
AZURE NSG 白名單設定
NSG可透過CMD顯示列表，也可使用CMD增加rule
參考文件:
https://learn.microsoft.com/en-us/cli/azure/network/nsg/rule?view=azure-cli-latest#az-network-nsg-rule-create
AWS 作為雲端商，會在世界各大地區建立基礎設施，比如說東京(Tokyo)就是其中之一。而一個實體地區的概念對到 AWS 的架構中，就是 Region，如下圖。
而在每個 Region 內，會建立多個 Availability Zone ，簡稱 AZ。比如說，在一個 Region 上面我們可以有三個 Availability Zone，如下圖。
那在我們對 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)。
例如東京區域名稱
本機區域的代碼為其區域代碼
同樣的，如果是 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 的費用計費。
華為雲-CDN提供资源的缓存刷新和缓存预热功能
CDN提供资源的缓存刷新和缓存预热功能。
https://support.huaweicloud.com/intl/zh-cn/usermanual-cdn/zh-cn_topic_0281233366.html
在修改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以上（依日誌需求選擇版本）
建立完成後，在叢集資訊頁下方就會看到【日誌】標籤
公有雲如有更換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）
5.騰訊雲（Tencent Cloud）:
登錄到騰訊雲控制台（https://console.cloud.tencent.com）。
選擇您的CVM實例。
點擊雲服務器主機之後，找到右側更多操作裡面有個【重置應用】
更換鏡像接著進入系統重裝鏡像修改界面，選擇公共鏡像。根據需求選擇需要的OS系統，接著點擊確定
點擊開始重裝系統之後，如圖開始進入重裝操作系統界面。之前的數據將全部格式化。
等待片刻之後，系統更換完成。
在阿里雲Dynamic Content Delivery Network（DCDN）服務針對地區做更換節點
1.點擊阿里雲控制台選取全站加速(或是使用搜尋查找DCDN)
進入EC2後點選左邊的EC2全域檢視。
進入該主機後點選下方的監控。
.png)
另外依照過往經驗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]。
參考文件：
[2] https://docs.aws.amazon.com/zh_tw/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html
原廠建議為了減輕未來此類底層硬體故障的影響，可建立CloudWatch告警監控EC2實例，以利及時發現問題並通報處理。
原廠提供的參考連結:
[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
剛好之前有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]。
參考官方說明：
[2] https://docs.aws.amazon.com/zh_tw/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html
在GCP的監控中，指標瀏覽器可用來確認業務使用和應用程式的效能
1. 在GCP搜尋列搜尋Metrics Explorer就可進入到如下選單中
2. 接著選擇要查看的資源名稱及標籤
3. 選擇要查看的時間範圍，有預設的或是也可以選Custom自訂時間
4. 點開SHOW ADVANCED OPTIONS
5. 校正函式選擇sum
6. 這邊可點選要用哪種圖示顯示
