Data encryption is a critical component of cloud security, especially when dealing with sensitive workloads in regulated environments. Amazon S3 provides multiple encryption mechanisms that cater to different compliance and operational needs. This guide goes beyond the basics, diving into advanced configurations, key management strategies, and best practices for enterprise-grade security.

Why Encrypt Data in S3?

Encryption ensures that even if data is accessed without authorization, it remains unreadable. For enterprises, encryption is not optional—it’s a compliance mandate. AWS offers encryption at rest and in transit, but understanding the nuances of each method is key to building a secure architecture.
Advanced Consideration: Evaluate encryption requirements based on data classification, regulatory frameworks (e.g., GDPR, HIPAA), and internal security policies. For multi-account setups, enforce encryption through Service Control Policies (SCPs) and AWS Config rules.

Encryption Options in Amazon S3

AWS S3 supports two primary encryption paradigms: Server-Side Encryption (SSE) and Client-Side Encryption. Each has advanced features that can be leveraged for enterprise use cases.

1. Server-Side Encryption (SSE)

Server-side encryption with Amazon S3 is by far the simplest option and requires very little effort to enable. All you need to do is set the server-side encryption flag in the object metadata when uploading your data. Once your data reaches S3, it is encrypted automatically and stored securely. When you retrieve the data, Amazon S3 decrypts it seamlessly as it streams back to your application, so the process is completely transparent to you.

The key advantage of server-side encryption is that AWS manages the encryption keys on your behalf, making it incredibly easy to adopt without changing your application logic. Your data remains encrypted at rest in S3, and you don’t need to worry about key storage or rotation. This approach is ideal for organisations looking for a quick, compliant solution without the complexity of managing encryption keys themselves. AWS encrypts data before writing it to disk.

• SSE-S3 (AES-256): Simplest option; AWS manages keys. Ideal for workloads where compliance does not require customer-managed keys.

• SSE-KMS: Integrates with AWS Key Management Service for granular control, key rotation, and audit trails. Supports encryption context for additional security metadata.

• SSE-C: Customer-provided keys; AWS never stores your key. Requires strict operational discipline for key lifecycle management.

Advanced Option: Use bucket policies to enforce SSE-KMS and deny uploads without encryption headers. Combine with KMS key policies for least privilege access.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIncorrectEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:awsN:s3:::bucket-br/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Sid": "DenyNonKMSKey",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:awsN:s3:::bucket-br/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
        }
      }
    }
  ]
}

2. Client-Side Encryption

Client-side encryption is an alternative approach for securing your sensitive data before it ever leaves your environment/application. Unlike server-side encryption, this method ensures that your data remains encrypted throughout its journey, giving you complete control over the encryption keys. By using the AWS SDK for Java, you can implement client-side encryption with the AmazonS3EncryptionClient, which replaces the standard AmazonS3Client. The transition is straightforward because the encryption client shares the same interface as the standard client, meaning existing code requires minimal changes. Once configured, the client automatically encrypts data as it streams to Amazon S3 and decrypts it when retrieved, ensuring seamless integration with your application.

The key distinction between server-side and client-side encryption lies in key management. With client-side encryption, you are responsible for providing EncryptionMaterials, which dictate how the encryption process operates. This added responsibility offers stronger security because AWS never sees your unencrypted data or your keys. However, it also means you must implement robust key management practices, including secure storage, rotation, and access control, to maintain compliance and prevent vulnerabilities.

• AWS SDKs: Provide built-in support for client-side encryption using envelope encryption.

• Custom Implementations: Allows integration with on-prem HSMs or external key managers for hybrid architectures.

Advanced Option: For high-security environments, integrate client-side encryption with AWS Encryption SDK and implement data key caching for performance optimization.

How to Enable Encryption

a. SSE-S3

Enable default encryption in the bucket settings. AWS applies AES-256 automatically. Use S3 Object Lock with SSE-S3 for immutable storage in compliance scenarios.

b. SSE-KMS

• Create a Customer Managed Key (CMK) in AWS KMS.

• Configure IAM and bucket policies for controlled access.

• Apply encryption during upload using CLI or SDK:

aws s3 cp file.txt s3://bucket-name/ --sse aws:kms --sse-kms-key-id <key-id>

Enable automatic key rotation and monitor key usage with CloudTrail for compliance audits.

c. SSE-C

Provide your own key in the request header:

aws s3 cp file.txt s3://bucket-name/ --sse-c --sse-c-key <base64-encoded-key>

Implement a secure key distribution mechanism and audit access logs regularly.

Best Practices

• Enforce encryption using bucket policies and AWS Config rules.

