<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://aws.amazon.com/message/101925/"/>
	<rdf:li rdf:resource="https://cur.vantage.sh/"/>
	<rdf:li rdf:resource="https://aws-new-features.s3.amazonaws.com/html/aws_services.html"/>
	<rdf:li rdf:resource="https://awsmaniac.com/aws-outages/"/>
	<rdf:li rdf:resource="https://jack-vanlightly.com/blog/2023/5/15/kafka-vs-redpanda-performance-do-the-claims-add-up"/>
	<rdf:li rdf:resource="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html"/>
	<rdf:li rdf:resource="https://docs.google.com/spreadsheets/d/1DqYgQnEDLQVQm5acMAhLgHLD8xXCG9BIrk-_Nv6jF3k/edit#gid=504755275"/>
	<rdf:li rdf:resource="https://github.com/aws/aws-sdk-ruby/issues/2177#issuecomment-562772431"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/new-customer-carbon-footprint-tool/"/>
	<rdf:li rdf:resource="https://netflixtechblog.medium.com/cache-warming-leveraging-ebs-for-moving-petabytes-of-data-adcf7a4a78c3"/>
	<rdf:li rdf:resource="https://www.bbva.com/en/economics-of-serverless/"/>
	<rdf:li rdf:resource="https://www.reddit.com/r/aws/comments/o7oxnl/strange_performance_decline_aws_clocksource_change/"/>
	<rdf:li rdf:resource="https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/?ck_subscriber_id=512829374"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/compute/using-shared-memory-for-low-latency-intra-node-communication-in-aws-batch/"/>
	<rdf:li rdf:resource="https://medium.com/teads-engineering/estimating-aws-ec2-instances-power-consumption-c9745e347959"/>
	<rdf:li rdf:resource="https://prestosql.io/blog/2020/06/25/data-integrity-protection.html"/>
	<rdf:li rdf:resource="https://spotcost.net/"/>
	<rdf:li rdf:resource="https://twitter.com/avibryant/status/1247754254212665344"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/"/>
	<rdf:li rdf:resource="https://srvaroa.github.io/kubernetes/migration/latency/dns/java/aws/microservices/2019/10/22/kubernetes-added-a-0-to-my-latency.html"/>
	<rdf:li rdf:resource="https://medium.com/@ranshn/the-definitive-guide-to-running-ec2-spot-instances-as-kubernetes-worker-nodes-68ef2095e767"/>
	<rdf:li rdf:resource="https://stressgrid.com/blog/pps_limits_in_ec2/"/>
	<rdf:li rdf:resource="https://medium.com/@tinder.engineering/tinders-move-to-kubernetes-cda2a6372f44"/>
	<rdf:li rdf:resource="https://www.reddit.com/r/aws/comments/b9f8fn/s3_benchmark/"/>
	<rdf:li rdf:resource="https://github.com/databricks/devbox"/>
	<rdf:li rdf:resource="https://instaguide.io/"/>
	<rdf:li rdf:resource="https://www.qubole.com/blog/presto-performance-for-ad-hoc-workloads-on-aws-instance-types/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/whats-new/2018/11/introducing-predictive-scaling-for-amazon-EC2-in-aws-auto-scaling/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/compute/running-high-scale-web-on-spot-instances/"/>
	<rdf:li rdf:resource="https://www.slideshare.net/AmazonWebServices/deep-dive-maximizing-ec2-and-ebs-performance"/>
	<rdf:li rdf:resource="https://forums.aws.amazon.com/thread.jspa?messageID=831922&amp;tstart=0"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/ec2-instance-update-c5-instances-with-local-nvme-storage-c5d/"/>
	<rdf:li rdf:resource="https://www.slideshare.net/AmazonWebServices/stg306deep-dive-on-amazon-ebs"/>
	<rdf:li rdf:resource="https://www.slideshare.net/AmazonWebServices/dat302deep-dive-on-amazon-relational-database-service-rds"/>
	<rdf:li rdf:resource="https://www.slideshare.net/AmazonWebServices/cmp301deep-dive-on-amazon-ec2-instances"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/whats-new/2017/11/spot-fleet-now-supports-target-tracking-and-new-plug-in-for-atlassian-bamboo/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/new-network-load-balancer-effortless-scaling-to-millions-of-requests-per-second/"/>
	<rdf:li rdf:resource="https://github.com/cristim/autospotting?__s=gf36pf8g1gjugcqh6ppo"/>
	<rdf:li rdf:resource="https://github.com/jorgebastida/awslogs"/>
	<rdf:li rdf:resource="https://jeremyeder.com/2017/07/25/docker-operations-slowing-down-on-aws-this-time-its-not-dns/"/>
	<rdf:li rdf:resource="https://github.com/awslabs/aws-ec2rescue-linux"/>
	<rdf:li rdf:resource="https://www.datadoghq.com/blog/top-5-ways-to-improve-your-aws-ec2-performance/"/>
	<rdf:li rdf:resource="https://segment.com/blog/spotting-a-million-dollars-in-your-aws-account/"/>
	<rdf:li rdf:resource="https://github.com/cristim/autospotting"/>
	<rdf:li rdf:resource="https://insights.ubuntu.com/2017/04/05/ubuntu-on-aws-gets-serious-performance-boost-with-aws-tuned-kernel/?__s=gf36pf8g1gjugcqh6ppo"/>
	<rdf:li rdf:resource="https://wiki.jenkins-ci.org/display/JENKINS/Amazon+EC2+Container+Service+Plugin"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/developer-preview-ec2-instances-f1-with-programmable-hardware/"/>
	<rdf:li rdf:resource="http://jvns.ca/blog/2016/11/16/ideas-about-how-to-use-aws/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/new-auto-scaling-for-ec2-spot-fleets/?sc_channel=sm&amp;sc_campaign=launch_EC2_522bf4f3&amp;sc_publisher=tw_go&amp;sc_content=AnyScale_support_spot_fleets&amp;sc_country=global&amp;sc_geo=globaly"/>
	<rdf:li rdf:resource="http://www.ybrikman.com/writing/2015/11/11/running-docker-aws-ground-up/"/>
	<rdf:li rdf:resource="http://www.slideshare.net/pwakeford/aws-sydney-meetup-april-2016-paul-wakeford"/>
	<rdf:li rdf:resource="https://cloudnative.io/yeobot/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/compute/powering-your-amazon-ecs-clusters-with-spot-fleet/"/>
	<rdf:li rdf:resource="http://perspectives.mvdirona.com/2015/12/vpc-nat-gateways-transactional-uniqueness-at-scale/"/>
	<rdf:li rdf:resource="https://www.reddit.com/r/aws/comments/3xuf93/2016_wish_list_for_aws/"/>
	<rdf:li rdf:resource="https://railsadventures.wordpress.com/2015/12/06/why-we-chose-kubernetes-over-ecs/"/>
	<rdf:li rdf:resource="http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_CLI_tutorial.html#ECS_CLI_tutorial_compose_service"/>
	<rdf:li rdf:resource="https://github.com/AdRoll/hologram"/>
	<rdf:li rdf:resource="http://ispyker.blogspot.ie/2015/10/aws-reinvent-2015-video-slide.html"/>
	<rdf:li rdf:resource="https://segment.com/blog/rebuilding-our-infrastructure/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/new-ec2-spot-blocks-for-defined-duration-workloads/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/message/5467D2/"/>
	<rdf:li rdf:resource="http://blog.cloudsploit.com/2015/09/15/how-we-use-lambda/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/ec2/spot/bid-advisor/"/>
	<rdf:li rdf:resource="http://ben.straub.cc/2015/08/19/kubernetes-aws-vpc-peering/"/>
	<rdf:li rdf:resource="http://blog.takipi.com/amazon-ec2-2015-benchmark-testing-speeds-between-aws-ec2-and-s3-regions/"/>
	<rdf:li rdf:resource="http://lg.io/2015/07/05/revised-and-much-faster-run-your-own-highend-cloud-gaming-service-on-ec2.html"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/vpc-flow-logs-log-and-view-network-traffic-flows/"/>
	<rdf:li rdf:resource="http://highscalability.com/blog/2015/6/8/leveraging-aws-to-build-a-scalable-data-pipeline.html"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://aws.amazon.com/message/101925/">
    <title>Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region</title>
    <dc:date>2025-10-23T15:08:30+00:00</dc:date>
    <link>https://aws.amazon.com/message/101925/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Postmortem writeup of this week's massive AWS us-east-1 outage. tl;dr:

