Encryption on Amazon MWAA
The following topics describe how Amazon MWAA protects your data at rest, and in transit. Use this information to learn how Amazon MWAA integrates with Amazon KMS to encrypt data at rest, and how data is encrypted using Transport Layer Security (TLS) protocol in transit.
Encryption at rest
On Amazon MWAA, data at rest is data that the service saves to persistent media.
You can use an Amazon owned key for data at rest encryption, or optionally provide a Customer managed key for additional encryption when you create an environment. If you choose to use a customer managed KMS key, it must be in the same account as the other Amazon resources and services you are using with your environment.
To use a customer managed KMS key, you must attach the required policy statement for CloudWatch access to your key policy. When you use a customer managed KMS key for your environment, Amazon MWAA attaches four grants on your behalf. For more information on the grants Amazon MWAA attaches to a customer managed KMS key, see Customer managed keys for data encryption.
If you do not specify a customer managed KMS key, by default, Amazon MWAA uses an Amazon owned KMS key for to encrypt and decrypt your data. We recommend using an Amazon owned KMS key to manage data encryption on Amazon MWAA.
Note
You pay for the storage and use of Amazon owned, or customer managed KMS keys on Amazon MWAA. For more information, see Amazon KMS Pricing
Encryption artifacts
You specify the encryption artifacts used for at rest encryption by specifying an Amazon owned key or Customer managed key when you create your Amazon MWAA environment. Amazon MWAA adds the grants needed to your specified key.
Amazon S3 – Amazon S3 data is encrypted at the object-level using Server-Side Encryption (SSE). Amazon S3 encryption and decryption takes place on the Amazon S3 bucket where your DAG code and supporting files are stored. Objects are encrypted when they are uploaded to Amazon S3 and decrypted when they are downloaded to your Amazon MWAA environment. By default, if you are using a customer managed KMS key, Amazon MWAA uses it to read and decrypt the data on your Amazon S3 bucket.
CloudWatch Logs – If you are using an Amazon owned KMS key, Apache Airflow logs sent to CloudWatch Logs are encrypted using Server-Side Encryption (SSE) with CloudWatch Logs's Amazon owned KMS key. If you are using a customer managed KMS key, you must add a key policy to your KMS key to allow CloudWatch Logs to use your key.
Amazon SQS – Amazon MWAA creates one Amazon SQS queue for your environment. Amazon MWAA handles encrypting data passed to and from the queue using Server-Side Encryption (SSE) with either an Amazon owned KMS key, or a customer managed KMS key that you specify. You must add Amazon SQS permissions to your execution role regardless of whether you are using an Amazon owned or customer managed KMS key.
Aurora PostgreSQL – Amazon MWAA creates one PostgreSQL cluster for your environment. Aurora PostgreSQL encrypts the content with either an Amazon owned or customer managed KMS key using Server-Side Encryption (SSE). If you are using a customer managed KMS key, Amazon RDS adds at least two grants to the key: one for the cluster and one for the database instance. Amazon RDS might create additional grants if you choose to use your customer managed KMS key on multiple environments. For more information, see Data protection in Amazon RDS.
Encryption in transit
Data in transit is referred to as data that may be intercepted as it travels the network.
Transport Layer Security (TLS) encrypts the Amazon MWAA objects in transit between your environment's Apache Airflow components and other Amazon services that integrate with Amazon MWAA. such as Amazon S3. For more information about Amazon S3 encryption, see Protecting data using encryption.