Forem: Prahal N P

EC2 Key Pairs

Prahal N P — Fri, 19 Dec 2025 05:46:29 +0000

EC2 key pairs are cryptographic keys used for secure SSH access to Amazon EC2 instances.

It's a combination of 2 keys.

Public key: Stored by AWS and placed on your EC2 instance.
Private key: Downloaded to your local machine.

How EC2 Key Pair works:

While creating an ec2 instance we have 2 option we can provide the existing key pair or we can create part of the ec2 instance.
Once the ec2 key-pair created, we have an option to download the private key. Once downloaded AWS will delete it and cannot be recovered.
Public key will be stored within AWS and used by Ec2 instances.
When we create the instance by providing the key-pair the public key will be stored in the ~/.ssh/authorized_keys folder.
While connecting to instance user use the Private key instead of password.

Note:

Key Pairs don't get deleted from Ec2 instance's root volume when the key pair removed from the ec2 console
Launching an ec2 with the golden/pre-build ami, the old key(used while building AMI) will exist with the new key pair in the root volume. User can Use any of the private keys to SSH the instance.

How Instance Connect works:

User Initiate the connection by Ec2 Instance connect API.
Ec2 instance connect will create an temporary ec2 key pair.
Private key will be handled by ec2 instance connect and public key will be passed to instance through instance metadata which will be valid only for 60 seconds. 4.Ec2 instance connect will ssh the ec2 with the AWS IP address range to the instance with the Private key.
The session starts and all the connections are logged in cloudtrail.

How to Connect to Linux EC2 Instance with a Lost
SSH Key Pair:

Create a new Key Pair
Stop the original EC2 instance
Detach the EBS root volume
Attach the EBS volume to a temporary EC2 instance as a secondary volume
Add the new public key to ~/.ssh/authorized_keys on the volume
Re-attach the volume to the original instance, then restart the instance

AWS Envelop Encryption

Prahal N P — Thu, 18 Dec 2025 06:43:22 +0000

First we will learn what is encryption, Encryption is the process of scrambling readable data (plaintext) into an unreadable code (ciphertext) using an algorithm and a secret key, preventing unauthorized access.

In AWS, the KMS service manages encryption, specifically for data at rest. This service encrypts data only if its size is less than 4 KB. For data larger than 4 KB, KMS uses envelope encryption.

How AWS Encryption and Decryption works works:

For data size less than 4 kb KMS will take care of the encryption process.

AWS SDK/CLI calls the encrypt API with the secret data.
KMS validates the IAM permissions for the user to perform the API.
If the user has permission, KMS encrypts the data and sends the encrypted data.
During decryption, AWS SDK/CLI calls the decrypt API with the encrypted data.
KMS validates the IAM permissions for the user to perform the API.
If the user has permission, KMS decrypts the data and sends the decrypted data.
AWS KMS manages the encryption/decryption key if we use keys stored in KMS.

How AWS Envelope Encryption works:

KMS Encrypt API call has a limit of 4 KB. If you want to encrypt >4 KB, we need to use Envelope Encryption

Encryption:

This time we want to encrypt a big file ie, more than 4KB file.
We are going to use the SDK to call the GenerateDataKey API by specifying CMK.
If the requester has the permission, KMS will provide 2 keys, plaintext DEK and encrypted DEK.
SDK will encrypt the secret file with the plaintext DEK.
Finally SDK will create an single Final file which has encrypted secret file and encrypted DEK.

Decryption:

During decryption AWS SDK will call the Decrypt API with the envelop file.
If the requester has the permission, KMS will decrypt the encrypted DEK part of the envelop file using KMS CMK, and send the plaintext data key.
AWS SDK will decrypt the encrypted file.

High Availability Multi-Region RDS Instance

Prahal N P — Sat, 05 Apr 2025 03:08:50 +0000

Amazon Relational Database Service (Amazon RDS) is an managed relational database service. Amazon RDS automates undifferentiated database management tasks, such as provisioning, configuring, backing up, and patching.

