actually alert fatigue started from healthcare initially where doctors become desensitized to safety alerts, and as a result ignore or fail to respond appropriately to such warnings - it is the same problem in tech companies where you get all these muted Slack channels. It’s a problem almost every company faces at some point of its life
actually, it’s 100 workflows, 20 providers and 10 users. important to note that it’s per deduplicated alert and not every event ingested by keep. what got you surprised about this pricing model?
In surprised because 500 deduplicated alerts requiring human attention is a normal day for my company. If something goes really wrong it'd start to get very expensive.
one of our goals is to help you better manage those alerts and reduce the total number. I would have loved to hear more about those 500 alerts use case, im sure checking up Keep would be a super interested use case
it's definitely relevant for early-stage products who deeply care about realiability. are you already handling some amount of alerts today? there's a bunch of stuff you can do with workflows to automate processes and help your users.
we do integrate with AWS Cloudwatch but not yet with Vercel's observability, but can add that if you want to give it try
How does it do that for ruby for example? (which is in the link you provided). OTEL instrumentation for HTTP doesn’t instrument the body so you won’t be able to see token usage, prompts and completions. Or am I missing something?
why just now? there are many known attacks (SSRF[1] for example) that are based on IMDSv1.
maybe i'm missing something but feels like this should have been done a long ago?
The migration isn't transparent, IMDSv2 has been available for a while and they have been pushing for it using warning notifications in the console. AWS deprecates things very slowly and usually avoid breaking changes. For instance, EC2 Classic stayed alive a very long time after they stopped selling it.
Over years, they moved from alerting to changing the default and will later remove IMDSv1 for new instances. Even then, they will not remove it for the previous generations and those may stay for years, the current oldest is M4 which I think is from 2015.
IMDSv2 was initially introduced after the capital one attack. but aws users will have to explicitly enable it and its not enabled by default.
now they are changing the default modes for instances launched from aws console using quick start process. and sometime in 2024 they will give an option to customers to control the default value for all run instances API calls from an account
IMDSv2 has been enabled by default since launch, and was made the default in the AWS SDKs at the same time. What's changing now is that IMDSv1 will be disabled by default. Until now customers had to disable it intentionally, either at the instance level, or by using IAM policies / SCPs to block calls still using IMDSv1 issued credentials.
I think we mean different things, it is enabled by default but I'm saying thats not the default IMDS version that metadata endpoint points to for `/latest/`
for example if you run below curl request on ec2 instances launched from aws console before nov 6th then you will get a response
IMDSv2 doesn't change the URLs, the "/latest/" in that URL is referring to the meta-data profile, rather than the IMDS version. IMDS is a lower level change in the authentication workflow to use a token (which is retrieved using a PUT request).
Because unlike some other providers, AWS understands the value of backward compatibility. They were the first to make the concept of simultaneously deployed versioned public HTTP APIs work seamlessly at scale, and the number of actually impactful API deprecations they have done is tiny. This is one of them.
Prior to this change, IMDSv2 could be enforced on an account, machine image, and launch API call level.
reply