• Use SSE-KMS for workloads requiring compliance and auditability.

• Rotate keys periodically and enable multi-region keys for disaster recovery.

• Monitor encryption compliance with AWS Security Hub and CloudTrail.

• For hybrid environments, integrate with AWS PrivateLink for secure KMS access

Conclusion

Encryption in AWS S3 is more than a checkbox—it’s a strategic decision that impacts compliance, security posture, and operational complexity. By leveraging advanced features like SSE-KMS, encryption context, and client-side encryption, you can build a robust, enterprise-grade security model for your cloud workloads.

Reference:

1. Securing Your Data in the Cloud

2. Protecting data with encryption

3. Protecting data with server-side encryption

4. Protecting data by using client-side encryption

Amazon S3 is a highly durable, scalable object storage service that provides 99.999999999% durability by storing data across multiple Availability Zones. However, certain compliance, latency, and disaster recovery requirements demand storing data across different AWS Regions. This is where Cross-Region Replication (CRR) comes in.

CRR enables automatic, asynchronous replication of objects from one S3 bucket to another in a different AWS Region. It ensures business continuity, improves performance for global users, and helps meet regulatory requirements.

Why Use Cross-Region Replication?

According to AWS best practices and industry use cases:

• Compliance: Some regulations require data copies in geographically distant regions.

• Disaster Recovery: Replicating data across regions mitigates risks from regional outages.

• Latency Optimization: Serve global customers faster by storing data closer to them.

• Ownership Override: CRR allows changing object ownership in the destination bucket for access control.

How CRR Works

CRR uses live replication for new objects and S3 Batch Replication for existing objects. Key requirements:

• Both buckets must have versioning enabled.

• An IAM role must grant permissions for replication.

• Objects uploaded before enabling replication are not automatically replicated.

Replication Types:

• Same-Region Replication (SRR): For compliance within a region.

• Cross-Region Replication (CRR): For multi-region backups and disaster recovery.

Advanced Option: Enable Replication Time Control (RTC) for predictable replication within 15 minutes (additional cost).

Step-by-Step Configuration

1. Create Buckets and Enable Versioning

• Create source bucket in primary region.

• Enable versioning via Properties → Bucket Versioning.

• Create destination bucket in secondary region with versioning enabled.

2. Configure Replication Rule (source bucket)

• Navigate to Management → Replication rules → Create replication rule.

• Scope: Entire bucket or filtered by prefix/tags.

• Destination: Select destination bucket.

• IAM Role: Assign or create a role with permissions:

IAM Replication Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetReplicationConfiguration",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::source-br"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObjectVersionForReplication",
                "s3:GetObjectVersionAcl",
                "s3:GetObjectVersionTagging"
            ],
            "Resource": [
                "arn:aws:s3:::source-br/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ReplicateObject",
                "s3:ReplicateDelete",
                "s3:ReplicateTags"
            ],
            "Resource": "arn:aws:s3:::target-br/*"
        }
    ]
}

There is an advance option for S3 objects to be replicated within 15 minutes, you’ll need to tick the “Replication Time Control (RTC)” box. Please note that this feature incurs additional charges.

3. Test Replication

• Upload a new file to the source bucket.

• Verify replication in the destination bucket.

• Note: Existing objects require S3 Batch Replication.

Now validate if the uploaded files are replicated to our target bucket.

Advanced Scenarios

Encrypted Objects

• By default, KMS-encrypted objects are not replicated.

• Edit replication rule → Enable Replicate objects encrypted with AWS KMS.

• Specify destination KMS key.

Folder-Based Replication

• Use prefix filter (e.g., crr-test/) to replicate only specific folders.

Tag-Based Replication

• Create rule with Tag filter (e.g., Key=replicate, Value=yes).

• Only tagged objects replicate.

Delete Marker Replication

• By default, deletions are not replicated.

• Enable Delete marker replication if required.

Best Practices & Considerations

• Cost: Replication incurs storage and request charges in both regions.

• Monitoring: Use Amazon S3 Replication metrics, CloudWatch, and EventBridge for alerts.

• Multi-Region Access Points: Combine CRR with Multi-Region Access Points for global applications.

• Security: Apply least-privilege IAM roles and enable encryption for compliance.

Conclusion

Amazon S3 CRR is a powerful feature for compliance, disaster recovery, and performance optimization. By leveraging versioning, replication rules, and advanced filters, you can design robust multi-region backup strategies.

Reference

1. Replicating objects within and across Regions

2. Setting up permissions for live replication

3. Replicating existing objects with Batch Replication

4. Using S3 Replication metrics

