In 2013, the CA/Browser Forum passed an intent to allow a DNS domain name (joeblow.com) holder to specify one or more Certification Authorities (CAs) authorization to issue certificates for their domain. No other CAs would be authorized to issue that domain’s certificate.
This is accomplished by the domain holder adding a “CAA” record to their DNS for their domain. This helps mitigate the problem that the public CA trust system is only as strong as its weakest CA.
Organized in 2005, the CA/Browser Forum is a voluntary group of certification authorities (CAs), vendors of Internet browser software, and suppliers of other applications that use X.509 v.3 digital certificates for SSL/TLS and code signing.
View the full ballot.
On August 21st, 2017, Amazon Web Services (AWS) announced that their DNS service “Route 53” now supports CAA records.
We currently run some magnetic EBS volumes for data storage accessed by EC2 instances. Last month AWS announced the availability of Live Volume Modification with Elastic Volumes on EBS. This would enable a volume to expand while being in-use. Where as before you’d have to schedule downtime.
Live Volume Modification is almost a must-have feature for the web servers we run to be cost efficient and reduce any downtime. I have also noted that EBS Magnetic Volumes are now considered “previous generation” technology. (AKA: silent deprecation, just like reduced redundancy S3)
I attempted to expand a magnetic volume on a m3.large instance but found that the modify link was disabled. After a forum post, and the helpful reply from AWS, I found that previous generation magnetic volumes can not be modified while live.
This feature is too important and we will be moving to a SSD volume type instead to enable this feature. However it remains to be seen what restrictions we may have. Documentation states: “Current generation m3.medium instances fully support volume modification. However, some m3.large, m3.xlarge, and m3.2xlarge instances may not support all volume modification features.”
See more information at “Considerations for Modifying EBS Volumes”
Forum reference: https://forums.aws.amazon.com/message.jspa?messageID=771210
It has always been one of my pet-peeves that I had to attach an IAM role to an EC2 instance just in case I’d need it in the future. The reason was you couldn’t attach one later.
Attaching a role allows API access to AWS from your instance w/o having to inject API keys, which reduces security and maintainability (you’d have to remember to change out the keys when rotating keys).
AWS has now announced that you can attach an IAM role to an exiting EC2 instance.
- Create an IAM role
- Attach the IAM role to an existing EC2 instance that was originally launched without an IAM role.
- Replace the attached IAM role.
Stop using Reduced Redundancy S3 storage (RRS) on AWS now. Starting price for RRS is now $0.024 where as standard S3 starts at $0.023.
This caught me off guard today as I use RRS for backups due to what used to be an approximate 33% savings over standard S3.
For me using Glacier for backups is out of the question due to the waiting period necessary to get files.
There is also the newer “Standard – Infrequent Access” storage type for S3. This is a good option for storing perhaps a system image when doing backups, however for what I normally backup, which are small website files, this likely won’t be a good fit either. Each file has a minimum storage bill of 128KB. The math and gamble required likely won’t be worth the effort.
So for now I’ll likely be switching to all standard S3 storage for backups. I don’t use S3 for much else other than EC2 snapshots and temporary file storage for migrations.