Currently AWS support Highly available, durable relational databases deployed across up to three Availability Zones (AZs) ie, Multi-AZ where standby instance is created in other availability zone to enhance availability and resilience, ensuring that if one zone fails, the system can automatically switch to another. AWS support multi-AZ where any availability zone goes down the system will be available through standby instance.

The solution outlined here supports the RDS instance during regional unavailability. In this setup, resources are provisioned using Cloudformation templates.

Primary region architecture:

The CloudFormation stack outlined above provisions the following resources: two Lambda functions that create RDS-related resources, an SSM parameter containing the RDS information, and an alarm parameter. where lambda code will be residing in the s3 bucket. Here this template expects the RDS parameter and alarms parameters as input.

The Create_resource_primary_region Lambda function will be established as a component of the CloudFormation template. It is triggered directly from the stack itself. During the stack creation process, this Lambda function activates and generates RDS instance, alarms based on the provided input. Additionally, this Lambda function updates the parameters to the SSM parameter, which is integral to the stack.

The Create_stack_secondary_region lambda function is designed to retrieve the CloudFormation template from S3. Based on the specified secondary region parameter, it will create a stack in that region. which completes the deployment process in the primary region, which is halfway in our overall solution.

Secondary region architecture:

This stack provisions the following resources: 2 event-bridge rule, an ssm parameter, an lambda function and an sns-topic.

During the stack creation, the Create_resource_failover_fallback_action Lambda function is triggered. This function creates a read replica in the secondary region from the primary region's RDS instance. Additionally, it updates the RDS instance parameters and alarm parameters in the SSM parameter store. This process successfully completes the deployment.

During the primary region outage, the RDS_failover_event event bridge rule will trigger the Create_resource_failover_fallback_action lambda which will do following actions.

Notifies outage to users through sns topic.
failover_status_check event rule will be disabled intially but enables now which will invoke the lambda every 5mins.
Promotes the RDS Read replica(This will take sometime in this time the rds will be outage)

The failover_status_check rule triggers a lambda function that verifies the promotion status. If the instance is successfully promoted, the lambda creates an alarm. Once all components are set up, signaling the completion of the failover process. The failover_status_check rule is then disabled, and users are notified through the designated topic.

In the event that the region recovers during the promotion phase, the RDS_failover_event rule will notify the lambda, which will delete the promoting instance and create a new read replica in the secondary region using the primary region instance. Users will also receive notifications through the topic in this scenario.

Once the primary region comes back then RDS_failover_event rule will notifies the lambda which will do the same steps for fallback ie,

Notifies outage to users through sns topic.
failover_status_check event rule will be disabled initially but enables now which will invoke the lambda every 5mins.
Create the read replica in the primary region from secondary region instance, the primary region instance and the alarm are deleted, the execution exits.
The failover_status_check rule will trigger the lambda every 5 mins so it will be checking creating status once created..
Promotes the RDS Read replica in primary region.(This will take sometime in this time the rds will be outage) Failover_status_check rule will invoke the lambda which will check for the promotion status if promoted then lambda creates alarm and create read replica in secondary region. once everything created, the secondary region instance and alarm will be deleted and fallback is completed, disables the failover_status_check rule and notifies users through the topic.

Note: Here we can fallback during maintenance windows too.Incase user has budget concern we can use the rds automated backups instead of the read-replicas which will reduce the budget but there is limitation of supported replication region!!

Following is the RDS_failover_event event rule pattern:
{
"source": ["aws.health"],
"detail-type": ["AWS Health Event"],
"detail": {
"service": ["RDS"],
"eventTypeCategory": ["issue"],
"eventTypeCode": ["AWS_RDS_API_ISSUE", "AWS_RDS_CONNECTIVITY_ISSUE", "AWS_RDS_OPERATIONAL_ISSUE"],
"statusCode": ["open","closed"]
},
"resources": [!Ref pDBIdentifier],
"region": [!Ref pPrimaryRegion]
}