Hybrid and multicloud strategies are now the norm for enterprises seeking agility, resilience, and compliance. Yet, managing infrastructure that spans AWS, on-premises data centres, and even other public clouds introduces operational complexity and security challenges. AWS Systems Manager (SSM) provides a unified, scalable solution for automating, monitoring, and securing workloads across these diverse environments.

Why AWS Systems Manager for Hybrid Environments?

AWS SSM enables organisations to treat on-premises servers and VMs, whether Windows or Linux, just like EC2 instances. By registering these machines as “managed nodes”, you can apply consistent patching, configuration, and compliance policies across your entire estate. This approach eliminates silos, reduces manual effort, and enhances security posture.

Key benefits include:

• Centralised management: One console for AWS, on-premises, and multicloud resources.

• Consistent automation: Use the same SSM documents, maintenance windows, and automation scripts everywhere.

• Unified compliance: Generate fleet-wide patch and compliance reports, regardless of location.

• Secure operations: All actions are logged in AWS CloudTrail, and access is governed by IAM.

Architecture Overview

A robust hybrid SSM deployment typically includes:

• SSM Agent: Installed on all managed nodes (EC2, on-premises, or other cloud VMs).

• Private Connectivity: On-premises servers connect to AWS via Direct Connect or VPN, with VPC endpoints for SSM, S3, and related services to ensure no traffic traverses the public internet.

• IAM Roles: Fine-grained roles for hybrid activations, with least-privilege permissions.

• Patch Manager: Automates patch scanning, deployment, and compliance reporting.

• CloudWatch & CloudTrail: For monitoring, alerting, and auditing.

Deep Dive: Network Architecture, VPC Endpoints, and Patch Source Requirements

Ensuring Secure, Private Connectivity with VPC Endpoints

In a well-architected hybrid SSM deployment, all communication between on-premises servers and AWS Systems Manager services must traverse private VPC endpoints—never the public internet. This is essential for both security and compliance, especially in regulated industries.

Centralising Endpoints in the Network Account

Within an AWS Organisation, it is best practice to centralise all VPC endpoints in a dedicated network account. This approach simplifies management, auditing, and ensures consistent security controls across all environments (Dev, Test, Prod). All on-premises and cloud-based managed nodes should route their SSM, S3, and related traffic through these endpoints.

VPC Endpoint Policies: Restricting Access to Patch Repositories

To enforce that all patching traffic flows exclusively through VPC endpoints, you must apply strict endpoint policies. Below is an example S3 VPC endpoint policy that only allows access to the patch repository bucket from the endpoint itself:

SSM and Related Endpoint Policies

For SSM, SSM Messages, and EC2 Messages endpoints, use endpoint policies that restrict access to only the required AWS services and resources. Example:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "",
      "Action": "ssm:SendCommand",
      "Resource": ""
    }
  ]
}

Best practice:

• Limit actions and resources as tightly as possible.

• Regularly review endpoint policies for least-privilege access.

Patch Source Requirements: WSUS and Satellite Servers

While AWS Patch Manager orchestrates patching, the actual patch binaries for on-premises servers must still be sourced from local repositories:

• Windows Servers:\ Require connectivity to a local WSUS (Windows Server Update Services) server. This ensures that Windows updates are distributed efficiently and in compliance with internal policies.\ Note: Direct internet access to Microsoft Update is not recommended for enterprise environments.

• Linux Servers (e.g., Red Hat):\ Must have access to a Red Hat Satellite server or equivalent local repository. This is critical for environments with restricted internet access and for maintaining control over which updates are approved and deployed.

Why Local Patch Sources Are Mandatory

• Bandwidth Efficiency: Downloading patches once to a local repository and distributing internally reduces WAN usage and speeds up patch deployment.

• Compliance and Control: Organisations can vet and approve patches before they are made available to production systems.

• Security: Prevents unmanaged or unapproved updates from being installed, and avoids exposing servers to the public internet

Advanced Setup: Hybrid Activation and Agent Configuration

1. Hybrid Activation

Hybrid activation is the process of registering non-EC2 machines (on-premises or other clouds) as managed nodes in SSM. This involves:

• Creating an activation in the SSM console, specifying the instance limit, IAM role, and expiry.

• Installing the SSM Agent on each server and registering it using the activation code and ID.

• For large estates, automate agent deployment and registration using configuration management tools (e.g., Ansible, Chef, or PowerShell DSC).

2. Agent Configuration for Secure Connectivity

Update the amazon-ssm-agent.json file on each managed node to:

• Point to VPC endpoints for SSM, S3, and EC2 messages.

• Disable public internet access.

• Configure logging and telemetry to CloudWatch or S3 for centralised monitoring.

