Storing and using secret information securely with AWS SSM The SSM Parameters store is a great way to securely store hierarchical configuration data. It is widely used by AWS to provide parameters it own services. The names of the parameters are guaranteed to be unique and of arbitrary structure, allowing users to store nested structures of configuration data. In this post I will examine how to use Parameters Store efficiently to provide settings and secrets to Docker containers executed on ECS.
ECS Autoscaling The topic of ECS autoscaling is a vast area of heated discussions and broken dreams. It is quite hard to come up with efficient scaling policies for your ECS services. And the more distributed your architecture, the more issues with cascading load and increasing latency you are going to face. But fear not, the promised salvation in form of autoscaling for your services is here to save the day and distribute your computing load evenly across your micro services.
DynamoDB Autoscaling DynamoDB autoscaling is a feedback-loop based monitoring setup which can dynamically change provisioned capacity for the table or global secondary index. There are two ways one can define autoscaling policy for this resource: Step scaling policy Target tracking policy Step scaling policy The first kind of policy - step scaling - is based on CloudWatch alarms. This approach is the original autoscaling policy, the kind of which has been available to us from the beginning of days.
A very in-depth article from our friends at ScyllaDB about how they fought an I/O latency bug in Linux CFQ scheduler. Big latencies? It’s open season for kernel bug-hunting! I remember myself back in like 4 years ago struggling to understand how can select on non-blocking socket take anywhere up to a 15 seconds to return on AWS. However my issue was not related to the scheduler but the quest and persistence of ScyllaDB team is just another reminder that there are people who really care.