幹壞事是進步最大的原動力
看到「Study Notes - CloudWatch」這篇後想到可以把 CloudWatch Logs 寫下來...
目前的玩法是參考「Quick Start: Install and Configure the CloudWatch Logs Agent on a Running EC2 Instance」這篇設定 IAM Role 的權限，然後安裝 agent，最後設定要丟什麼上去，其實這塊還蠻簡單的...
然後用 kennu/cwtail 這隻程式負責幫你跑出像 tail -f 的效果。像是 cwtail --profile=myaccount -e -f -s -t /var/log/syslog 這樣的用法 (參數的意義可以直接跑 cwtail 看到)。
不過他的 -n 好像不會動，跑下去都會從頭拉 XDDD
AWS 提高了 EC2 Reserved Instances 的彈性：「New – Instance Size Flexibility for EC2 Reserved Instances」。
比較簡單的說 (但不是太精確)，就是針對 family type 就可以了，同一個 family type 會依照比例系統自動計算。
舉個例子來說，買 c4.8xlarge 的 RI 可以被計算在兩台 c4.4xlarge 上。而買 c4.4xlarge 的 RI 後，c4.8xlarge 的機器可以有一半透過 c4.4xlarge 計算，另外一半依照原價算。就不需要自己調來調去了...
整個新的計算方式回溯到 2017/03/01 生效。
看到「Netflix Security Monkey on Google Cloud Platform」這則消息，看起來 Netflix 也往 Google Cloud Platform 在嘗試了。
Netflix Security Monkey 本來是對 AWS 分析，現在則是開始支援 GCP (雖然還在 beta)：
Security Monkey monitors policy changes and alerts on insecure configurations in an AWS account. While Security Monkey’s main purpose is security, it also proves a useful tool for tracking down potential problems as it is essentially a change tracking system.
透過混搭本來的 shared IP address (已經對各 ISP 有信用) 與客戶租用的 dedicated IP address 混發，然後一段時間後養起來 (最多 45 days)：「Amazon SES Can Now Automatically Warm Up Your Dedicated IP Addresses」。
Amazon SES controls the amount of email that can be sent through an IP address. Amazon SES uses a predefined warm-up plan that indicates the maximum number of emails that can be sent daily through an IP address to ensure the traffic is increasing gradually over 45 days.
要注意的是，這個過程需要發五萬封才有辦法養出來，不是設上去就會自己養：
After you successfully warm up your dedicated IPs (either by yourself or by using the Amazon SES automatic warm-up mechanism), you must send at least 50,000 emails per dedicated IP per day so that the IPs maintain a positive reputation with ISPs. To avoid throttling by the ISPs, avoid sending a high volume of emails soon after the completion of warm-up; we recommend gradually increasing the volume for better deliverability.
現在弄 mail service 超麻煩的...
看到「Amazon EC2Rescue is now available」這個，在「How can I use EC2Rescue to troubleshoot and fix common issues on my EC2 Windows instance?」這邊則解釋了用途。
拿來解 Windows 上常見的問題的工具，也可以單純拿來拉 log？不過要注意的是版本：
Note: EC2Rescue can only be run on Windows Server 2008 R2 or later, but it can also analyze the offline volumes of Windows Server 2008 or later.
像是 Windows 2003 這些古董是沒辦法跑的 XDDD
Amazon Aurora 本來最小台只支援到 t2.medium，現在則是多支援到 t2.small 了，對於更小的需求會更方便：「Amazon Aurora Cuts Entry-Level Pricing in Half With Support for T2.Small Instances」。
不過如果真的要小，而且不考慮會急速成長擴充的話，還是會往標準的 RDS 靠吧... 價錢上還是比較便宜。
看到「Two frequently used system calls are ~77% slower on AWS EC2」這篇在講 gettimeofday 與 clock_gettime 的效能，另外搜資料時發現應該也是作者提問的「gettimeofday() not using vDSO?」這篇。
在 EC2 比較新的機器上用 tsc 應該是沒問題的 (在 2015 的時候官方就這樣建議了)：
it seems tsc support in Xen has improved with version 4.0 and with improved CPU support in Sandy Bridge+ platforms. Modern EC2 machines should be okay with tsc. Check Xen version using dmesg | grep "Xen version". Amazon recommended the tsc clocksource already in re:Invent 2015 (https://www.slideshare.net/AmazonWebServices/cmp402-amazon-ec2-instances-deep-dive). I'm not yet running to production with this, but the situation doesn't seem as bad as implied by packagecloud.
開了一台 t2.micro 看 /sys/devices/system/clocksource/clocksource0/current_clocksource 看起來目前是設成 xen：
ubuntu@ip-172-31-22-165:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen
在「(CMP402) Amazon EC2 Instances Deep Dive」這邊也可以看到一些資料 (page 24 與 page 25)：
Google 在這次 Google Cloud Next '17 公佈了 Google Cloud Platform Free Tier 的 Always Free Usage Limits，也就是終身免費的方案。
這次宣佈的包括了許多服務。掃了一遍應該會去玩 GCE 的部份，包括了 0.6GB RAM 的機器以及 1GB 的對外流量 (不過到中國與澳洲要另外計費，不包含在這個範圍內)。
領先者的 AWS 不知道會不會也跟進...
看開發記錄，應該很久了... 這次是 donnemartin/saws：
用 Python 寫的，所以用 pip 就可以跑，不過目前還是不支援 profile：
Command line options for starting SAWS with a specific profile are under development.
所以自己用還可以 (因為只有一個帳號)，公司有一堆帳號得切來切去就沒辦法了，先丟著...
在「Thou shalt not depend on me: analysing the use of outdated JavaScript libraries on the web」這邊看到對 JavaScript Library 的研究。
jQuery 沒有什麼疑問的還是最大宗，查了一下應該是 CVE-2011-4969 的影響，對 jQuery 1.6、1.6.1、1.6.2 三個版本有影響。
另外也提到了 hosting 的部份，可以看到 Google Hosted Libraries 還是佔有最高的比率。