There is a solution to this requirement of securing sensitive information in Lambda functions.

Environment variables for Lambda functions enable you to

• dynamically pass settings to your function code and libraries, without making changes to your code. 

Read More about them at https://kaustubhsharma.com/blog/Lambda-functions

Storing the variables in an encrypted DynamoDB table is not necessary when you can use encryption helpers. It's become a more complicated process.

ENCRYPTION AT TRANSIT:

• When you use environment variables, you can enable console encryption helpers to use client-side encryption to protect the environment variables in transit.

ENCRYPTION AT REST :

• You can use environment variables to store secrets securely for use with Lambda functions. Lambda always encrypts environment variables at rest. By default, Lambda uses an AWS KMS key that Lambda creates in your account to encrypt your environment variables. This AWS managed key is named aws/lambda. However, you can Customer managed Keys if required.

Read more about it at https://kaustubhsharma.com/blog/Lambda-functions

CIPHERTEXT:

• It is encrypted text transformed from plaintext using an encryption algorithm. 
• It can't be read until it has been converted into plaintext (decrypted) with a key.

When you deploy your Lambda function, all the environment variables you’ve specified are encrypted by default after, but not during, the deployment process. They are then decrypted automatically by AWS Lambda when the function is invoked. If you need to store sensitive information in an environment variable, you should encrypt that information before deploying your Lambda function. The Lambda console makes that easier for you by providing encryption helpers that leverage AWS Key Management Service to store that sensitive information as Ciphertext.

1." sensitive information is properly secured"  - This sensitive information is stored as environment variables within Lambda so we need encryption of environment variables.

So, environment variables are encrypted at transit by enabling console encryption helpers to use client-side encryption.

To encrypt environment variables at rest, Lambda uses an AWS KMS key by default that Lambda creates in your account to encrypt your environment variables. This AWS managed key is named aws/lambda.

S3 Standard for general-purpose storage of frequently accessed data. However, after 90 days, we don't want to expire data as it must be retained for compliance.

Reduced Redundancy Storage (RRS) is an Amazon S3 storage option that enables customers to store non-critical, reproducible data at lower levels of redundancy than Amazon S3’s standard storage.

But the issue with RRS is that you cannot transition from any storage class to REDUCED_REDUNDANCY.

Read all other unsupported S3 lifecycles transitions:https://kaustubhsharma.com/blog/s3-lifecycle-transitions

S3 Glacier Deep Archive is Amazon S3’s lowest-cost storage class and supports long-term retention and digital preservation for data that may be accessed once or twice a year. 

S3 Standard-IA is for data that is accessed less frequently but requires rapid access when needed. 

1."rarely accessed"  clearly indicates two options DEEP ARCHIVE & REDUCED REDUNDANCY. But Reduced redundancy doesn't support lifecycle transition. So, the correct answer is DEEP ARCHIVE .

The best solution is to use Amazon SQS to decouple the front end from the processing compute layer. To do this you can create a custom CloudWatch metric that measures the number of messages in the queue and then configure the ASG to scale using a target tracking policy that tracks a certain value.

The Amazon Simple Notification Service (SNS) is used for sending notifications using topics. Amazon SQS is a better solution for this scenario as it provides a decoupling mechanism where the actual images can be stored for processing. SNS does not provide somewhere for the images to be stored.

Using a target tracking policy with the ASG that tracks CPU utilization does not allow scaling based on the number of images being uploaded.

Using a scheduled policy is less dynamic as though you may be able to predict usage patterns, it would be better to adjust dynamically based on actual usage.

1. "processing layer should be decoupled from the front end" - SQS has a better decoupling mechanism where the actual images can be stored for processing, whereas SNS doesn't.