1. DynamoDB runs into a consistency failure in an internal DNS optimization service;
2. EC2 provisioning depends on DynamoDB and craps out;
3. Network load balancers screw up due to impact of EC2 outage.
]]></description>
<dc:subject>dynamodb dns aws ec2 nlb outages post-mortems cloud-computing amazon us-east-1</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4a70bf22a463/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nlb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:post-mortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud-computing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:us-east-1"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cur.vantage.sh/">
    <title>cur.vantage.sh</title>
    <dc:date>2025-02-05T10:01:43+00:00</dc:date>
    <link>https://cur.vantage.sh/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[via Ben Schaechter: "a new microsite we’ve launched for the AWS community that helps with understanding billing codes present in either Cost Explorer or the CUR. We profiled the number of distinct billing codes across our customer base and have about ~60k unique billing codes. We hear all the time that FinOps practitioners and engineers are confused about the billing codes present in Cost Explorer or the Cost and Usage Report. Think of these as being things like “Requests-Tier1” for S3 or “CW:GMWI-Metrics” for CloudWatch. There is usually really limited resources for determining what these billing codes are even when you Google around for them."]]></description>
<dc:subject>aws billing codes cost-explorer ec2 s3 finops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:55952b17d38d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:billing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:codes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cost-explorer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:finops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws-new-features.s3.amazonaws.com/html/aws_services.html">
    <title>AWS region/service availability matrix</title>
    <dc:date>2024-07-25T09:57:54+00:00</dc:date>
    <link>https://aws-new-features.s3.amazonaws.com/html/aws_services.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An exhaustive list of AWS services, VPC endpoints, EC2 instance types, service quotas, etc etc etc., broken down by their availability in each AWS region.  Blog post: https://aws.amazon.com/blogs/aws/subscribe-to-aws-daily-feature-updates-via-amazon-sns/

(Via Last Week In AWS Slack)]]></description>
<dc:subject>via:lwia aws features releases regions ops ec2 vpc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9504799b9f96/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:lwia"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:features"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:releases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:regions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://awsmaniac.com/aws-outages/">
    <title>AWS Maniac's History of AWS Outages</title>
    <dc:date>2024-05-31T10:33:27+00:00</dc:date>
    <link>https://awsmaniac.com/aws-outages/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A decent list, from S3's infamous single-bit-corruption incident in 2008, to a networking control plane outage in December 2021 (via the Last Week in AWS slack).

See also https://aws.amazon.com/premiumsupport/technology/pes/ for the "official" list (which omits single-AZ incidents as a matter of policy).]]></description>
<dc:subject>aws cloud outages downtime s3 ec2 dynamodb incidents post-mortems</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1b6a3252e8c2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:downtime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:incidents"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:post-mortems"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://jack-vanlightly.com/blog/2023/5/15/kafka-vs-redpanda-performance-do-the-claims-add-up">
    <title>Kafka vs Redpanda Performance</title>
    <dc:date>2023-05-15T16:19:55+00:00</dc:date>
    <link>https://jack-vanlightly.com/blog/2023/5/15/kafka-vs-redpanda-performance-do-the-claims-add-up</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I don't use either service, but this is actually an excellent writeup of some high-end performance optimization on modern Linux EC2-based systems with NVMe SSDs, and the benchmarking of same]]></description>
<dc:subject>kafka redpanda benchmarks ec2 aws ssd optimization performance ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c155a58ab563/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redpanda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html">
    <title>EC2 instance network error metrics</title>
    <dc:date>2023-01-24T11:03:07+00:00</dc:date>
    <link>https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[looks like Amazon are now exposing a bunch of error metrics for their EC2 instance network drivers in Linux]]></description>
<dc:subject>metrics ec2 ops drivers networking bandwidth errors</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3176cdd6fec2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:drivers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bandwidth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:errors"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://docs.google.com/spreadsheets/d/1DqYgQnEDLQVQm5acMAhLgHLD8xXCG9BIrk-_Nv6jF3k/edit#gid=504755275">
    <title>AWS EC2 Carbon Footprint Dataset - Google Sheets</title>
    <dc:date>2022-08-29T09:13:46+00:00</dc:date>
    <link>https://docs.google.com/spreadsheets/d/1DqYgQnEDLQVQm5acMAhLgHLD8xXCG9BIrk-_Nv6jF3k/edit#gid=504755275</link>
    <dc:creator>jm</dc:creator><description><![CDATA['"This spreadsheet provides a way for AWS cloud users to estimate the carbon footprint of their EC2 based workloads. Two estimations are available:
- Carbon emissions related to running the instance, including the datacenter PUE
- Carbon emissions related to manufacturing the underlying hardware.'

Courtesy of French online ad company Teads]]></description>
<dc:subject>aws carbon emissions ec2 hosting</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1c85b1d03555/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:carbon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emissions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hosting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/aws/aws-sdk-ruby/issues/2177#issuecomment-562772431">
    <title>aws-sdk-core &gt; 3.78.0 slows down the fetching of credentials · Issue #2177 · aws/aws-sdk-ruby</title>
    <dc:date>2022-04-05T08:37:58+00:00</dc:date>
    <link>https://github.com/aws/aws-sdk-ruby/issues/2177#issuecomment-562772431</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Poorly-coordinated EC2 security decision which has broken many things which run containers on EC2 instances]]></description>
<dc:subject>aws aws-sdk containers docker eks ec2 bugs fail imdsv2</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fea302b0ba13/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws-sdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:imdsv2"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/new-customer-carbon-footprint-tool/">
    <title>New – Customer Carbon Footprint Tool | AWS News Blog</title>
    <dc:date>2022-03-02T14:39:20+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/new-customer-carbon-footprint-tool/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Starting today customers can calculate the environmental impact of their AWS workloads with the new customer carbon footprint tool. This new tool uses easy-to-understand data visualizations to provide customers with their historical carbon emissions, evaluate emission trends as their use of AWS evolves, approximate the estimated carbon emissions they have avoided by using AWS instead of an on-premises data center, and review forecasted emissions based on current use. The forecasted emissions are based on current usage, and show how a customer’s carbon footprint will change as Amazon stays on path to powering its operations with 100% renewable energy by 2025, five years ahead of its original target of 2030, and drives toward net-zero carbon by 2040 as part of The Climate Pledge.  

