Getting Windows 10 on EC2 isn’t difficult, but perusing the documentation can lead to confusion. You can’t mount an ISO to an empty VM the way you might do in VirtualBox, so this process requires a local copy of the VM to be created, then using the aws ec2 import-image command to create the AMI. When done, not only will the image be ready for EC2, but it will be detected as Windows by AWS and be configured such that it has many of the same AWS-specific features as other Windows AMIs provided by Amazon.
Containers are a great unit of deployment. They’re a great way to isolate code, reduce attack areas, and, well, contain a service. When it comes to deployment in production, operational attributes of containers must be considered. Container technology can enable significant density (described in terms of containers per vm) while retaining isolation between services. However, is this something we want to take advantage of operationally? Two significant issues with pushing for >1 container per vm come to mind.
Since I’m working for AWS, I want to understand fundamentally the workings of the open source Xen Hypervisor. I also want to dig more deeply into the emerging Unikernel ecosystem. Of course, I want to do this on Amazon EC2, because generally I prefer to assume my laptop is ephemeral and could be lost, stolen, dropped, etc. However, Xen doesn’t nest well, so putting Xen in a virtual machine on top of Xen is a little bit crazy-talk.
index.html is an interesting beast in S3. S3 is an object store. It is often mistaken for a filesystem, but it is not. It is also not a web server, though it can pretend to be. CloudFront is a CDN, and as such, it is also not a web server, though it does serve web content to users. All this makes for a strange situation for our friend, index.html. index.html is generally used as a default document in web servers.
The process I’ve put together for publishing this blog allows for automatic publish to the web as soon as I git commit/git push. This post describes how this is done. As background, this blog is hosted on Amazon Web Services’ S3 service with CDN capabilities and SSL termination provided by CloudFront and Amazon Certificate Manager. This last service is extremely new, to the point that I obtained and assigned the certificate to CloudFront the very day CloudFront integration was available.
I’ve decided to add Disqus comments to the site. Having a blog without comments is just…not a blog. That said, I’m not particularly happy with the amount of overhead it adds to the page. My base configuration (no images, no comments) involves a total of two requests to the site for full rendering (three if you count favicon business, which I don’t). The blog is delivered via AWS S3 and CloudFront, which gives me CDN capabilities.
I’ve been meaning to document my home backup strategy for quite some time. In the process of evolving the design, I’ve tried to address the following concerns: Rapid restoration of data in the event of an outage (RTO) Minimal data loss from an incident (RPO) Recovery from accidental deletes Recovery from malicious deletes, such as ransomware Recovery from cosmic ray damage on hard drive platters Recovery from total destruction of the house Recovery from a failed hard drive Nice, but not too expensive.
I am transitioning to a new blog host and new, well, everything regarding my blog. I had the following goals when creating this new blog site: Remove dependence on blogger.com Change the url. It’s now more common to not have “blog” in the url Reduce the page size/number of requests Improve the speed of the site (see above, plus CDN) SSL everywhere This is still a work in progress and the styling will be updated moving forward, but I’m a fan of dark themes, so this is roughly where I’m going.