1

Situation

We have a sandbox AWS account for trying things out. It is not for production, purely just for playing around with all the toys that AWS provide. We want to encourage everyone to explore and learn.

We have many AWS accounts in our estate, including but not limited to,

  • sandbox
  • development
  • test
  • production

Financial and environmental responsibility is important to us.

Requirement

  • Must
    • automatically destroy everything in the sandbox account.
    • only be capable of running on this specific account.
  • Should
    • destroy an instance after x hours.
  • Could

Potential solutions

aws-nuke

I have seen aws-nuke. If we ran this at midnight on Wednesdays and Sundays it would terminate all instances. This sounds like a great solution, however it is also somewhat dangerous as it could terminate instances on other accounts my mistake. It also currently works on a block-nuke list, rather than an explicit allow-nuke list which is another potential security issue. I have logged aws-nuke#751 to address this.

Max uptime policy

The other method that I am looking into is to use a policy (IAM?) to set the maximum uptime for everything. I feel like this has less likelihood of leaking into our other accounts and also has the potential to be more nuanced. I'm not sure,

  • how best to implement this
  • whether it needs to be run in a lambda or can just be a policy
  • whether this is actually more secure than running aws-nuke across the estate.

I would be tremendously grateful for any pointers.

James Geddes
  • 131
  • 7

1 Answers1

0

At one previous employer someone had written a Lambda function to list all running instances and stop them each night at 7pm if they didn't have a specific tag. This was a pretty simple, effective way to handle it. The python boto3 libraries are pretty easy to use.

The lambda was deployed in the Organisation and used a cross-account role, but you could just as easily deploy it via a StackSet into all org accounts, and have it only target that accounts instances.

shearn89
  • 3,403
  • 2
  • 15
  • 39
  • Hmm I was hoping to avoid using a lambda as the run could be a long one if many instances are created. – James Geddes Mar 04 '22 at 15:02
  • 1
    Could always break it up, have one Lambda generate the list -> SQS -> others. I'd expect the API call to stop an instance is a quick one. Other option is a spot instance that runs the same code? – shearn89 Mar 04 '22 at 16:49