The customer carbon footprint tool is visible today through the AWS Billing console and helps to support customers on their sustainability journey. When signed into the AWS Billing console, customers can view their carbon emissions data by geographical location and by AWS services, such as Amazon Elastic Compute Cloud (EC2) and Amazon Simple Storage Service (S3). They can also measure changes in their carbon footprint over time, as they deploy new resources in the cloud. The new tool uses data that meets the Greenhouse Gas Protocol, which is the international standard for greenhouse gas reporting.'

Covers Scope 1 and Scope 2 emissions.]]></description>
<dc:subject>aws carbon emissions climate-change sustainability climate infrastructure ops ec2 s3</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6fb815c75d98/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:carbon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emissions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:climate-change"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sustainability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:climate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infrastructure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://netflixtechblog.medium.com/cache-warming-leveraging-ebs-for-moving-petabytes-of-data-adcf7a4a78c3">
    <title>Cache warming: Leveraging EBS for moving petabytes of data</title>
    <dc:date>2021-12-01T10:09:14+00:00</dc:date>
    <link>https://netflixtechblog.medium.com/cache-warming-leveraging-ebs-for-moving-petabytes-of-data-adcf7a4a78c3</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting idea for EC2-based high-volume workload rebalancing, exploiting a feature of EC2 networking -- EBS gets a dedicated additional network bandwidth allocation]]></description>
<dc:subject>architecture ebs memcache caching networking ec2 netflix</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1e40b505a3ec/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memcache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.bbva.com/en/economics-of-serverless/">
    <title>Lambda vs EC2 costs</title>
    <dc:date>2021-08-10T09:10:29+00:00</dc:date>
    <link>https://www.bbva.com/en/economics-of-serverless/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[BBVA run the numbers on AWS Lambda vs bare-EC2 cost effectiveness.  This is a good analysis, as of Dec 2020 pricing at least:

<blockquote>
With traffic profiles where requests arrive in at periodic intervals, and a low total amount of requests, serverless architecture seems to be a great architecture in terms of cost, speed of delivery and effort. Thus, Lambda is probably the way to go if our application has sufficiently large periods of inactivity.

Once the break-even point is reached, when EC2 is more cost-effective than Lambda, the cost difference grows rapidly, making Lambda less and less attractive in terms of cost. Thus, it is of great importance to know if the expected amount of traffic will be around the break-even point.

Be aware of the CPU throttling you will get with the smaller memory flavors of Lambda. If your code is CPU-bound, choosing the smaller memory flavors might not be an option, since execution times, and thus latency, might grow beyond your requirements. On the other hand, if your code is I/O bound, the CPU throttling might not affect you significantly.

Break-even point (if there is one, that is) strongly depends on the application itself. Without measuring the target application code, knowing the intended usage of the service, the SLA and the capabilities of the team in charge of building the application it is almost impossible to know for sure which service, Lambda or EC2, is more convenient.</blockquote>

IMO there are still significant costs in organisational and infrastructure terms around replacing a working EC2 infrastructure with a Lambda-based one; deployment and other integration points with AWS are extremely tricky to deal with. But this is good data on the $ point alone.
]]></description>
<dc:subject>serverless aws lambda costs cost-control ec2 hosting architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2ff2f72827fa/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:serverless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lambda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:costs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cost-control"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hosting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.reddit.com/r/aws/comments/o7oxnl/strange_performance_decline_aws_clocksource_change/">
    <title>Interesting AWS performance tip</title>
    <dc:date>2021-06-27T20:41:55+00:00</dc:date>
    <link>https://www.reddit.com/r/aws/comments/o7oxnl/strange_performance_decline_aws_clocksource_change/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>we determined that calls to time.Now() or time.Since(time.Time) in Golang were taking about 200 times longer on new servers than they were on old servers. We found similar impacts in Python, which lead us to the clocksource.

It turns out that in our Grub boot parameters for AL2, we had added clocksource=hpet about two years ago, but all of our servers launched prior to 6/17 had a clocksource of kvm-clock, apparently ignoring the Grub config. Servers launched after 6/17 (with the same AMI, Grub config, everything) were honoring the specified clocksource, which caused our performance issue.</blockquote>

]]></description>
<dc:subject>ec2 aws clocksource linux kvm</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:68b3230eeae8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clocksource"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kvm"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/?ck_subscriber_id=512829374">
    <title>The 17 Ways to Run Containers on AWS - Last Week in AWS</title>
    <dc:date>2021-05-31T14:36:45+00:00</dc:date>
    <link>https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/?ck_subscriber_id=512829374</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is both (a) correct and (b) a nightmare. AWS need a coherent product plan where containers are involved...]]></description>
<dc:subject>containers aws ec2 eks k8s docker architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0efe3719a580/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/compute/using-shared-memory-for-low-latency-intra-node-communication-in-aws-batch/">
    <title>Using shared memory for low-latency, intra-node communication in AWS Batch | AWS Compute Blog</title>
    <dc:date>2021-05-21T08:46:49+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/compute/using-shared-memory-for-low-latency-intra-node-communication-in-aws-batch/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Crazy HPC-oriented feature in current AWS offerings: shared memory buffers over EFA:

<blockquote>HPC workloads use algorithms that require parallelization and a low latency communication between the different processes. The two main technologies used for the parallel communications are message-passing with distributed memory and shared memory.

Message Passing Interface (MPI) is a message-passing standard used for the communication in a parallel distributed environment. Elastic Fabric Adapter (EFA) enables your MPI applications to use low-latency, inter-node communication.

The shared memory paradigm allows multiple processors in the same system to communicate using a memory (RAM) portion that is shared between the processes. This method takes advantage of the high-speed memory bus.</blockquote>

]]></description>
<dc:subject>shared-memory hpc mpi shmem ram coding efa aws ec2 low-latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6dd0427bd3ed/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shared-memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mpi"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shmem"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ram"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:efa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:low-latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/teads-engineering/estimating-aws-ec2-instances-power-consumption-c9745e347959">
    <title>Estimating AWS EC2 Instances Power Consumption</title>
    <dc:date>2021-04-27T11:59:58+00:00</dc:date>
    <link>https://medium.com/teads-engineering/estimating-aws-ec2-instances-power-consumption-c9745e347959</link>
    <dc:creator>jm</dc:creator><description><![CDATA[attempting to estimate the carbon footprint of cloud computing at AWS, by estimating the power consumption of individual EC2 instances running a workload.]]></description>
<dc:subject>aws ec2 cloud-computing energy carbon footprint power estimation ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5d2afd8b0f5a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud-computing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:energy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:carbon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:footprint"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:power"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:estimation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://prestosql.io/blog/2020/06/25/data-integrity-protection.html">
    <title>Data Integrity Protection in Presto</title>
    <dc:date>2020-06-26T10:35:28+00:00</dc:date>
    <link>https://prestosql.io/blog/2020/06/25/data-integrity-protection.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Presto testers run into an interesting network-level data corruption bug in both AWS and Azure.  checksum your traffic!]]></description>
<dc:subject>presto data-corruption bugs aws azure ec2 checksums reliability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c751bb2609c8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-corruption"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:azure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:checksums"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://spotcost.net/">
    <title>Spot Cost</title>
    <dc:date>2020-06-08T20:04:55+00:00</dc:date>
    <link>https://spotcost.net/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['EC2 Spot Instances comparison. Find the cheapest Region, availability zone, interruption rate or compare the specs']]></description>