Example configuration snippet:

{
  "Ssm": { "Endpoint": "ssm.region.amazonaws.com" },
  "Mds": { "Endpoint": "ec2messages.region.amazonaws.com" },
  "Mgs": { "Endpoint": "ssmmessages.region.amazonaws.com" },
  "S3": { "Endpoint": "PATCH-LOG-BUCKET.s3-region.amazonaws.com" }
}

3. IAM and Security

Patch Manager, a feature of SSM, automates patching for both operating systems and supported applications (limited to Microsoft updates on Windows). It supports:

• Patch Baselines: Define which patches are approved, auto-approve rules, and exceptions.

• Patch Groups: Use tags to group servers for targeted patching.

• Maintenance Windows: Schedule patching to minimise business impact.

• Compliance Reporting: Generate detailed reports on patch status and compliance.

4. Advanced Patch Orchestration

• Integrate Patch Manager with automation pipelines (e.g., Jenkins, GitHub Actions) for CI/CD-driven patching.

• Use custom SSM documents to handle complex patching scenarios, such as pre- and post-patch validation, or application-aware patching.

• For multicloud, ensure SSM Agent is supported and network connectivity is secured for each cloud provider.

Monitoring, Auditing, and Compliance

• CloudWatch: Collect metrics and logs from all managed nodes, set up alarms for patch failures or compliance drift.

• CloudTrail: Audit all SSM actions, including who initiated patching or configuration changes.

• Athena & QuickSight: Query and visualise compliance data at scale for audits and executive reporting.

Best Practices and Lessons Learned

• Segregate environments: Use separate activations and IAM roles for Dev, Test, and Prod.

• Automate everything: From agent deployment to compliance reporting, leverage automation to reduce manual errors.

• Test patching in lower environments before rolling out to production.

• Monitor agent health: Regularly check that all managed nodes are online and reporting.

• Document and review: Maintain clear documentation of your hybrid SSM setup, and periodically review IAM policies and network configurations.

End-to-End Patch Flow in a Hybrid Environment

1. Patch Manager schedules a scan or deployment via SSM.

2. SSM Agent on each managed node receives instructions via the VPC endpoint.

3. On-premises Windows servers fetch updates from WSUS; Linux servers fetch from Satellite.

4. Patch status and compliance data are sent back to AWS via the VPC endpoint.

5. All logs and compliance reports are centralised in S3, accessible only via the endpoint.

Security and Audit Considerations

• All patching and SSM traffic must be logged and auditable via CloudTrail and VPC Flow Logs.

• No direct internet access should be permitted from managed nodes for patching.

• IAM roles and endpoint policies must be reviewed regularly to ensure least-privilege.

Conclusion

AWS Systems Manager, when properly architected, delivers enterprise-grade automation, compliance, and security across hybrid and multicloud estates. By enforcing strict VPC endpoint policies, mandating WSUS and Satellite servers for on-premises patch sources, and following advanced setup practices, such as private connectivity, robust IAM, and automated patch orchestration, organisations can achieve operational excellence and regulatory compliance, while reducing risk and manual effort.

Overview of AFT

AFT is a Terraform-based orchestration framework that automates the provisioning and customization of AWS accounts in a Control Tower landing zone. It enables platform teams to adopt a GitOps-style workflow, where account lifecycle operations are managed through version-controlled repositories.

Key Benefits:

• Terraform-native provisioning with support for Terraform Cloud, Enterprise, and OSS.

• Governance integration with AWS Control Tower.

• Customizations applied globally or per-account.

• Git-based workflows via AWS CodeCommit or external VCS providers.

Architecture

AFT operates in a dedicated AFT management account, separate from the Control Tower management account. The architecture includes:

1. Account Request Pipeline: Users submit Terraform files to a Git repo.

2. Provisioning Engine: AFT provisions accounts via Control Tower.

3. Global Customizations: Common configurations applied to all accounts.

4. Account-Specific Customizations: Tailored settings based on metadata.

5. Audit and Traceability: CloudWatch Logs and unique tokens for tracking.

This modular design ensures scalability, traceability, and compliance across large AWS environments.

Deployment Models

AFT supports both single-account and multi-account provisioning:

• Single Account: Ideal for testing or small teams.

• Multiple Accounts: Supports concurrent provisioning for enterprise-scale environments.

Prerequisites:

• AWS Control Tower landing zone.

• AFT management account.

• Terraform runtime environment.

• Git repository (CodeCommit or external).

• Optional configurations: VPC, encryption, tagging, compute resources.

Required Roles and Permissions

AFT requires specific IAM roles to operate securely:

