Since you are using Standard Edition, you cant use TDE. So other options are
Using encryption keys at instance/database level :
SQL Server has two kinds of keys: symmetric and asymmetric. Symmetric keys use the same password to encrypt and decrypt data. Asymmetric keys use one password to encrypt data (called the public key) and another to decrypt data (called the private key).
SQL Server has two primary applications for keys: a service master key (SMK) generated on and for a SQL Server instance, and a database master key (DMK) used for a database.
Also, you can have encryption at column level by creating a MASTER KEY ENCRYPTION along with CREATE CERTIFICATE and then CREATE SYMMETRIC KEY.
An example of how this can be done is described at Encrypt a Column of Data
Reference : SQL Server and Database Encryption Keys (Database Engine)
At Drive level :
Using BitLocker as it is a Drive Encryption data protection feature available Windows Server 2008 R2. Refer to : BitLocker Drive Encryption Overview There are many opensource or third party software to do the same job but at additional cost.
Note: The most important bit is ALWAYS backup your encryption keys.
You can use third party software like Redgate's sql backup which allows you to encrypt backups using passwords.
Depending on what level you need encryption will determine if it is worth upgrading to enterprise edition or not. You have to evaluate native TDE encryption vs encryption keys and certificates vs open source vs disk encryption.
Generally, for best results on Stack, you want to break each question up into its own question, but here we go:
Q: When I run this command, is the data left unencrypted on the disk at any point?
Not by the key change process, but be aware that filestream and replication data aren't encrypted regardless. For more details, check Books Online's section on TDE.
Q: i.e. Does this command first unencrypt all the data using the old key/certificate and then re-encrypt it using the new one, which would mean that the data is unencrypted at some point in the process.
No. For more details, see Microsoft's post on encryption key management.
Q: Bonus question, what happens to the log file during the key change?
Changes to the database are logged operations, so you'll need to watch the size and speed of your transaction log just like you did when you first applied TDE to the database.
Best Answer
AE is intended to protect sensitive data end-to-end. That's why keys are held by the client, not server. In SQL Server 2016 granularity is at the column level.
If you want to AE the entire database, you'd have to do it one column at a time. That doesn't really make sense and doesn't fit the AE scenario unless all data in your database is sensitive. Theoretically possible but pretty rare in reality. You've also made your database extremely limited in query capabilities and perf is pretty much out the window.