<dc:subject>spot-instances ec2 aws spots ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:42d9ebcd05f6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spots"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/avibryant/status/1247754254212665344">
    <title>Amazon may be running Folding@Home on their unused EC2 spot instances</title>
    <dc:date>2020-04-08T09:07:50+00:00</dc:date>
    <link>https://twitter.com/avibryant/status/1247754254212665344</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A mysterious team called "AWSFolds" is using a massive amount of AWS spot capacity]]></description>
<dc:subject>aws amazon ec2 spot-instances foldingathome covid-19</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e4917664327c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:foldingathome"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:covid-19"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/">
    <title>Amazon EBS Multi-Attach now available on Provisioned IOPS io1 volumes</title>
    <dc:date>2020-02-17T10:49:05+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Attach multiple EC2 instances to the same EBS volume.  Now that is pretty cool]]></description>
<dc:subject>ebs ec2 filesystems networking ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2f99d09d89c4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://srvaroa.github.io/kubernetes/migration/latency/dns/java/aws/microservices/2019/10/22/kubernetes-added-a-0-to-my-latency.html">
    <title>KIAM defaults result in massive latencies on AWS API calls</title>
    <dc:date>2019-11-11T10:30:38+00:00</dc:date>
    <link>https://srvaroa.github.io/kubernetes/migration/latency/dns/java/aws/microservices/2019/10/22/kubernetes-added-a-0-to-my-latency.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>KIAM [a Kubernetes IAM API helper] happens to provide short-lived credentials to Pods, which makes sense as it’s fair to assume that the average lifetime of a Pod is shorter than EC2 instances. The default is precisely 15 min.

But if you put both defaults together, you have a problem. Each certificate provided to the application has a 15 min expiration time. The AWS Java SDK will force refreshing any certificate with less than 15 min expiration time left.

The result is that every request will be forced to refresh the temporary certificate, which requires two calls to the AWS API that add a huge latency penalty to each request. We later found a feature request in the AWS Java SDK that mentions this same issue.

The fix was easy. We reconfigured KIAM to request credentials with a longer expiration period. Once this change was applied, requests started being served without involving the AWS Metadata service and returned to an even lower latency than in EC2.</blockquote>

]]></description>
<dc:subject>kubernetes kiam defaults aws latency performance ec2</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e6d5522f5c36/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kiam"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:defaults"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/@ranshn/the-definitive-guide-to-running-ec2-spot-instances-as-kubernetes-worker-nodes-68ef2095e767">
    <title>The definitive guide to running EC2 Spot Instances as Kubernetes worker nodes</title>
    <dc:date>2019-05-22T10:46:45+00:00</dc:date>
    <link>https://medium.com/@ranshn/the-definitive-guide-to-running-ec2-spot-instances-as-kubernetes-worker-nodes-68ef2095e767</link>
    <dc:creator>jm</dc:creator><description><![CDATA[it really is quite definitive, good writeup]]></description>
<dc:subject>ec2 spot-instances cost-saving kubernetes clusters asg aws</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6f043fb3a3f0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cost-saving"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clusters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://stressgrid.com/blog/pps_limits_in_ec2/">
    <title>Packets-per-second limits in EC2</title>
    <dc:date>2019-04-26T10:26:17+00:00</dc:date>
    <link>https://stressgrid.com/blog/pps_limits_in_ec2/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>By running these experiments, we determined that each EC2 instance type has a packet-per-second budget. Surprisingly, this budget goes toward the total of incoming and outgoing packets. Even more surprisingly, the same budget gets split between multiple network interfaces, with some additional performance penalty. This last result informs against using multiple network interfaces when tuning the system for higher networking performance.

The maximum budget for m5.metal and m5.24xlarge is 2.2M packets per second. Given that each HTTP transaction takes at least four packets, we can translate this to a maximum of 550k requests per second on the largest m5 instance with Enhanced Networking enabled.</blockquote>

]]></description>
<dc:subject>aws ec2 networking pps packets tcp ip benchmarking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:94369fd8e8b0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/@tinder.engineering/tinders-move-to-kubernetes-cda2a6372f44">
    <title>Tinder’s move to Kubernetes – Tinder Engineering – Medium</title>
    <dc:date>2019-04-18T12:56:05+00:00</dc:date>
    <link>https://medium.com/@tinder.engineering/tinders-move-to-kubernetes-cda2a6372f44</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A solid technical writeup of Tinder's k8s migration.  Some problems with Flannel, DNS and (worryingly) ELB, but good +1s for Envoy as a sidecar]]></description>
<dc:subject>kubernetes k8s flannel networking elb aws envoy ec2 ops tinder</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:68e5fb0e2425/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:k8s"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:flannel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:envoy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tinder"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.reddit.com/r/aws/comments/b9f8fn/s3_benchmark/">
    <title>S3 Throughput Benchmarks</title>
    <dc:date>2019-04-08T09:19:48+00:00</dc:date>
    <link>https://www.reddit.com/r/aws/comments/b9f8fn/s3_benchmark/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is really useful data.  As expected the c5ns win, but good to validate that! 

<blockquote>I used this to benchmark S3's performance from all 155 EC2 instance types in existence. I put all the data in an interactive spreadsheet. [...] Below is the max throughput I got from each instance type, but the spreadsheet shows you what object sizes and thread counts you need to get that performance.</blockquote>

]]></description>
<dc:subject>ec2 instances instance-types hardware cloud s3 performance benchmarks ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c487e84fb24d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instance-types"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/databricks/devbox">
    <title>databricks/devbox</title>
    <dc:date>2019-02-28T17:51:40+00:00</dc:date>
    <link>https://github.com/databricks/devbox</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting, a synchronization daemon from Databricks which they use to synch up dev repos with a remote "devbox" in EC2 for heavyweight compilation]]></description>
<dc:subject>remote-compiles compiling devbox databricks coding tools dev ec2</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c2aad21df18a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:remote-compiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devbox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databricks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dev"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://instaguide.io/">
    <title>Instance Price Guide</title>
    <dc:date>2019-01-18T10:10:33+00:00</dc:date>
    <link>https://instaguide.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nicely done EC2 instance price comparison site, with spot instance and reserved pricing discounts taken into account; possibly better than ec2instances.info]]></description>
<dc:subject>ec2 instances aws pricing hosts spot-instances money</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b0929e6d1b0a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pricing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hosts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:money"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.qubole.com/blog/presto-performance-for-ad-hoc-workloads-on-aws-instance-types/">
    <title>Presto Performance for Ad Hoc Workloads on AWS Instance Types</title>
    <dc:date>2018-11-29T10:44:26+00:00</dc:date>
    <link>https://www.qubole.com/blog/presto-performance-for-ad-hoc-workloads-on-aws-instance-types/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good benchmark/review of instance types from Qubole]]></description>
