aws / aws/aws-ec2-instance-connect-config
Please cache results
- Dominant language
- Shell
- Stars
- 88
- Forks
- 39
- PR merge metrics
- No merged PRs in 30d
Description
Hi,
I was reviewing the general concepts of EIC a [while ago](https://bugs.launchpad.net/ubuntu/+source/ec2-instance-connect/+bug/1835114/comments/7) and wanted to now file this report for discussion here. Because one thing I started to wonder was about was what would happen if you have e.g. remotely driven automation that might have hundreds of ssh calls per second.
Obviously one could say "push a script to the system and execute that" but many automation solutions just don't work that way. In that context EIC will work like an amplifier which means every of those ssh logins will trigger a multitude of curl calls each adding latency and overhead.
I was wondering if it would seem reasonable to you to rate-limit this.
You could use timestamps and only re-check everything once every x seconds.
The first login won't find a timestamp and has to work it out, but every later login for some time doesn't need to do the same work over and over again.
That could help scalability and drop overhead a lot at almost no loss IMHO.
I have not found a "I already got my Auth-data, fast-path-skip" in the code - if there is one that I missed please just let me know and consider this almost resolved :-)
Contributor guide
Research direction
The issue names no file or test; start by tracing the EC2 Instance Connect login path and its repeated curl calls during SSH logins. Clarify whether the project wants timestamp-based caching or rate limiting, define the cache interval and invalidation behavior, and agree on tests and acceptance criteria before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, shell
- Domain
- authentication, cloud
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100