Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design mechanism for auto-creation of per-ENI mirroring #33

Closed
chelma opened this issue Apr 25, 2023 · 4 comments
Closed

Design mechanism for auto-creation of per-ENI mirroring #33

chelma opened this issue Apr 25, 2023 · 4 comments
Labels
Capture Resilience Work to make traffic capture more resilient to changes in load, configuration, and sources

Comments

@chelma
Copy link
Collaborator

chelma commented Apr 25, 2023

Description

Currently, the only way to update which ENIs are monitored in a particular user-VPC is invoke remove-vpc & add-vpc to tear down capture and stand it back up, a process with currently takes ~10 minutes. This is obviously not the desired experience.

This task is to investigate options for more nimble, ideally automatic, creation and destruction of per-ENI mirroring configuration and propose a initial solution to the problem. The proposal should ideally address the following topics:

  • Automated creation/destruction of per-ENI configuration in each user-VPC
  • A way for users to initiate this process themselves if they wish
  • How the system will behave for longer-lived (EC2 instances) and shorter lived (Lambda containers) resources
  • How the system will handle multiple, concurrent and/or conflicting instructions

This task will NOT address changes in the network topography of the user's VPC (e.g. adding/removing subnets); that will be addressed with the refresh-cluster command (see: #32)

Acceptance Criteria

  • Proposal design, written up in GitHub
@chelma chelma added the Capture Resilience Work to make traffic capture more resilient to changes in load, configuration, and sources label Apr 25, 2023
@chelma
Copy link
Collaborator Author

chelma commented Apr 25, 2023

Taking a look at things, AWS Event Bridge [1] seems like a good option to explore further. I'm thinking we'll have one or more Lambda functions that are capable of setting up/tearing down the per-ENI resources. We'll probably schedule them to fire on a regular cadence as a backstop, and then use Event Bridge to catch things like EC2 ASG and ECS scale up/down events and react sooner than backstop would fire. LOTS of AWS Services fire these events [2].

[1] https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html
[2] https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-event-list.html

@chelma
Copy link
Collaborator Author

chelma commented Apr 26, 2023

Design proposal posted: #35

@chelma
Copy link
Collaborator Author

chelma commented Apr 27, 2023

@chelma
Copy link
Collaborator Author

chelma commented Apr 27, 2023

Task completed; resolving.

@chelma chelma closed this as completed Apr 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Capture Resilience Work to make traffic capture more resilient to changes in load, configuration, and sources
Projects
None yet
Development

No branches or pull requests

1 participant