<dc:subject>qubole presto performance benchmarks ops aws instances ec2</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:476670e29703/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:qubole"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/whats-new/2018/11/introducing-predictive-scaling-for-amazon-EC2-in-aws-auto-scaling/">
    <title>Introducing Predictive Scaling for Amazon EC2 in AWS Auto Scaling</title>
    <dc:date>2018-11-21T10:48:42+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/whats-new/2018/11/introducing-predictive-scaling-for-amazon-EC2-in-aws-auto-scaling/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Predictive Scaling predicts future traffic based on daily and weekly trends, including regularly-occurring spikes, and provisions the right number of EC2 instances in advance of anticipated changes. Provisioning the capacity just in time for an impending load change makes Auto Scaling faster than ever before. Predictive Scaling’s machine learning algorithms detect changes in daily and weekly patterns, automatically adjusting their forecasts. This removes the need for manual adjustment of Auto Scaling parameters over time, making Auto Scaling simpler to configure and consume. Auto Scaling enhanced with Predictive Scaling delivers faster, simpler, and more accurate capacity provisioning to our customers.</blockquote>

Fantastic!  More heavy lifting taken care of.]]></description>
<dc:subject>aws amazon scaling autoscaling predictive-scaling ml ec2 asg</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e3499386f7d2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:autoscaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:predictive-scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ml"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asg"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/">
    <title>New – EC2 Auto Scaling Groups With Multiple Instance Types &amp; Purchase Options | AWS News Blog</title>
    <dc:date>2018-11-15T11:00:49+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Basically getting EC2 Fleet's featureset into ASGs, good news]]></description>
<dc:subject>ec2 fleet asg ops architecture cost-control</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bbd4ce40f4c6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fleet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cost-control"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/compute/running-high-scale-web-on-spot-instances/">
    <title>Running high-scale web applications on Amazon EC2 Spot Instances</title>
    <dc:date>2018-10-03T16:09:14+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/compute/running-high-scale-web-on-spot-instances/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[AppNext's setup looks like quite good practice for a CPU-bound fleet]]></description>
<dc:subject>appnext spot-instances ec2 scalability aws ops architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e099fd008834/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:appnext"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.slideshare.net/AmazonWebServices/deep-dive-maximizing-ec2-and-ebs-performance">
    <title>Deep Dive: Maximizing EC2 and EBS Performance</title>
    <dc:date>2018-09-17T11:11:36+00:00</dc:date>
    <link>https://www.slideshare.net/AmazonWebServices/deep-dive-maximizing-ec2-and-ebs-performance</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some decent EBS tips from 2015]]></description>
<dc:subject>ebs ec2 aws ops storage tips</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8dc4551f948d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://forums.aws.amazon.com/thread.jspa?messageID=831922&amp;tstart=0">
    <title>AWS Developer Forums: m5.xlarge in us-east-1 has intermittent DNS resolution failures</title>
    <dc:date>2018-06-26T16:29:41+00:00</dc:date>
    <link>https://forums.aws.amazon.com/thread.jspa?messageID=831922&amp;tstart=0</link>
    <dc:creator>jm</dc:creator><description><![CDATA[likewise for C5 instance types -- reportedly still an issue]]></description>
<dc:subject>c5 m5 instances ec2 aws amazon ops dns</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4b578d96708c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c5"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:m5"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dns"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/ec2-instance-update-c5-instances-with-local-nvme-storage-c5d/">
    <title>EC2 Instance Update – C5 Instances with Local NVMe Storage (C5d)</title>
    <dc:date>2018-05-18T10:11:29+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/ec2-instance-update-c5-instances-with-local-nvme-storage-c5d/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>With a 25% to 50% improvement in price-performance over the C4 instances, the C5 instances are designed for applications like batch and log processing, distributed and or real-time analytics, high-performance computing (HPC), ad serving, highly scalable multiplayer gaming, and video encoding. Some of these applications can benefit from access to high-speed, ultra-low latency local storage. For example, video encoding, image manipulation, and other forms of media processing often necessitates large amounts of I/O to temporary storage. While the input and output files are valuable assets and are typically stored as Amazon Simple Storage Service (S3) objects, the intermediate files are expendable. Similarly, batch and log processing runs in a race-to-idle model, flushing volatile data to disk as fast as possible in order to make full use of compute resources.</blockquote>

Very nice!]]></description>
<dc:subject>ec2 instance-types ops storage hardware aws</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0521fbd281bc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instance-types"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.slideshare.net/AmazonWebServices/stg306deep-dive-on-amazon-ebs">
    <title>AWS re:Invent 2017 slides: STG306 - Deep Dive on Amazon EBS</title>
    <dc:date>2017-12-14T10:23:04+00:00</dc:date>
    <link>https://www.slideshare.net/AmazonWebServices/stg306deep-dive-on-amazon-ebs</link>
    <dc:creator>jm</dc:creator><description><![CDATA[useful session from re:Invent this year]]></description>
<dc:subject>ec2 ebs aws amazon ops tips slides reinvent</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:043c7cccb5c5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reinvent"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.slideshare.net/AmazonWebServices/dat302deep-dive-on-amazon-relational-database-service-rds">
    <title>AWS re:Invent 2017 slides: DAT302 - Deep Dive on Amazon Relational Database Service (RDS)</title>
    <dc:date>2017-12-14T10:22:46+00:00</dc:date>
    <link>https://www.slideshare.net/AmazonWebServices/dat302deep-dive-on-amazon-relational-database-service-rds</link>
    <dc:creator>jm</dc:creator><description><![CDATA[useful session from re:Invent this year]]></description>
<dc:subject>ec2 ebs aws amazon ops tips slides reinvent</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6bbf7316c9fb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reinvent"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.slideshare.net/AmazonWebServices/cmp301deep-dive-on-amazon-ec2-instances">
    <title>AWS re:Invent 2017 slides: CMP301 - Deep Dive on Amazon EC2 Instances</title>
    <dc:date>2017-12-14T10:22:27+00:00</dc:date>
    <link>https://www.slideshare.net/AmazonWebServices/cmp301deep-dive-on-amazon-ec2-instances</link>
    <dc:creator>jm</dc:creator><description><![CDATA[useful session from re:Invent this year]]></description>
<dc:subject>ec2 ebs aws amazon ops tips slides reinvent</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4674fd1ed517/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reinvent"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/whats-new/2017/11/spot-fleet-now-supports-target-tracking-and-new-plug-in-for-atlassian-bamboo/">
    <title>Spot Fleet now supports Target Tracking</title>
    <dc:date>2017-11-20T10:23:58+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/whats-new/2017/11/spot-fleet-now-supports-target-tracking-and-new-plug-in-for-atlassian-bamboo/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Awesome, nice feature]]></description>
<dc:subject>spot-fleet spot-instances ec2 amazon aws scaling ops architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b0bd09164e4c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-fleet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/new-network-load-balancer-effortless-scaling-to-millions-of-requests-per-second/">
    <title>New Network Load Balancer – Effortless Scaling to Millions of Requests per Second | AWS Blog</title>
    <dc:date>2017-09-08T13:32:52+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/new-network-load-balancer-effortless-scaling-to-millions-of-requests-per-second/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Looks like the EC2 Networking team got their way and got to rewrite LBs in AWS]]></description>
<dc:subject>load-balancing aws elb alb nlb networking ec2 ops architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:53d55f54edb6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-balancing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:elb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nlb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/cristim/autospotting?__s=gf36pf8g1gjugcqh6ppo">
    <title>cristim/autospotting</title>
    <dc:date>2017-08-21T14:56:08+00:00</dc:date>
    <link>https://github.com/cristim/autospotting?__s=gf36pf8g1gjugcqh6ppo</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Easy to use tool that automatically replaces some or even all on-demand AutoScaling group members with similar or larger identically configured spot instances in order to generate significant cost savings on AWS EC2, behaving much like an AutoScaling-backed spot fleet.']]></description>