• AFT Management Role: Deployed in the AFT management account to orchestrate pipelines.

• Account Customization Role: Assumes permissions in target accounts for applying configurations.

• Terraform Execution Role: Manages Terraform operations securely.

• Cross-Account Access Roles: Enable customization and logging across accounts.

These roles should follow least privilege principles and be monitored via AWS CloudTrail.

Customizations and Data Protection

AFT supports global and account-specific customizations using Terraform modules. Examples include:

• Security Baselines: GuardDuty, IAM policies, SCPs.

• Networking: VPC setup, Transit Gateway attachments.

• Monitoring: CloudWatch alarms, dashboards.

• Data Protection:

  • KMS Encryption: Encrypt logs, SNS topics, and other resources.

  • CloudTrail Integration: Organization-wide logging of data events.

  • Default VPC Removal: Enforce custom networking standards.

Customizations are version-controlled and auditable, ensuring compliance with data protection regulations.

Operational Metrics and Monitoring

AFT provides visibility into operations via:

• CloudWatch Logs: Track provisioning and customization events.

• Step Functions: Visualize workflow execution.

• Custom Metrics:

  • Account provisioning success/failure rates.

  • Customization execution times.

  • Drift detection and reconciliation.

These metrics help platform teams optimize performance and troubleshoot issues proactively.

Updating and Removing Accounts

Updating Existing Accounts

AFT supports post-provisioning updates via manual customization requests. This allows teams to:

• Apply new policies.

• Update networking.

• Modify tagging strategies.

All updates are logged and traceable.

Removing Accounts

While AFT does not directly delete accounts, it supports:

• Decommissioning workflows: Custom Terraform modules to clean up resources.

• Tagging for retirement: Mark accounts for manual review and deletion.

• Audit Trails: Ensure all removal actions are logged.

Account removal should follow organizational policies and AWS best practices.

Feature Options

AFT offers several optional features to enhance governance and cost optimization :

• CloudTrail Logging: Enable organization-level logging of data events.

• Default VPC Deletion: Remove default VPCs to enforce custom networking standards.

• Enterprise Support Enrollment: Automatically enroll accounts into AWS Enterprise Support.

• KMS Encryption: Apply customer-managed keys to CloudWatch logs and SNS topics.

• Custom Tags: Add metadata for cost allocation and resource tracking.

These features can be toggled via Terraform variables during deployment or updated later.

Conclusion

AWS Control Tower Account Factory for Terraform empowers platform teams to manage AWS accounts at scale with automation, governance, and flexibility. From provisioning to customization, monitoring, and decommissioning, AFT provides a robust framework that integrates seamlessly with modern DevOps workflows.

Ref: https://docs.aws.amazon.com/controltower/latest/userguide/aft-architecture.html

As businesses increasingly rely on data lakes for storing massive volumes of information, the need for structured storage within Amazon S3 has grown. Enter AWS S3 Tables—a revolutionary feature that enhances S3’s object storage capabilities by introducing table-based data organization, optimized for analytics workloads.

Unlike traditional S3 buckets, AWS S3 Tables enable structured querying using Apache Iceberg, providing an efficient, scalable, and transactional approach to managing structured data in the cloud.S3 Table Buckets

Key Features of AWS S3 Tables

AWS S3 Tables come packed with innovations designed for high-performance analytics:

1. Native Apache Iceberg Support

AWS S3 Tables fully integrate with Apache Iceberg, a format that supports SQL-like query optimizations, transactional consistency, and schema evolution—ensuring flexible and efficient data management.

2. Automatic Optimization & Maintenance

Unlike manually managed data lakes, S3 Tables provide automatic compaction and metadata management, improving query speeds while reducing storage costs.

3. Schema Evolution for Flexibility

Data structures often change over time. S3 Tables support schema evolution, meaning fields can be added or modified without requiring complex migrations.

4. Partitioning for Faster Query Execution

Partitioning helps accelerate queries by reducing data scan sizes. AWS S3 Tables automatically handle partitioned data to enhance query performance.

5. High Transaction Throughput

AWS S3 Tables deliver up to 10x higher transactions per second (TPS) compared to unmanaged Iceberg tables—critical for high-volume workloads.

6. Seamless AWS Service Integration

✅ Amazon Athena – Direct SQL queries on S3 Tables.

✅ Redshift Spectrum – Combining S3 and Redshift for analytics.

✅ AWS Glue – Automated data preparation and cataloging.

7. Use Cases: Where S3 Tables Shine

📌 Data Lakes & Business Intelligence – Enterprises use S3 Tables for structured, high-performance querying within large-scale data lakes.

