Net::Telnet's pod:

The typical usage bug causes a time-out error because you've made incorrect assumptions about what the remote side actually sends. The easiest way to reconcile what the remote side sends with your expectations is to use input_log() or dump_log().

However, you say that all your waitfor()'s are not timing out because the last action, destroy, happens OK. So your problem is after issuing $t->cmd('yes');

I suggest logging to a file and see what happens after that "yes" using $t->dump_log("mylog.txt"); before connecting. Could host be asking you another question after destroying that volume?

Now, this route is simple but painful (and relatively secure). Another route, already suggested, is setting a webserver on remote and having it execute actions whenever you do something like http://10.10.4.46/?action=delete_volume provided that you also authenticate (via cookies etc.) which means that your basic webserver now has to have a secure login page. This job can be made easier by using some framework, like Dancer2::Cookbook, instead of plain old CGI but your setup gets more and more complex. HOWEVER, this solution implies that on remote machine you have scripts which do the action without asking you to confirm. Of course you can add an html-based confirm dialog before you execute the action but it will not be the actual confirmation aggr destroy is asking. That can (probably) be bypassed in a very hackish way using the following echo "yes" | aggr destroy XYZ or set no-confirmations mode (I am sure there is something to set this up for aggr delete) or use Expect as suggested already here (in a way similar to waitfor)

Also, there is the way of executing a command on a remote server using ssh. The benefit of it is that it can be password-less (via keeping keys etc.). E.g. alias XYZ='ssh abc@host command'. Use -t if you want interactive session. ssh's friend is screen which remembers the state of your remote shell even if you logout, meaning history command, past command output etc. But I digress. Bottomline is, you have plenty of options to automate but you need to plan security (passwords, webservers etc.) and safety (running delete without confirmation).