<dc:subject>asg autoscaling ec2 aws spot-fleet spot-instances cost-saving scaling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:514204b9090f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:autoscaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-fleet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cost-saving"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/jorgebastida/awslogs">
    <title>GitHub - jorgebastida/awslogs: AWS CloudWatch logs for Humans™</title>
    <dc:date>2017-08-13T20:27:54+00:00</dc:date>
    <link>https://github.com/jorgebastida/awslogs</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This feature alone is a bit of a killer app:

<blockquote>$ awslogs get /var/log/syslog ip-10-1.* --start='2h ago' | grep ERROR</blockquote>

Nice.

]]></description>
<dc:subject>cli logging aws cloudwatch logs awslogs ec2</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6870758defc9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloudwatch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:awslogs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://jeremyeder.com/2017/07/25/docker-operations-slowing-down-on-aws-this-time-its-not-dns/">
    <title>EBS gp2 I/O BurstBalance exhaustion</title>
    <dc:date>2017-07-26T13:14:54+00:00</dc:date>
    <link>https://jeremyeder.com/2017/07/25/docker-operations-slowing-down-on-aws-this-time-its-not-dns/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[when EBS volumes in EC2 exhaust their "burst" allocation, things go awry very quickly]]></description>
<dc:subject>performance aws ebs ec2 burst-balance ops debugging</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bef976e76060/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:burst-balance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/awslabs/aws-ec2rescue-linux">
    <title>awslabs/aws-ec2rescue-linux</title>
    <dc:date>2017-07-21T09:54:23+00:00</dc:date>
    <link>https://github.com/awslabs/aws-ec2rescue-linux</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Amazon Web Services Elastic Compute Cloud (EC2) Rescue for Linux is a python-based tool that allows for the automatic diagnosis of common problems found on EC2 Linux instances.</blockquote>

Most of the modules appear to be log-greppers looking for common kernel issues.

]]></description>
<dc:subject>ec2 aws kernel linux ec2rl ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1e8923ebc45e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2rl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.datadoghq.com/blog/top-5-ways-to-improve-your-aws-ec2-performance/">
    <title>Top 5 ways to improve your AWS EC2 performance</title>
    <dc:date>2017-07-03T10:51:31+00:00</dc:date>
    <link>https://www.datadoghq.com/blog/top-5-ways-to-improve-your-aws-ec2-performance/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A couple of bits of excellent advice from Datadog (although this may be a slightly old post, from Oct 2016):

1. Unpredictable EBS disk I/O performance.  Note that gp2 volumes do not appear to need as much warmup or priming as before.

2. EC2 Instance ECU Mismatch and Stolen CPU.  advice: use bigger instances

The other 3 ways are a little obvious by comparison, but worth bookmarking for those two anyway.

]]></description>
<dc:subject>ops ec2 performance datadog aws ebs stolen-cpu virtualization metrics tips</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:26efe6d76709/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datadog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stolen-cpu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:virtualization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://segment.com/blog/spotting-a-million-dollars-in-your-aws-account/">
    <title>Spotting a million dollars in your AWS account · Segment Blog</title>
    <dc:date>2017-05-18T14:43:35+00:00</dc:date>
    <link>https://segment.com/blog/spotting-a-million-dollars-in-your-aws-account/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>You can easily split your spend by AWS service per month and call it a day. Ten thousand dollars of EC2, one thousand to S3, five hundred dollars to network traffic, etc. But what’s still missing is a synthesis of which products and engineering teams are dominating your costs. 

Then, add in the fact that you may have hundreds of instances and millions of containers that come and go. Soon, what started as simple analysis problem has quickly become unimaginably complex. 

In this follow-up post, we’d like to share details on the toolkit we used. Our hope is to offer up a few ideas to help you analyze your AWS spend, no matter whether you’re running only a handful of instances, or tens of thousands.

</blockquote>

]]></description>
<dc:subject>segment money costs billing aws ec2 ecs ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:37e7b0f5b58b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:segment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:money"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:costs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:billing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/cristim/autospotting">
    <title>cristim/autospotting: Pay up to 10 times less on EC2 by automatically replacing on-demand AutoScaling group members with similar or larger identically configured spot instances.</title>
    <dc:date>2017-05-02T11:01:21+00:00</dc:date>
    <link>https://github.com/cristim/autospotting</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>A simple and easy to use tool designed to significantly lower your Amazon AWS costs by automating the use of the spot market.

Once enabled on an existing on-demand AutoScaling group, it launches an EC2 spot instance that is cheaper, at least as large and configured identically to your current on-demand instances. As soon as the new instance is ready, it is added to the group and an on-demand instance is detached from the group and terminated.

It continuously applies this process, gradually replacing any on-demand instances with spot instances until the group only consists of spot instances, but it can also be configured to keep some on-demand instances running.</blockquote>

]]></description>
<dc:subject>aws golang ec2 autoscaling asg spot-instances ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e7451129fd50/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:golang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:autoscaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://insights.ubuntu.com/2017/04/05/ubuntu-on-aws-gets-serious-performance-boost-with-aws-tuned-kernel/?__s=gf36pf8g1gjugcqh6ppo">
    <title>Ubuntu on AWS gets serious performance boost with AWS-tuned kernel</title>
    <dc:date>2017-04-11T10:54:52+00:00</dc:date>
    <link>https://insights.ubuntu.com/2017/04/05/ubuntu-on-aws-gets-serious-performance-boost-with-aws-tuned-kernel/?__s=gf36pf8g1gjugcqh6ppo</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting -- faster boots, CPU throttling resolved on t2.micros, other nice stuff]]></description>
<dc:subject>aws ubuntu ec2 kernel linux ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:018d8e2ae296/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ubuntu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kernel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://wiki.jenkins-ci.org/display/JENKINS/Amazon+EC2+Container+Service+Plugin">
    <title>Amazon EC2 Container Service Plugin - Jenkins - Jenkins Wiki</title>
    <dc:date>2017-02-03T16:55:55+00:00</dc:date>
    <link>https://wiki.jenkins-ci.org/display/JENKINS/Amazon+EC2+Container+Service+Plugin</link>
    <dc:creator>jm</dc:creator><description><![CDATA[neat, relatively new plugin to use ECS as a autoscaling node fleet in Jenkins]]></description>
<dc:subject>ec2 ecs aws jenkins docker plugins</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:26de51b78df5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jenkins"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:plugins"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/developer-preview-ec2-instances-f1-with-programmable-hardware/">
    <title>Developer Preview – EC2 Instances (F1) with Programmable Hardware</title>
    <dc:date>2016-11-30T17:07:32+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/developer-preview-ec2-instances-f1-with-programmable-hardware/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[this is frankly amazing. Elastic FPGAs!]]></description>
<dc:subject>fpga hardware coding aws ec2</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f2a038ce758a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fpga"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hardware"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jvns.ca/blog/2016/11/16/ideas-about-how-to-use-aws/">
    <title>Julia Evans reverse engineers Skyliner.io</title>
    <dc:date>2016-11-17T12:34:18+00:00</dc:date>
    <link>http://jvns.ca/blog/2016/11/16/ideas-about-how-to-use-aws/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[simple usage of Docker, blue/green deploys, and AWS ALBs]]></description>