📌 Transactional Workloads – Retailers and fintech companies leverage S3 Tables for structured transaction storage, ensuring real-time processing.

📌 Machine Learning Pipelines – Data scientists benefit from structured, scalable datasets that streamline feature engineering and model training.

📌 Clickstream & Ad Analytics – Marketing firms track user interactions and campaign performance efficiently using partitioned tables.

8. Comparing AWS S3 Tables vs. Traditional S3 Storage

Conclusion

While standard S3 buckets are great for general storage, AWS S3 Tables bring advanced queryability, transaction support, and efficiency to large-scale data applications.

In the cloud computing environment, particularly on AWS (Amazon Web Services), it is crucial to manage and control costs effectively. One of the primary concerns for organisations and individuals using AWS is ensuring that they do not unintentionally exceed their budget. AWS offers numerous services, and without proper monitoring, costs can easily spiral out of control. This is where AWS CloudWatch Billing Alarms come into play.

A CloudWatch Billing Alarm helps monitor your AWS usage and sends notifications when your costs approach or exceed a set threshold. By configuring these alarms, you gain insights into your usage patterns and can take action to prevent unnecessary expenses. This makes billing alarms an essential tool in cost optimisation and budgeting within AWS.

How It Helps

• Cost Control: AWS operates on a pay-as-you-go pricing model, which, while beneficial, can sometimes lead to unintended overspending. Billing alarms mitigate this risk by providing notifications before you reach your budgetary limits, allowing for informed decision-making and resource management.

• Usage Monitoring: With a multitude of AWS services in operation, keeping a comprehensive track of every resource can be challenging. Billing alarms offer a consolidated overview of your overall usage, facilitating better awareness and helping you avoid surpassing your budgetary constraints.

• Proactive Notifications: These alarms are designed to alert you via email or SMS when your spending approaches or exceeds the designated threshold. This proactive approach empowers you to take immediate action, whether that entails adjusting resource utilisation or revising budgetary parameters, ultimately promoting financial prudence.

• Prevent Unexpected Charges: It is not uncommon for users to overlook unused services that continue to run in the background, accruing charges without their knowledge. Billing alarms play a critical role in identifying these dormant services early, allowing you to eliminate unnecessary costs and streamline your expenditure.

• Support for Scaling: As your utilisation of AWS increases, CloudWatch Billing Alarms become instrumental in tracking cost escalations. They provide essential insights that aid in strategic planning for scaling your infrastructure, ensuring that you can accommodate growth without encountering unwelcome financial surprises.

Step-by-Step Process for Setting Up CloudWatch Billing Alarms

1. Enable Billing Alerts

   Before setting up the billing alarm, we first need to enable billing alerts in the billing preferences. This can be done by accessing the “Billing and Management” dashboard after logging into the AWS Management Console.

   

   

   

   

2. Setup SNS Topic and Subscription

   Move to the Amazon Simple Notification Service (SNS) console and provide the topic name you wish to create.

   

   

   Scroll down the end of the page and click “Create Topic”

   Select the subscription section from the left pane and provide the required protocol and endpoint for the subscription. In this instance, I am using email as the protocol and have provided my email address for the endpoint.

   

   Confirm the subscription and its ready

   

3. Final Step: Create a Billing Alarm

   Move to the CloudWatch console and click on Create Alarm on the Alarm Section.

   

   

   

   

   

   

   

   

   Review and create alarm

   

   

   wait for a while for CloudWatch collect the data and you will see the alarm action enabled.

   

4. Monitoring and Managing the Alarm

   Once the alarm is set up, it will actively monitor your billing. You can view the status of the alarm in the CloudWatch Console under the Alarms section. If triggered, you will receive a notification based on your configured settings. You can also modify or delete the alarm at any time by going back to the Alarms section. But remember you can’t rollback the “CloudWatch Billing Alerts”. Once it enabled, this preference cannot be disabled.

Conclusion

AWS CloudWatch Billing Alarms are a vital tool for anyone using AWS, allowing you to monitor and control costs effectively. By setting up billing alarms, you can ensure you are always aware of your cloud expenditure and avoid exceeding your budget unintentionally. This proactive approach to cost management is particularly important for businesses and individuals using multiple AWS services.

The setup process involves enabling billing alerts, creating a billing alarm in CloudWatch, and configuring notifications via SNS. Once configured, the billing alarm helps keep your cloud expenses under control, sending notifications when thresholds are crossed, helping you to optimise your AWS spending.

Please remember to delete the resources you created if you did it for learning purposes to avoid unnecessary costs on your account.

