Typically when regression testing is talked about, it's tests that ensure features don't break from one release to another.
Automated testing is a big category. It includes, but is not limited to regression testing with it's sub categories like smoke/bvt testing, unit tests, scripted UI automation. There are lots of other kinds of automation. Monkey automation that just randomly pushes buttons and looks for crashes, randomized fuzz testing, data integrity testing of databases and semi automated tasks are some examples. There are many more
Further, the traits of good regression tests are different than other categories of automation. Regression test code needs to be relatively fast, reliable, diagnostic and easy to maintain. The goal is not to find "good" or new bugs. The goal is to ensure the changes to the code base don't have a ripple effect that isn't notices early on. Your regression tests should always be passing. If a test is failing every day for a week and no one cares you have a problem. Soon it will be two, then ten and then no one will care about the regression reports because "those things never pass anyway."
There is a large class of ad-hoc automation and semi-automated tests. These should be cheap, planned to have a short lifespan and be super useful in either finding new bugs or pointing out areas where bugs might be lurking. Simply parsing log files with a perl script or logparse.exe and looking for anomalies is a good example. Because the results often require human judgment to parse, writing super clean automation to find bugs that may or may not exist has a poor return on investment. It's possible to find entire classes of bugs, which then need a root cause and some focused regression tests very cheaply. Don't apply the rigid coding standards to throw away testing. Rule of thumb, if it's faster to just write the script again next release than to document and check it in, throw your junky code away and make a note to do it again next release.
Performance and Stress automation are not often considered regression automation. You can make your perf and stress automation into regression tests, but it's not always cost effective. They often end up in the semi-automatic camp where a person has to curate the tests and the results for each run.
Lastly there is a infrastructure automation. Deployment scripts, database cleanup jobs and the regression test framework are examples. They often fall into a gray area between test and product. Some of the best infrastructure automation has built in build-test-deploy cycles. None of that is regression testing per se, but having good infrastructure automation is a key to a smooth process.