<dc:subject>docker alb aws ec2 blue-green-deploys deployment ops tools skyliner via:jgilbert</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f2861c3cf680/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blue-green-deploys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:skyliner"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:jgilbert"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/new-auto-scaling-for-ec2-spot-fleets/?sc_channel=sm&amp;sc_campaign=launch_EC2_522bf4f3&amp;sc_publisher=tw_go&amp;sc_content=AnyScale_support_spot_fleets&amp;sc_country=global&amp;sc_geo=globaly">
    <title>Auto Scaling for EC2 Spot Fleets</title>
    <dc:date>2016-09-05T11:35:07+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/new-auto-scaling-for-ec2-spot-fleets/?sc_channel=sm&amp;sc_campaign=launch_EC2_522bf4f3&amp;sc_publisher=tw_go&amp;sc_content=AnyScale_support_spot_fleets&amp;sc_country=global&amp;sc_geo=globaly</link>
    <dc:creator>jm</dc:creator><description><![CDATA['we are enhancing the Spot Fleet model with the addition of Auto Scaling. You can now arrange to scale your fleet up and down based on a Amazon CloudWatch metric. The metric can originate from an AWS service such as EC2, Amazon EC2 Container Service, or Amazon Simple Queue Service (SQS). Alternatively, your application can publish a custom metric and you can use it to drive the automated scaling.']]></description>
<dc:subject>asg auto-scaling ec2 spot-fleets ops scaling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ac54c86f1987/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:auto-scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-fleets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.ybrikman.com/writing/2015/11/11/running-docker-aws-ground-up/">
    <title>Running Docker on AWS from the ground up</title>
    <dc:date>2016-04-08T11:25:52+00:00</dc:date>
    <link>http://www.ybrikman.com/writing/2015/11/11/running-docker-aws-ground-up/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Advantages/disavantages section right at the bottom is good.

<blockquote>ECS, believe it or not, is one of the simplest Schedulers out there. Most of the other alternatives I’ve tried offer all sorts of fancy bells & whistles, but they are either significantly more complicated to understand (lots of new concepts), take too much effort to set up (lots of new technologies to install and run), are too magical (and therefore impossible to debug), or some combination of all three. That said, ECS also leaves a lot to be desired.</blockquote>

]]></description>
<dc:subject>aws docker ecs ec2 schedulers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:deadf4093c4e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:schedulers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/pwakeford/aws-sydney-meetup-april-2016-paul-wakeford">
    <title>AWS Billing And Cost Control [slides]</title>
    <dc:date>2016-04-08T10:56:29+00:00</dc:date>
    <link>http://www.slideshare.net/pwakeford/aws-sydney-meetup-april-2016-paul-wakeford</link>
    <dc:creator>jm</dc:creator><dc:subject>aws ec2 costs money hosting ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:68166c52777a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:costs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:money"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hosting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cloudnative.io/yeobot/">
    <title>Yeobot - CloudNative</title>
    <dc:date>2016-03-09T17:18:00+00:00</dc:date>
    <link>https://cloudnative.io/yeobot/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['The shared SQL command line for AWS'.  it's #chatopsy!]]></description>
<dc:subject>chatops yeobot bots cloudnative ec2 aws slack</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0810f735b14e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chatops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:yeobot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bots"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloudnative"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slack"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/compute/powering-your-amazon-ecs-clusters-with-spot-fleet/">
    <title>Powering your Amazon ECS Clusters with Spot Fleet</title>
    <dc:date>2016-01-20T18:30:02+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/compute/powering-your-amazon-ecs-clusters-with-spot-fleet/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[sounds feasible]]></description>
<dc:subject>amazon ec2 aws ecs autoscaling scaling ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2c1bb2a4048a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:autoscaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://perspectives.mvdirona.com/2015/12/vpc-nat-gateways-transactional-uniqueness-at-scale/">
    <title>VPC NAT gateways : transactional uniqueness at scale</title>
    <dc:date>2016-01-03T09:57:03+00:00</dc:date>
    <link>http://perspectives.mvdirona.com/2015/12/vpc-nat-gateways-transactional-uniqueness-at-scale/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[colmmacc introducing the VPC NAT gateway product from AWS, in a guest post on James Hamilton's blog no less!:

<blockquote>you can think of it as a new “even bigger” [NAT] box, but under the hood NAT gateways are different. The connections are managed by a fault-tolerant co-operation of devices in the VPC network fabric. Each new connection is assigned a port in a robust and transactional way, while also being replicated across an extensible set of multiple devices. In other words: the NAT gateway is internally horizontally scalable and resilient.</blockquote>

]]></description>
<dc:subject>amazon ec2 nat networking aws colmmacc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:795dcd0733e5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:colmmacc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.reddit.com/r/aws/comments/3xuf93/2016_wish_list_for_aws/">
    <title>2016 Wish List for AWS?</title>
    <dc:date>2015-12-22T22:56:53+00:00</dc:date>
    <link>https://www.reddit.com/r/aws/comments/3xuf93/2016_wish_list_for_aws/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good thread of AWS' shortcomings -- so many services still don't handle VPC for instance]]></description>
<dc:subject>vpc aws ec2 ops wishlist</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cfbb7b294aba/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wishlist"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://railsadventures.wordpress.com/2015/12/06/why-we-chose-kubernetes-over-ecs/">
    <title>Why We Chose Kubernetes Over ECS</title>
    <dc:date>2015-12-14T16:23:34+00:00</dc:date>
    <link>https://railsadventures.wordpress.com/2015/12/06/why-we-chose-kubernetes-over-ecs/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>3 months ago when we, at nanit.com, came to evaluate which Docker orchestration framework to use, we gave ECS the first priority. We were already familiar with AWS services, and since we already had our whole infrastructure there, it was the default choice. After testing the service for a while we had the feeling it was not mature enough and missing some key features we needed (more on that later), so we went to test another orchestration framework: Kubernetes. We were glad to discover that Kubernetes is far more comprehensive and had almost all the features we required. For us, Kubernetes won ECS on ECS’s home court, which is AWS.</blockquote>

]]></description>
<dc:subject>kubernetes ecs docker containers aws ec2 ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9426fd8edac6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_CLI_tutorial.html#ECS_CLI_tutorial_compose_service">
    <title>Amazon ECS CLI Tutorial - Amazon EC2 Container Service</title>
    <dc:date>2015-10-27T12:38:29+00:00</dc:date>
    <link>http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_CLI_tutorial.html#ECS_CLI_tutorial_compose_service</link>
    <dc:creator>jm</dc:creator><description><![CDATA[super-basic ECS tutorial, using a docker-compose.yml to create a new ECS-managed service fleet]]></description>
<dc:subject>ecs cli linux aws ec2 hosting docker tutorials</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f1f678ae8462/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hosting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tutorials"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/AdRoll/hologram">
    <title>Hologram</title>
    <dc:date>2015-10-20T19:56:17+00:00</dc:date>
    <link>https://github.com/AdRoll/hologram</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Hologram exposes an imitation of the EC2 instance metadata service on developer workstations that supports the [IAM Roles] temporary credentials workflow. It is accessible via the same HTTP endpoint to calling SDKs, so your code can use the same process in both development and production. The keys that Hologram provisions are temporary, so EC2 access can be centrally controlled without direct administrative access to developer workstations.</blockquote>

]]></description>
<dc:subject>iam roles ec2 authorization aws adroll open-source cli osx coding dev</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5801a286921c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:iam"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:roles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:authorization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:adroll"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:osx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dev"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://ispyker.blogspot.ie/2015/10/aws-reinvent-2015-video-slide.html">
    <title>AWS re:Invent 2015 Video &amp; Slide Presentation Links with Easy Index</title>
    <dc:date>2015-10-18T20:19:29+00:00</dc:date>
    <link>http://ispyker.blogspot.ie/2015/10/aws-reinvent-2015-video-slide.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Andrew Spyker's roundup:

<blockquote>my quick index of all re:Invent sessions.  Please wait for a few days and I'll keep running the tool to fill in the index.  It usually takes Amazon a few weeks to fully upload all the videos and slideshares.</blockquote>

Pretty definitive, full text descriptions of all sessions (and there are an awful lot of 'em).]]></description>
<dc:subject>aws reinvent andrew-spyker scraping slides presentations ec2 video</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c5e0596d9cbe/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reinvent"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:andrew-spyker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scraping"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:video"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://segment.com/blog/rebuilding-our-infrastructure/">
    <title>Rebuilding Our Infrastructure with Docker, ECS, and Terraform</title>
    <dc:date>2015-10-09T10:04:24+00:00</dc:date>
    <link>https://segment.com/blog/rebuilding-our-infrastructure/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good writeup of current best practices for a production AWS architecture

]]></description>
<dc:subject>aws ops docker ecs ec2 prod terraform segment via:marc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e2c14ca77c3e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prod"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:terraform"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:segment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:marc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/new-ec2-spot-blocks-for-defined-duration-workloads/">
    <title>EC2 Spot Blocks for Defined-Duration Workloads</title>
    <dc:date>2015-10-08T14:03:48+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/new-ec2-spot-blocks-for-defined-duration-workloads/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>you can now launch Spot instances that will run continuously for a finite duration (1 to 6 hours). Pricing is based on the requested duration and the available capacity, and is typically 30% to 45% less than On-Demand.</blockquote>

]]></description>
<dc:subject>ec2 aws spot-instances spot pricing time</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:77d0e9aff94b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pricing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/message/5467D2/">
    <title>Summary of the Amazon DynamoDB Service Disruption and Related Impacts in the US-East Region</title>
    <dc:date>2015-09-23T12:48:44+00:00</dc:date>
    <link>https://aws.amazon.com/message/5467D2/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Painful to read, but: tl;dr: monitoring oversight, followed by a transient network glitch triggering IPC timeouts, which increased load due to lack of circuit breakers, creating a cascading failure]]></description>
<dc:subject>aws postmortem outages dynamodb ec2 post-mortems circuit-breakers monitoring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f804599be513/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postmortem"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:post-mortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:circuit-breakers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.cloudsploit.com/2015/09/15/how-we-use-lambda/">
    <title>How We Use AWS Lambda for Rapidly Intensifying Workloads · CloudSploit</title>
    <dc:date>2015-09-16T04:16:54+00:00</dc:date>
    <link>http://blog.cloudsploit.com/2015/09/15/how-we-use-lambda/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[impressive -- pretty much the entire workload is run from Lambda here]]></description>
<dc:subject>lambda aws ec2 autoscaling cloudsploit</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5b91285e9a68/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lambda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:autoscaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloudsploit"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/ec2/spot/bid-advisor/">
    <title>Spot Bid Advisor</title>
    <dc:date>2015-09-02T12:45:25+00:00</dc:date>
    <link>https://aws.amazon.com/ec2/spot/bid-advisor/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>analyzes Spot price history to help you determine a bid price that suits your needs.</blockquote>

]]></description>
<dc:subject>ec2 aws spot spot-instances history</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7717e3fd0a19/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spot-instances"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:history"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://ben.straub.cc/2015/08/19/kubernetes-aws-vpc-peering/">
    <title>Kubernetes and AWS VPC Peering – Ben Straub</title>
    <dc:date>2015-08-19T22:07:18+00:00</dc:date>
    <link>http://ben.straub.cc/2015/08/19/kubernetes-aws-vpc-peering/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[the perils of overloading 10/8 ]]></description>
<dc:subject>10/8 ec2 aws vpc kubernetes ops internet ip-addresses</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:23c27a56f95d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:10/8"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip-addresses"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.takipi.com/amazon-ec2-2015-benchmark-testing-speeds-between-aws-ec2-and-s3-regions/">
    <title>Amazon EC2 2015 Benchmark: Testing Speeds Between AWS EC2 and S3 Regions</title>
    <dc:date>2015-08-11T10:03:51+00:00</dc:date>
    <link>http://blog.takipi.com/amazon-ec2-2015-benchmark-testing-speeds-between-aws-ec2-and-s3-regions/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Here we are again, a year later, and still no bloody percentiles! Just amateurish averaging.  This is not how you measure anything, ffs.  Still, better than nothing I suppose]]></description>
<dc:subject>fail latency measurement aws ec2 percentiles s3</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4e5264c55d58/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lg.io/2015/07/05/revised-and-much-faster-run-your-own-highend-cloud-gaming-service-on-ec2.html">
    <title>Revised and much faster, run your own high-end cloud gaming service on EC2!</title>
    <dc:date>2015-07-10T22:49:32+00:00</dc:date>
    <link>http://lg.io/2015/07/05/revised-and-much-faster-run-your-own-highend-cloud-gaming-service-on-ec2.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[a g2.2xlarge provides decent Windows GPU performance over the internet, at about $0.53 per hour]]></description>
<dc:subject>gaming games ec2 amazon aws cloud windows hacks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:aa886a192762/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gaming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:games"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:windows"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/vpc-flow-logs-log-and-view-network-traffic-flows/">
    <title>VPC Flow Logs</title>
    <dc:date>2015-06-15T11:11:30+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/vpc-flow-logs-log-and-view-network-traffic-flows/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>we are introducing Flow Logs for the Amazon Virtual Private Cloud.  Once enabled for a particular VPC, VPC subnet, or Elastic Network Interface (ENI), relevant network traffic will be logged to CloudWatch Logs for storage and analysis by your own applications or third-party tools.

You can create alarms that will fire if certain types of traffic are detected; you can also create metrics to help you to identify trends and patterns. The information captured includes information about allowed and denied traffic (based on security group and network ACL rules). It also includes source and destination IP addresses, ports, the IANA protocol number, packet and byte counts, a time interval during which the flow was observed, and an action (ACCEPT or REJECT).</blockquote>

]]></description>
<dc:subject>ec2 aws vpc logging tracing ops flow-logs network tcpdump packets packet-capture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:60c85edd365b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tracing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:flow-logs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:network"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcpdump"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packet-capture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://highscalability.com/blog/2015/6/8/leveraging-aws-to-build-a-scalable-data-pipeline.html">
    <title>Leveraging AWS to Build a Scalable Data Pipeline</title>
    <dc:date>2015-06-14T21:22:02+00:00</dc:date>
    <link>http://highscalability.com/blog/2015/6/8/leveraging-aws-to-build-a-scalable-data-pipeline.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice detailed description of an auto-scaled SQS worker pool]]></description>
<dc:subject>sqs aws ec2 auto-scaling asg worker-pools architecture scalability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:83cb65158dca/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:auto-scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:asg"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:worker-pools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>