Amazon RDS creates a storage volume snapshot of your DB instance, backing up the entire instance rather than individual databases. When creating this DB snapshot on a Single-AZ DB instance, there is a brief I/O suspension that can last from a few seconds to a few minutes, depending on the size and class of your DB instance. The time required to create a snapshot varies with the size of your databases. Since the snapshot includes the entire storage volume, the size of files, such as temporary files, also affects the duration of the snapshot creation process.

Snapshots of Amazon RDS volumes are incremental, even though database snapshots function operationally as full backups. There are two types of Amazon RDS snapshots: automated and manual. Automated backups occur daily during the preferred backup window, whereas a manual snapshot can be triggered at any time it is needed. Unlike automated backups, manual snapshots are not subject to the backup retention period and do not expire

Step 1 - Select the database

1. Sign in to the Amazon RDS Console

   Go to the AWS Management Console and log in with your credentials. Then In the console, locate and select RDS from the list of services. In the upper-right corner of the RDS console, select the AWS Region where DB instance located.

   

2. Select the database

   In the left navigation pane of the RDS dashboard, click on Databases. This will display a list of all your RDS instances. Locate and select the database instance from the list.

   

Prepare Snapshot

Manual Snapshot

1. Take Snapshot

   Select Database then go to actions and click Take Snapshot option

   If it is taking the first snapshot, it may take a couple of minutes depending on the size of the database.

   

2. Name it and initiate the snapshot

   For the snapshot name, use the meaning full and easy to recognise the purpose of each snapshot.

   Provide the snapshot name and click on Take Snapshot

   

3. Validate the snapshot

Console automatically move to the RDS Snapshots console. Watch on the snapshot name and the status to see the completion

Snapshot is ready, when the status change to Available.

click on the snapshot and validate the details

You successfully created a RDS manual snapshot.

Automated Snapshot

1. Modify the database configuration

   Select the Database and click Modify

   

2. Configure the preferred backup window

   Scroll down up to the Additional Configuration and set the time under the Backup section

   

   In the next window, select the option when to apply then click on Modify DB instance

   

   You successfully set the automated snapshot(Backup) window

3. Validate the Automated Snapshot settings

   Select the Automated backups section in the left panel (After the scheduled time which set earlier) and find the snapshot form the list.

   

   click on the snapshot and cross check the summary

   

We have successfully configured and created RDS automated and manual snapshots and validated.

Please remember to delete the resources you created if you did it for learning purposes to avoid unnecessary costs on your account.

Amazon RDS offers encryption for DB instances, ensuring that data at rest, including underlying storage, automated backups, read replicas, and snapshots are protected. It employs the industry-standard AES-256 encryption algorithm, which operates transparently with minimal performance impact, requiring no modifications to database client applications. This encryption enhances data security against unauthorized access and helps meet compliance requirements. Additionally, when creating a read replica, it must be encrypted with the same KMS key as the primary instance if they are in the same AWS Region; otherwise, the appropriate regional KMS key should be used.

Walkthrough

1. Sign in to the Amazon RDS Console

   Go to the AWS Management Console and log in with your credentials. Then In the console, locate and select RDS from the list of services. In the upper-right corner of the RDS console, select the AWS Region where you want to create your DB instance.

   

2. Start the Database Creation Process

   In the RDS Console pane, click the Create database button.

   

3. Select Database Creation Method and Choose the Database Engine

   Choose Standard create for more configuration options and Under Engine options*, select* MySQL as the database engine.

   

4. Select the Engine Version and Template

   Scroll down the same page and select the compatible version and select the templates depends your needs.

   

5. Select the Availability and Durability

   Here the option to decide do we need DB Cluster or single node or Multi-AZ DB

   

6. Configure DB Instance Settings

   DB instance identifier*: Enter a unique name for your DB instance.*

   Master username*: Specify a username for the database administrator.*

   Master password*: Create a strong password and confirm it.*

   

7. Configure DB Instance Size

   Choose the DB instance class based on your performance needs (e.g., db.t3.micro for a small instance).

   Set the Storage type and allocate the desired amount of storage.

   

8. Configure Connectivity

   Choose the VPC and Subnet group for your DB instance.

   Set the Public accessibility option to determine if the database should be accessible from the internet.

   Configure the VPC security group to control access to the DB instance.

   

   

9. Additional Configuration

   Select and configure Monitoring options

   Under Database options, you can set the initial database name and other parameters.

   Configure backup, encryption, log exports, maintenance, and deletion protection settings as needed.

   — Here the option to encrypt the database instance and you can only encrypt an Amazon RDS DB instance when you create it, not after the DB instance is created.

   

   

