你是哪種 AWS服務?
這個還蠻另類的心理測驗耶, 來測看看你是什麼 AWS服務.
我的結果是 S3
快來測試看看你是哪種 AWS的服務吧!
分類
標籤: aws
根據 AWS的官方資料 – https://docs.aws.amazon.com/dlami/latest/devguide/gpu.html, 得到共有以下幾種 EC2中使用 GPU: P3, P4, P5, G3, G4, G5, G6, G5g, 其中 G5g 是 ARM-Based CPU, 而 GPU又有以下幾種: Tesla V100, Tesla A100, Tesla H100, Tesla M60, T4, A10G, L4.
根據上面的內容, 整理一下相關的價格與 GPU數量, GPU記憶體等資料, 彙整成一個方便使用的查找表:
請參考: https://sample.diary.tw/aws-gpu/
大家可以多加利用, 查找使用上適合的價格與規格資料.
從這裡看來的:
AWS 宣布在台部署全新 AWS 本地區域，擴充本地基礎設施
https://aws.amazon.com/tw/events/taiwan/news/aws-local-zone-in-taiwan/
Amazon Web Services（AWS）宣布將在台灣推出全新 AWS Local Zone（本地區域）。AWS 本地區域為一種新型的基礎設施部署類型，將 AWS 運算、儲存、資料庫及其他服務部署在緊鄰人口密集、產業集中，或資訊科技中心的雲端邊緣，讓企業及機構客戶更近距離地為終端用戶或本地端資料中心部署毫秒級延遲的應用。
什麼是 Local Zone? 可以參考官方的資料:
https://aws.amazon.com/tw/about-aws/global-infrastructure/localzones/features/
雖然並不是全功能的 AZ (可用區域) 也沒有 S3, 不過繼之前來台的邊緣網路後, 再來提供了本地區域, 也算是有更進一步了呢.
不過沒有提供布署的地點與俱體上時間就是了.
相關新聞:
今天早上開始, AWS 位在香港的 AP-EAST-1 Region 有大量的異常, 包含了 EC2 與 RDS, 看起來還蠻嚴重的.
根據 AWS 服務狀態頁來看:
https://status.aws.amazon.com/
等看看稍晚有沒有其他訊息或新聞..
[2021/6/19 18:53]
目前看起來都恢復的差不多了, 還好終於恢復了呢.
分類
EC2如何擴充開機碟空間
EC2 是 AWS 上的虛擬機器, 一般來說是用來做工作負載的.
如何擴充開機磁碟, 可以利用 EBS 的空間直接線上設定即可.
但是作業系統還不會擴充, 需要下一些指令來進行.
先參考這裡:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
我的流程如下:
[ec2-user ~]$ sudo file -s /dev/xvd*
/dev/xvda: DOS/MBR boot sector ..
/dev/xvda1: Linux rev 1.0 ext4 filesystem data …
/dev/xvdf: SGI XFS filesystem data …
[ec2-user ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 8G 0 part /
[ec2-user ~]$ sudo growpart /dev/xvda 1
[ec2-user ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 16G 0 part /
[ec2-user ~]$ sudo xfs_growfs /dev/xvda1
[ec2-user ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 16G 1.9G 14G 12% /
很容易地在線上完成擴充, 不過在 EBS 設定擴大空間時, 會影響 EC2 效能, 但不致於不能工作. 記得最好先做備份或快照, 避免不必要的資料異常或損失.
繼續閱讀:
https://hackernoon.com/tutorial-how-to-extend-aws-ebs-volumes-with-no-downtime-ec7d9e82426e
分類
AWS的EC2將以秒計費
厲害, 雲端資源原來遊戲規則要調整了, 以小時計費計價的基礎將要進行調整, 改為以秒計費, 真的來到了用多少付多少的計價方式.
參考這篇資料:
https://aws.amazon.com/tw/blogs/aws/new-per-second-billing-for-ec2-instances-and-ebs-volumes/
其中提到:
Effective October 2nd, usage of Linux instances that are launched in On-Demand, Reserved, and Spot form will be billed in one-second increments. Similarly, provisioned storage for EBS volumes will be billed in one-second increments.
也就是從 2017/10/2 起, EC2, EBS 都會以”秒”計費, 真的太棒了.
繼續閱讀:
https://www.bnext.com.tw/article/46219/amazon-aws-per-second-billing
[2017/9/28 9:34]
結果 Google Cloud Platform 也來加入混戰了, 以秒計費, 即刻開始:
https://www.bnext.com.tw/article/46330/following-aws-google-compute-engine-also-moves-to-per-second-billing
今天早上9點多開始的, 原來要用 run.quikLAB 的服務, 網頁有些問題, 剛好在忙, 沒特別去查.
不過後發現像 dropbox 也有這個狀況(因為 dropbox.com 網頁也用了 cloudfront), 開啟了 firebug 的 network 功能, 檢查一下, 原來是 cloudfront dns 解析失敗.
經交錯測試檢查, 目前查得狀況如下,
- 走 hinet 電路問 hinet dns 失敗
- 走其他電路問 hinet dns 成功
- 走 hinet 電路問其他 dns 成功
- 走其他電路問其他 dns 成功
如此一來, 變成 hinet 網內用 hinet dns 的用戶, 會無法正常檢視有使用到 cloudfront 功能的網站, 太奇怪了.
- 若是人為刻意設定, 一定有很大的陰謀
- 若是不小心設錯, 持續了這麼久, MRTG表應該早就發現了, 還不處理也很妙
所以, 再觀察看看. 這個問題很大.
[12:12]
目前已觀測正常了. 看起來可能是第二個原因吧.
aws (amazon web service) 終於有自己的 route53 管理介面了(console).
以往要管理 route53, 要嘛就是用 api (http://docs.amazonwebservices.com/Route53/latest/APIReference/), 不然要 ui 的管理介面就得用 3rd party 的 DNS30: http://www.dns30.com/, 對於不熟悉的人來說, 還真的不太方便.
現在 aws 推出了 route53 的管理介面了, 真的可以方便在使用 route53 服務操作上, 利用友善的管理介面, 無論是在新增修改管理上, 都更加的方便了呢!
有在使用的朋友們, 可以快去試看看: https://console.aws.amazon.com/route53/home