10. Review and Create

    Review all your settings to ensure they are correct.

    Click the Create database button to launch your MySQL DB instance at the end of the page.

    

11. Validate the Database instance

    It will take a few minutes to complete the database creation and launch.

    

12. Validate the Encryption of the DB instance

    Click on the DB identifier

    

    Select the Configuration TAB and look on the Storage panel

    

    Remember :You can't turn off encryption on an encrypted DB instance.

    You can't create an encrypted snapshot of an unencrypted DB instance.

We have successfully created an encrypted AWS RDS DB instance. Please remember to delete the resources you created if you did it for learning purposes to avoid unnecessary costs on your account.

AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs all API calls made within your AWS environment, including those made through the AWS Management Console, AWS SDKs, command-line tools, and other AWS services.

Why is CloudTrail Important?

With CloudTrail, you can keep an eye on and archive account activity linked to actions taken throughout your AWS infrastructure. It may be essential for compliance obligations, security audits, and identifying any strange activity in your account.

Setting Up CloudTrail in a Single Account

Prerequisites

1. Necessary IAM permissions to create CloudTrail (e.g., cloudtrail:CreateTrail).

2. S3 bucket (optional, but necessary if storing logs outside of the default location).

Enable the Trail

1. Navigate to the AWS CloudTrail Console and Click on Create a trail

   

2. Create Trail

   1. In the CloudTrail dashboard, click on "Create trail".

      1. Provide a name for your trail.

         

3. Trail first look

   

4. Configure the Storage.

   1. Click on Edit in the General details section.

      

   2. Select "Use existing S3 Bucket, then click Browse and select the bucket

      

5. Choose Additional Settings (Recommended)

   

   Save Changes.

6. Select the Events ( Management / Data /Insights)

   1. By Default Management events is enabled read and write.

   2. The rest must be manually enable as per the requriements.

      

Best Practices

1. Enable Log File Validation

2. Use Multi-Region Trails

3. Monitor for Anomalies

4. Set Up Alerts

5. Review and Rotate Keys

Conclusion

AWS CloudTrail is a service that logs all API calls made in your AWS environment, providing detailed records of activities across your account. It plays a crucial role in security, compliance, and operational auditing by enabling you to monitor and track actions such as who accessed resources, when, and from where. CloudTrail logs can be stored in an S3 bucket, integrated with CloudWatch for real-time monitoring, and used to trigger automated responses to specific events. This makes it an essential tool for maintaining transparency, ensuring accountability, and responding to potential security incidents in your AWS environment.

Access logs in Elastic Load Balancing is an optional feature, and it comes disabled by default. Once you activate/enable access logs for your load balancer, Elastic Load Balancing captures and stores the logs in the specified Amazon S3 bucket in compressed file format. Disabling access logs can be done at any point in time. For every load balancer node, Elastic Load Balancing generates a log file every 5 minutes. The delivery of logs follows an eventually consistent model. Each log file includes details such as the time of request receipt, client IP addresses, latencies, request paths, and server responses. You must create S3 bucket for access logs before you enable the access logs.

Setup S3 Bucket

• The bucket must be located in the same Region as the load balancer.

• The bucket and the load balancer can be in same or different account.

-> Connect the AWS Console and Open the Amazon S3 console
-> Select Create Bucket

-> Select the region of the bucket
-> Enter the name of the bucket
-> Scroll down
-> Select the default encryption, Amazon S3-managed keys (SSE-S3)
-> Select Create bucket

Attach bucket policy

S3 bucket must have a bucket policy that grants Elastic Load Balancing permission to write the access logs to the bucket.

-> Connect the AWS Console and Open the Amazon S3 console
-> Select your bucket

-> Select Permission tab
-> Select Edit under Bucket policy

-> Replace the account ID mentioned in the principal. This AWS account is managed by AWS and you have to select the one which assigned to each region.
-> Scroll Down and Select Save Changes

Enable and Configure the Access logs

-> Navigate to the Amazon EC2 Console
-> Select Load Balancers from the left navigation pane

-> Select the attribute tab
-> Select Edit under the attributes

-> Scroll down the edit page
-> Enable access logs under Monitoring section
-> Select Browse for selecting the bucket

-> Select the radio button of the bucket
-> Select Choose button on the popup window

-> Select Save Changes

Validation

-> Navigate to Amazon S3 Console
-> Select the Access logs repository bucket
-> Navigate to the test log file Eg: repo-bucket/AWSLogs/aws account ID/ELBAccessLogTestFile

Clean Up

As this is a testing environment, you may not need to retain the AWS resources used for creating this lab. Therefore, delete the AWS resources you allocated to avoid incurring further charges.