Aws Revision

What is AWS?

AWS (Amazon Web Services) is a cloud computing platform by Amazon that provides on-demand IT resources like servers, storage, databases, and more over the internet. You pay only for what you use.


Why do we need AWS?

  1. Cost-Effective: No need to buy expensive hardware; pay only for usage.

  2. Scalable: Easily increase or decrease resources as your needs change.

  3. Global Reach: AWS has data centers worldwide.

  4. Fast Deployment: Launch servers and resources in minutes.


Life Before AWS

  1. Companies bought physical servers.

  2. Needed large data centers to store them.

  3. Paid for maintenance and unused capacity.

  4. Scaling up/down was slow and expensive.


What is an EC2 Instance?

  • EC2 (Elastic Compute Cloud): A virtual server in AWS.

  • It lets you run applications without needing physical hardware.

  • You can choose instance types (CPU, memory, etc.) based on your needs.


Example of EC2 Usage

Imagine you're launching an online store for a seasonal sale.

  • Before AWS:

    • You’d need to buy multiple physical servers to handle the traffic during the sale.

    • After the sale, most of these servers would sit idle, wasting money and space.

    • Setting up and scaling servers would take weeks or months.

  • With AWS:

    • You launch EC2 instances just before the sale, configure them to handle high traffic, and scale up or down as needed during the event.

    • Once the sale is over, you can shut down the extra EC2 instances to save costs.

    • Everything is done quickly, efficiently, and at a lower cost.


Why EC2 is Useful?

  1. Flexible Configurations: Choose resources based on your needs.

  2. Pay-as-You-Go: Only pay while your server is running.

  3. Quick Scaling: Add more servers during high traffic.


Simple Analogy

Think of AWS as renting a car instead of buying one.

  • Before: You’d have to buy a car (physical server), even if you only needed it for a short trip.

  • Now: With AWS (EC2), you rent the car (server) for as long as you need it.

What is Block Storage?

Block Storage stores data in fixed-sized blocks. These blocks are like bricks in a wall — they hold pieces of data that a system puts together to retrieve full files or applications.

Key Components:

  1. Blocks: Small chunks of data, stored individually.

  2. Volume: A collection of blocks that acts as a hard drive for applications or operating systems.

  3. Snapshots: Backups of a block storage volume.

  4. IOPS (Input/Output Operations Per Second): Measures performance of block storage.

  5. Throughput: Measures how much data can be transferred at a time.

Example : Imagine you have a 500 GB hard disk (block storage).

  • The disk is divided into blocks of 512 MB each.

  • This means there are 500 GB ÷ 512 MB ≈ 976 blocks in total on the disk.

Now, suppose you have 2 GB of data to store:

  • Each block can store 512 MB of data.

  • So, 2 GB ÷ 512 MB = 4 blocks are needed to store the 2 GB of data.

In this example, 4 blocks (each 512 MB) are used out of the total 976 blocks on the disk, leaving the remaining blocks available for more data.

AWS Block Storage

AWS provides block storage services to attach storage volumes to virtual servers (EC2 instances). These storage solutions are scalable, reliable, and designed for various use cases.


Types of AWS Block Storage

1. Amazon EBS (Elastic Block Store)

  • Persistent block storage for EC2 instances.

  • Data remains even after the EC2 instance is stopped or terminated.

  • Use Case: Databases, enterprise applications.

2. Amazon EFS (Elastic File System)

  • Managed file storage that can be shared across multiple EC2 instances.

  • Automatically scales based on usage.

  • Use Case: Shared file systems for multiple servers.

3. Ephemeral Storage (Instance Store or Temporary Storage)

  • Non-persistent storage directly attached to an EC2 instance.

  • Data is lost if the instance is stopped or terminated.

  • Use Case: Temporary files or caches.


Types of EBS

1. SSD-Based Volumes (Solid State Drives)

  • Designed for transactional workloads like databases and web servers.

    • gp2 (General Purpose SSD):

      • Balances price and performance.

      • Min & Max Vol : 1 GB,16 TB | Min IOPS: 100 | Max IOPS: 16,000 | Throughput: Up to 250 MiB/s.

    • io1 (Provisioned IOPS SSD):

      • High performance for I/O-intensive workloads.

      • Min & Max Vol : 4 GB,16 TB | Min IOPS: 100 | Max IOPS: 64,000 | Throughput: Up to 1,000 MiB/s.

    • Similarly, we also have gp3 , io2 ,etc.

2. HDD-Based Volumes (Hard Disk Drives)

  • Ideal for sequential workloads like big data or log processing.

    • st1 (Throughput Optimized HDD):

      • For frequently accessed, large datasets.

      • Min & Max Vol : 500 GB,16 TB | Min IOPS: 40 | Max IOPS: 500 | Throughput: Up to 500 MiB/s.

    • sc1 (Cold HDD):

      • For infrequently accessed data.

      • Min & Max Vol : 500 GB,16 TB | Min IOPS: 12 | Max IOPS: 250 | Throughput: Up to 250 MiB/s.

3. Magnetic Disk (Deprecated):

  • Older generation, now replaced by st1/sc1 for cost efficiency.

  • Min & Max Vol : 1 GB,1 TB | IOPS: N/A | Throughput: N/A.

NOTE : SSD (Solid State Drive) is generally much faster than HDD (Hard Disk Drive) due to fundamental differences in their design and technology. SSDs use flash memory to store data, so there are no spinning disks or moving read/write heads like in an HDD. This allows SSDs to access data almost instantly.

Analogy: Think of an SSD as a super-fast sports car and an HDD as a reliable but slower truck. The car (SSD) gets you to your destination quickly, but the truck (HDD) can carry more load at a lower cost.

Real-World Example

  • EBS: A startup runs a MySQL database on an EC2 instance using gp2 for fast reads/writes.

  • EFS: A media company stores videos on EFS, allowing multiple EC2 instances to process files simultaneously.

  • Ephemeral Storage: A gaming app uses instance storage for caching player session data, as it doesn’t need to be stored permanently.

The below diagram briefly summarizes the content we discusses above :

We get this while creating an ec2 instance :

On creating 4 ec2 instances in my AWS Free tier account , I observed something related to volumes :

Now , suppose if we delete one of the four ec2 instances like :

Now, if we go back to the Volumes section , we see :

IMPORTANT NOTE : By default, Delete Volume on Termination is set to Yes for the root volume of an EC2 instance. This means the root volume is automatically deleted when the instance is terminated. However, you can change this behavior during the instance creation.

During instance creation :

Suppose I create a new ec2 instance named “try” in which Delete on termination is set to “No” .

So, for 4 instances , we have 4 volumes :

Now , if we terminate the ec2 instance named “try” :

Even on terminating the ec2 instance “try” , we see that its volume still exists (this is because during its creation , we set Delete Volume on Termination to “No” ) :

CONCLUSION :

  • If you require data on a volume to persist after even an instance is terminated, then ensure that the "Delete on Termination" option is set to No for that volume.

  • Also, to avoid orphaned volumes and potential charges, ensure that the option is set to Yes if the volume is no longer needed post-termination.

Diagram explanation :

When an EC2 instance is created with an 8GB root volume, an 8GB block of storage is allocated in the AWS Storage Area (specifically, Elastic Block Store or EBS). If the Delete on Termination option is set to Yes (default for root volumes), the root volume will automatically be deleted when the instance is terminated

However, if Delete on Termination is set to No, the volume will persist even after the instance is terminated. In this case, the volume remains available in the AWS Storage Area and can be manually attached to another EC2 instance as needed.

Non-root volumes:

A non-root volume is an additional EBS volume that is attached to an EC2 instance apart from its root volume.

  • The root volume contains the operating system and is created by default when an instance is launched.

  • Non-root volumes, on the other hand, are optional and are primarily used to store additional data like application files, logs, databases, etc.

How to Create and Attach a Non-Root Volume to an EC2 Instance :

  • Configure the volume:

    • Size: Specify the size (e.g., 5 GiB).

    • Volume Type: Choose the desired type (e.g., gp3 for general-purpose SSD).

    • Availability Zone: Ensure the availability zone matches the zone of the EC2 instance to which you want to attach the volume.

  • Click Create Volume.

The volume got created :

We can attach only that volume to an ec2 instance whose volume state is “Available”.

  • Click Actions > Attach Volume.

  • Select the instance you want to attach the volume to from the Instance dropdown.

  • Specify the device name (e.g., /dev/xvdbz). AWS will suggest a name automatically.

  • Click Attach Volume.

Now, we can see below that the Volume state changed from Available to In-use on attaching it with the EC2 instance.

COMPARISON :

  1. Before attaching any volume :

  1. After attaching a volume :

NOTE : 1) lsblk Command:

Purpose: Lists all block storage devices attached to your system in a tree-like format.

  1. fdisk -l Command:

Purpose: Displays detailed information about the disk layout.

It is important to Detach a Volume Before Deleting It :

Upon detaching the volumes , we see that their volume state changed from In-use to Available .

Then , we can delete the undesirable volumes :

The volumes get deleted :

How to increase the Root Volume size ?

  • Locate the Root Volume:

    • Under the Elastic Block Store section, select Volumes.

    • Identify the root volume of your instance.

  • Modify the Volume:

    • Select the root volume and click Actions > Modify Volume.

  • In the Modify Volume dialog:

    • Increase the size of the volume (e.g., from 8 GiB to 12 GiB).

    • Click Modify and confirm the changes.

  • Wait for the Update:

    • The status of the volume will show as Modifying , then optimizing. Wait until the status changes back to In Use.

We can see above that the size increased from 8 to 12 GiB .

Log in to the Instance and check the Current Disk Size :

We see above that the size got changed as per our requirement. If by any chance , the changes don’t get reflected upon connecting to the instance , then :

  • If you are using the default ext4 file system, extend it with the following command:

      sudo resize2fs /dev/xvda1
    
  • If you’re using xfs (common for Amazon Linux 2), use:

      sudo xfs_growfs /
    
  • Then Verify the New Disk Space:

    •       df -h
      

NOTE:

xvda is the entire disk. The disk (xvda) is divided into the following partitions:

  • xvda1 is your main OS partition.

  • xvda14 and xvda15 are used for bootloader and firmware.

  • xvda16 is used for storing boot-related files.

Understanding Size, IOPS, and Throughput for AWS Volumes


Relation Between Size and IOPS (for gp2 Volumes)

  • IOPS (Input/Output Operations Per Second): Measures how fast the storage can handle read/write operations.

  • gp2 (General Purpose SSD) has a direct relationship between size and IOPS:

    • 1 GiB to 33.3 GiB: IOPS = 100 (fixed baseline).

    • Beyond 33.3 GiB: For every 1 GiB increase in size, IOPS increases by 3.

Example:

  • Maximum IOPS:

  • gp2 supports up to 16,000 IOPS.

  • At 5,334 GiB, IOPS caps at 16,000.

  • Any size above 5,334 GiB will still provide 16,000 IOPS.

Burst IOPS (for gp2)

  • Burst IOPS = Temporary higher performance beyond the baseline IOPS.

  • Burst rate = 3,000 IOPS maximum.

Accumulation of Unused IOPS:

  • If your volume isn’t fully using its baseline IOPS, the unused capacity accumulates.

    • Example: Suppose we need 500 GiB volume for some work. By default, for 500 GiB size, we get 1500 IOPS :

      • Baseline = 1,500 IOPS; usage = 1,200 IOPS → 300 unused IOPS are saved.

      • If usage = 1,300 IOPS → 200 unused IOPS are saved. These saved IOPS get accumulated.

  • However, once accumulated IOPS reach 3,000, no more IOPS are added.

Understanding st1 (Throughput Optimized HDD)

  • Unlike SSDs, IOPS is not a fixed metric for st1 volumes.

    • Throughput (data transfer speed) is the key performance metric.
  • Throughput:

    • Baseline = 40 MB/s per TB.

    • Example:

      • Size = 500 GiB (0.5 TB) → Throughput = 0.5 × 40 = 20 MB/s.

      • Burst throughput is also possible for st1, allowing temporary higher speeds based on workload.

      • 123 MiB/s: It means that the volume can handle up to 123 MiB/s for short durations if it has sufficient burst credits. However, note that 123 MiB/s is not the universal burst maximum for st1 volumes—the maximum burst throughput for any st1 volume is 250 MiB/s, but smaller volumes might have specific limits based on accumulated credits and usage patterns.

Choosing Amazon Volumes Based on Price Calculation

Amazon provides different types of storage volumes, each with varying prices and performance. The most commonly used ones are:

  • gp2/gp3 (General Purpose SSD): Good for most workloads.

  • io1/io2 (Provisioned IOPS SSD): For high-performance applications like databases.

  • st1 (Throughput-Optimized HDD): For large-scale, sequential data like big data analytics.

  • sc1 (Cold HDD): For infrequently accessed data like backups.

Example - 1 :

You need 500 GiB of storage for a medium-performance web server.

  • gp2: $0.10 per GiB-month + IOPS included.

    • Cost: 500×0.10=50500 \times 0.10 = 50500×0.10=50 USD/month.
  • io1: $0.125 per GiB-month + $0.065 per provisioned IOPS/month.

    • If you need 1,000 IOPS:

    • Cost: (500×0.125)+(1000×0.065)=62.5+65=127.5(500 \times 0.125) + (1000 \times 0.065) = 62.5 + 65 = 127.5(500×0.125)+(1000×0.065)=62.5+65=127.5 USD/month.

Based on cost, gp2 is a better choice unless you need higher performance.

Example-2:

You have a choice between:

  • 500 GiB (gp2) for $50/month.

  • 1,000 GiB (gp2) for $100/month.

If your workload demands higher IOPS, the 1,000 GiB volume gives you more performance for double the cost. Moreover, cost-wise for the same IOPS (1000), we see : $100/m for gp2 and $127.5/m for io1.

Using RAID 0 for Certain Scenarios:

RAID 0 (Striping):

  • Combines multiple volumes into a single large volume.

  • Improves performance by splitting I/O operations across volumes.

  • No redundancy: If one volume fails, all data is lost.

When to Use RAID 0?

  • High performance is critical.

  • Data loss is acceptable (e.g., temporary data, caches).

Example:

You have two st1 volumes of 500 GiB each. Individually, each provides:

  • Throughput: 40 MiB/s per TB.

With RAID 0:

  • Combined size: 1,000 GiB.

  • Combined throughput: 40×2=8040 \times 2 = 8040×2=80 MiB/s.

This setup is cost-effective for workloads like big data analysis, where performance matters more than durability.

Real-Life Decision-Making

Scenario 1: Hosting a Website

  • Requirement: 100 GiB storage, moderate performance.

  • Choice: gp2, as it provides sufficient performance at a low cost.

Scenario 2: Running a Database

  • Requirement: 500 GiB storage, high performance.

  • Choice: io1, as it allows custom IOPS (e.g., 5,000).

Scenario 3: Big Data Analytics

  • Requirement: 2 TiB storage, high throughput.

  • Choice: st1 in RAID 0 for increased throughput (e.g., 4 x 500 GiB).

Reducing EBS Volume Size:

Reducing the size of an Amazon EBS volume directly is not supported by AWS, since the size of a volume can only be increased, not decreased.

However, there are workarounds for reducing the volume size for both root volumes and non-root volumes.

Steps for Reducing EBS Volume Size


For Root Volumes (Operating System Disks):

Reducing the size of a root volume involves creating a smaller volume from a snapshot of the original volume. Here's how:

1. Create a Snapshot of the Root Volume

  • Open the AWS Management Console.

  • Go to EC2 > Volumes.

  • Select the root volume you want to resize.

  • Click Actions > Create Snapshot.

  • Provide a description and create the snapshot.

2. Launch a Temporary EC2 Instance

  • Start a temporary instance in the same Availability Zone.

  • Attach the snapshot to this instance as a secondary volume.

3. Shrink the Filesystem (Optional)

  • Log in to the temporary instance using SSH.

  • Shrink the filesystem of the attached volume using tools like resize2fs (Linux) or Disk Management (Windows).

  • For example:

      sudo resize2fs /dev/xvdf1 10G
    

4. Create a New, Smaller Volume

  • Go to EC2 > Snapshots.

  • Select the snapshot you created.

  • Click Actions > Create Volume.

  • Specify the smaller size for the volume and create it.

5. Replace the Root Volume

  • Stop the original EC2 instance.

  • Detach the original root volume.

  • Attach the new smaller volume as the root volume (/dev/xvda).

  • Start the instance.


For Manually Created (Non-Root) Volumes:

For non-root volumes, the process is similar but simpler:

1. Create a Snapshot

  • Go to EC2 > Volumes.

  • Select the volume.

  • Click Actions > Create Snapshot.

2. Create a New Smaller Volume

  • Go to EC2 > Snapshots.

  • Select the snapshot.

  • Click Actions > Create Volume.

  • Enter the desired smaller size.

3. Attach the New Volume

  • Detach the original volume from the instance.

  • Attach the new smaller volume to the instance.

  • Update the mount points if necessary.

How To Activate and Deactivate MFA on AWS root Account ?

At first, we will go the Security credentials option :

Next, we will go to “ Assign MFA “ :

Selecting the type of MFA that we require :

Suppose , I select for Authenticator app ( and name it “Microsoft-Authenticator”)

Suppose , I have the Microsoft-Authenticator app on my phone . I need to scan the QR code like below and, then enter the OTPs which I get on my authenticator app:

This way , MFA is successfully enabled.

So, now if we login for the Root Account ; apart from the credentials like email-id , password and captcha , we will also need to put the OTP which we will receive in our authenticator app :

If we want to deactivate MFA , we can simply remove it like below :

Manage Access Secret Key:

The Access Key and Secret Key in AWS are part of the authentication mechanism that allows programmatic access to AWS services.

The usual way to access any AWS service is to access via AWS Console after logging in , as shown below:

But if we want to access the above services via AWS CLI , then the usual login credentials won’t help much. For that , we need Access and Secret keys.

What Are Access and Secret Keys?

  • Access Key: A unique identifier for the root user or an IAM user.

  • Secret Key: A confidential key paired with the Access Key, used to sign requests to AWS services.

Together, they are used for programmatic access via the AWS CLI, SDKs, or APIs to interact with AWS resources.

Practical :

Now , let us try to make use of the access keys in a ubuntu VM :

First , we need to install the aws cli with the command sudo apt install awscli and then , we shall use the command : aws configure

Now, if we want , we can deactivate and delete the access keys , like:

What is IAM in AWS?

IAM (Identity and Access Management) in AWS is a service that helps you securely control access to your AWS resources. It allows you to manage who (identity) has access to what (permissions) within your AWS account.

Key Concepts of IAM

1. Users

  • Represents an individual person or service that needs access to AWS.

  • Example: A developer who needs access to the EC2 service.

2. Groups

  • A collection of users with similar permissions.

  • Example: A "Developers" group where all members can launch and manage EC2 instances.

3. Policies

  • Documents that define permissions. They specify what actions are allowed or denied.

  • Example: A policy that allows reading data from a specific S3 bucket.

4. Roles

  • Temporary credentials for applications or services to access AWS resources.

  • Example: A Lambda function that needs access to a DynamoDB table.

Why IAM when we already have root?
The root user has unrestricted access to your entire AWS account, making it risky to use for daily tasks. IAM allows you to create users with specific permissions, reducing the risk of accidental or unauthorized changes.

Example: Instead of giving a developer full access (root), you use IAM to let them only manage EC2 instances without touching billing or S3.

PRACTICAL:

Let me now create an IAM user using my root account :

This way , the IAM user is being created :

Click the mentioned Console sign-in URL and then , enter the User name and Console Password:

Change the Old Password to a New Password:

After Logging in as an IAM user ,since we only have the ec2readonly permission; hence, we can see the instances but can’t connect to them :

We can delete the user if no more required:

Creating an IAM Policy Using a JSON Template

An IAM policy is a document (written in JSON) that defines what actions are allowed or denied for specific AWS resources.

Why Create Policies Using JSON?

  1. JSON gives precise control over permissions.

  2. You can customize permissions to suit specific needs.


Steps to Create a Policy Using a JSON Template

Scenario Example:

You want to allow a user to only start, stop, or describe EC2 instances.


1. Define Your Policy in JSON

This JSON template allows user to start, stop, or describe EC2 instances :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "*"
        }
    ]
}

2. Go to the AWS Management Console

  1. Open the IAM Console.

  2. Navigate to Policies > Create Policy.

  3. Switch to the JSON Editor.


3. Paste the JSON Template

  • Copy and paste the JSON template into the editor.

  • Click Next: Tags (optional step to add tags).

  • Click Next: Review.


4. Name Your Policy

  • Enter a name like ec2startandstop

  • Review the permissions.

  • Click Create Policy.


5. Attach the Policy

  • Go to Users or Groups.

  • Select the user or group that needs this policy.

  • Attach the ec2startandstop .


Now , we see that the IAM user kishaloy can stop ec2 instances :

Concept of IAM Group and IAM Role :-

1. IAM Group:

  • Definition: A collection of IAM users. Permissions applied to the group are inherited by all users in it.

  • Use Case: To manage permissions for multiple users easily.

Real-Life Practical Example:

  1. You are managing a team with three developers: Alice, Bob, and Charlie.

  2. All developers need EC2 full access to start and stop instances.

  3. Instead of attaching policies to each user, you:

    • Create an IAM Group named Developers.

    • Attach the policy AmazonEC2FullAccess to the Developers group.

    • Add Alice, Bob, and Charlie to the group.

Result: All three developers inherit the AmazonEC2FullAccess permission from the group.

PRACTICAL: Suppose I’ve an IAM user named “Bob_Biswas” :

Currently, the user Bob_Biswas only has one Permission :

Let me now create a group named “Developers” with the permission “AmazonEC2FullAccess“ and attach that group to the user “Bob-Biswas” , then we get :

Now, we see that the user Bob_Biswas has two permissions (earlier it had only one as shown above) :

So now upon logging in as the IAM user Bob_Biswas , we can even start ec2 instances :


2. IAM Role:

  • Definition: Temporary access with specific permissions that a user, application, or AWS service can assume. Roles do not belong to any user but can be "assumed."

  • Use Case: When services or applications need permissions to perform actions on your AWS account.

Real-Life Practical Example:

  1. Scenario: An application running on an EC2 instance needs to upload files to an S3 bucket.

  2. Steps:

    • Create an IAM Role named EC2-S3-Access.

    • Attach the policy AmazonS3FullAccess to this role.

    • Assign the role EC2-S3-Access to the EC2 instance when launching it.

Result:

  • The EC2 instance now has temporary access to upload files to the S3 bucket without needing permanent credentials.

PRACTICAL: Goal: Allow an EC2 instance to upload files to an S3 bucket.

  1. Prepare the Environment:

    • Create an S3 Bucket:

      • Go to the S3 Service.

      • Click Create bucket and give it a name (e.g., my-demo-bucket).

  2. Create an IAM Role:

    • Go to IAM > Roles.

    • Click Create role.

    • Choose Trusted Entity:

      • Select AWS Service and choose EC2.

      • Click Next.

  3. Attach a Policy to the Role:

    • Search for AmazonS3FullAccess.

    • Select the policy, then click Next.

    • Name the role: EC2-S3-Access.

    • Click Create role.

  4. Assign the Role to an EC2 Instance:

    • Launch a new EC2 instance or use an existing one.

    • We can modify an existing ec2 instance like this :

    • Similarly while creating an ec2 instance (let’s name it as “trial”), we can do like :

      • Under IAM role, select EC2-S3-Access.

    • Complete the launch process.

  5. Test the Role:

    • SSH into the existing EC2 instance

    • Upload a file to S3

        echo "Hello, AWS!" > test-file.txt
        aws s3 cp test-file.txt s3://my-example-bucket69/
      
    • Verify the file is in the S3 bucket :

  • Similarly, SSH into the newly created EC2 instance

  • Upload a file to S3

  • Final Outcome :

AWS CLI

AWS CLI (Command Line Interface) lets you manage AWS services using simple commands from a terminal, making it faster and more efficient than using the web console. It's important for automating tasks, scripting, and handling large-scale operations in AWS.

PRACTICAL:

At first I installed AWS CLI in my Ubuntu VM and then configured it with the help of access keys. Then , I verified its working by describing the instances :

Next , we can use the aws ec2 describe-regions command , which lists all the AWS regions available for your account, helping you identify where you can run resources :

If we want the above data in tabular format then , we can use the option “ --output table” :

How to create a New EC2 Instance using CLI ?

  1. Find the AMI ID for your region (Amazon Machine Image): For example :

     aws ec2 describe-images --filters "Name=name,Values=amzn2-ami-hvm-*-x86_64-gp2" --query "Images[0].ImageId"
    

    This returns the latest Amazon Linux 2 AMI ID.

    If we want to see all the available ImageIds , we can simply use the command aws ec2 describe-images , then we would get :

  2. Create a Key Pair (if not already created):

     aws ec2 create-key-pair --key-name MyKeyPair --query "KeyMaterial" --output text > MyKeyPair.pem
     chmod 400 MyKeyPair.pem
    
  3. Get the Subnet ID

    Subnets belong to a VPC and are specific to an availability zone (AZ). To list subnets:

     aws ec2 describe-subnets --query "Subnets[*].{SubnetID:SubnetId,AZ:AvailabilityZone,CIDR:SubnetArn,VPCID:VpcId}" --output table
    

    This command will show a table with:

    • SubnetID: The ID of the subnet .

    • AZ: The availability zone of the subnet (e.g., ap-southeast-1a).

    • CIDR: The subnet's CIDR block.

    • VPCID: The VPC ID associated with the subnet.

  4. Get the Security Group ID

    Security groups control the inbound and outbound traffic for your instance. To list available security groups:

     aws ec2 describe-security-groups --query "SecurityGroups[*].{GroupName:GroupName,GroupId:GroupId,Description:Description}" --output table
    

    This command will display:

    • GroupName: Name of the security group.

    • GroupId: ID of the security group (e.g., sg-0123456789abcdef0).

    • Description: Description of the security group.

  5. Launch an EC2 Instance:

     aws ec2 run-instances --image-id ami-012088614f199e3a9 --count 1 --instance-type t2.micro --key-name MyKeyPair --security-group-ids sg-035a7fbefd842789c --subnet-id subnet-092737912b6240c35
    

    So this way the ec2 instance got created . We can also verify its presence in the console :

    If we want , we can also name our ec2 instance in the AWS CLI by :

     aws ec2 create-tags \ 
     --resources i-0238f27f93912b8ec 
     --tags Key=Name,Value=Kishaloy
    

    See the final result :


Step 3: Stop the EC2 Instance

  1. Stop an Instance:

     aws ec2 stop-instances --instance-ids i-0238f27f93912b8ec
    

Step 4: Terminate the EC2 Instance

  1. Terminate an Instance:

     aws ec2 terminate-instances --instance-ids i-08364f4e1f3221576
    

  2. Verify Termination:

     aws ec2 describe-instances --instance-ids i-08364f4e1f3221576 --query "Reservations[].Instances[].State.Name"
    

    The state should change to terminated.


Step 5: Create a New Volume

  1. Create a Volume:

     aws ec2 create-volume --size 10 --availability-zone ap-southeast-1a --volume-type gp2
    

    Note the Volume ID ( vol-0a32778d8c1fb11d4).

  2. Attach the Volume to an Instance:

     aws ec2 attach-volume --volume-id vol-0a32778d8c1fb11d4 --instance-id i-0238f27f93912b8ec --device /dev/xvdf
    

We can also verify that the volume got attached to the instance by visiting the console :


Step 6: Delete a Volume

  1. Detach the Volume:

     aws ec2 detach-volume --volume-id vol-0a32778d8c1fb11d4
    

  2. Delete the Volume:

     aws ec2 delete-volume --volume-id vol-0a32778d8c1fb11d4
    

Proof : We can only see the root volume being attached , as we deleted the other volume :

Understanding Amazon S3 (Simple Storage Service)

Amazon S3 (Simple Storage Service) is a highly reliable, scalable, and cost-effective storage solution designed for storing object-based data. It's not meant for operating systems or database storage but is ideal for backups, file sharing, and static websites.


Key Concepts of S3

  1. Object Storage:

    • Stores data as objects (file + metadata).

    • Each object has a unique key to identify it.

    • Examples: Backup files, images, videos, logs, etc.

  2. Buckets:

  3. Unlimited Storage:

    • S3 can hold unlimited objects in a bucket, making it perfect for large-scale backups.
  4. High Availability and Reliability:

    • SLA (Service Level Agreement): 99.999999999% (11 9s) durability for data.

    • Your data is automatically replicated across multiple availability zones.

  5. Scalability:

    • S3 can handle any amount of data and grows automatically without manual intervention.
  6. Pay-as-You-Go:

    • You pay for the storage you use, data transfers, and requests (e.g., GET, PUT).

Why S3?

  1. Compared to Block Storage:

    • Block Storage (e.g., EBS): Ideal for OS, databases, and applications needing low latency.

    • S3: Designed for large-scale data storage where latency isn't critical (e.g., backups, static websites).

  2. Compared to EFS:

    • EFS (Elastic File System): Ideal for sharing files among multiple servers.

    • S3: Best for archival, backups, or storing media files accessed via applications.

  3. Compared to Ephemeral Storage:

    • Ephemeral Storage: Temporary, fast storage tied to EC2 instances, lost when the instance is terminated.

    • S3: Persistent and permanent storage for important data.

  4. Backup Use Case:

    • S3 is reliable, scalable, and cost-efficient for backups with features like versioning (Keeps multiple versions of the same file for recovery.), replication, and lifecycle policies to manage data retention.

How to Mount S3 bucket on EC2 Linux (Ubuntu) Instance :


sudo apt-get update
sudo apt-get install automake autotools-dev fuse g++ git libcurl4-gnutls-dev libfuse-dev libssl-dev libxml2-dev make pkg-config
git clone https://github.com/s3fs-fuse/s3fs-fuse.git

Now change to source code directory, and compile and install the code with the following commands:

cd s3fs-fuse
./autogen.sh
./configure --prefix=/usr --with-openssl
make
sudo make install

Use the below command to check where the s3fs command is placed in O.S. It will also tell you the installation is ok.

which s3fs

Create a new file in /etc with the name passwd-s3fs and Paste the access key and secret key in the below format.

sudo touch /etc/passwd-s3fs
sudo vim /etc/passwd-s3fs

Format : Your_accesskey:Your_secretkey

Change the permission of the file : sudo chmod 640 /etc/passwd-s3fs

Now create a directory or provide the path of an existing directory and mount S3bucket in it :-

mkdir /mys3bucket
s3fs your_bucketname -o use_cache=/tmp -o allow_other -o uid=1001 -o mp_umask=002 -o multireq_max=5 /mys3bucket

Now , since I had the below s3-bucket :

Hence , I used the command : sudo s3fs my-example-bucket69 -o use_cache=/tmp -o allow_other -o uid=1001 -o mp_umask=002 -o multireq_max=5 /mys3bucket

Now, on doing “df -h” , we see that the “s3fs” is Mounted on the mys3bucket directory :

Now , if we go inside the mys3bucket directory and check its contents , we see that it matches with the contents of my actual S3 bucket (my-example-bucket69) :

Now suppose we create some files or folders inside the mys3bucket directory through the ubuntu instance, we will see that the result gets reflected on the actual S3 bucket :

So the above observation confirms that the s3 bucket got mounted successfully.

Steps to Host a Static Website on S3:

Suppose I want to host a static website :

  • Create an S3 bucket named static-website69.

  • Upload your files (index.html, style.css).

  • Configure the bucket as a static website:

  • Set Permissions for Public Access :

    1. Go to Permissions Tab: Navigate to the Permissions tab in your bucket.

    2. Update Bucket Policy:

      • Scroll down to the Bucket policy section.

      • Click Edit and add the following policy to make your bucket objects publicly readable:

          {
            "Version": "2012-10-17",
            "Statement": [
              {
                "Effect": "Allow",
                "Principal": "*",
                "Action": "s3:GetObject",
                "Resource": "arn:aws:s3:::static-website69/*"
              }
            ]
          }
        
  • Visit the URL:

    I can finally see my static website :

What is S3 Versioning?

S3 Versioning is a feature that allows you to keep multiple versions of an object in an S3 bucket. When enabled, any time you upload a new version of a file with the same name, the older version is retained instead of being overwritten.


Why Use S3 Versioning?

  1. Accidental Deletion: Recover files if someone accidentally deletes them.

  2. Changes Tracking: Maintain a history of changes for your files.

  3. Disaster Recovery: Protect against data corruption or unintended changes.


How S3 Versioning Works

  • Before Versioning: If you upload a file with the same name, it overwrites the previous file. The old file is permanently gone.

  • After Versioning: Every time you upload a file with the same name, S3 keeps the old file as a different version.

Each file has a unique Version ID, and S3 uses it to track all versions of an object.

Practical :

Suppose currently my bucket has two files: Degree.pdf and kk.txt ( content: “Hello, I'm KK” )

Let me enable Versioning for this bucket :

Now, if I delete the Degree.pdf file and also upload a new kk.txt file (content :”Hello, I'm Kishaloy) , we see:

What is S3 Transfer Acceleration?

S3 Transfer Acceleration is a feature in Amazon S3 that speeds up the transfer of files to and from S3 buckets. It uses Amazon CloudFront’s globally distributed edge locations to reduce latency and improve upload/download speeds, especially for users far from the S3 bucket's region.


How Does It Work?

  1. Without Transfer Acceleration:

    • When you upload a file to an S3 bucket, your data travels directly from your location to the bucket’s region. If you're far away from the bucket's region, uploads might be slow due to higher latency.
  2. With Transfer Acceleration:

    • Instead of sending the data directly to the bucket, the file is first uploaded to the nearest CloudFront edge location.

    • From the edge location, the data travels over Amazon’s optimized network to the S3 bucket.

    • This process is faster because CloudFront's network is designed to handle such transfers efficiently.


Why Use Transfer Acceleration?

  1. Improves Upload/Download Speeds:

    • Ideal for users in remote locations or regions far from the S3 bucket.
  2. Reliable Data Transfer:

    • Amazon’s internal network is faster and more reliable than the public internet.
  3. Global Access:

    • Accelerates transfers for users all over the world.

PRACTICAL :

Suppose I have uploaded a video in my S3 bucket :

Now , if someone downloads this media file :

NOTE: The wget command is used to download files from the internet.

We can see above that the downloading process is taking some time ( around 60 seconds).

Hence , in order to reduce this downloading time , let me enable Transfer Acceleration to this bucket :

Now, after enabling it , if we re-try to download the same video file ":

We see above that this time it’s taking lesser time for downloading than before ( 2.5 seconds only).

NOTE BASED ON EXPERIENCE : While I was trying to use the wget command on the above s3 video file , I was getting permission denied type errors . In order to mitigate this problem , I did the following things:

  1. Turned Block all public access to Off .

  2. Attached the following Bucket Policy :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-example-bucket69/*"
        }
    ]
}

After the above two steps , my issue got resolved.

S3 Requester Pays

Normally, in Amazon S3, the bucket owner pays for the storage and data transfer costs when someone downloads files from their bucket.

With Requester Pays, the cost of downloading data is shifted to the person requesting the data (the downloader), not the bucket owner. This is useful when the bucket owner wants others to pay for the data they download, such as in the case of public datasets.

Real-Life Example:

Imagine you’re a researcher who uploads a large public dataset (like weather data) to an S3 bucket. If thousands of people download this data, the download costs can become very high for you, the bucket owner.

Instead of paying for everyone's downloads:

  1. Enable Requester Pays on your bucket.

  2. Now, anyone who downloads the data will pay for the bandwidth costs themselves.

We can enable it like :

Different Types of Amazon S3 Storage Classes :

1. S3 Standard (General Purpose)

  • Use Case: Frequently accessed data.

  • Features:

    • 99.99% availability and 11 9's durability.

    • Designed for data that requires low latency and high throughput.

    • Stores data in multiple availability zones (AZs) for high reliability.

Example: A website hosting service stores user-uploaded photos that need to be accessible instantly.

Cost: Higher than other classes but ideal for critical and frequently accessed data.


2. S3 Intelligent-Tiering (Cost-Optimized)

  • Use Case: Data with unpredictable or changing access patterns.

  • Features:

    • Automatically moves objects between access tiers (frequent and infrequent) based on usage.

    • No retrieval fees.

    • Designed to save costs without manual intervention.

Example: A company stores application logs that are frequently accessed initially but rarely used later. Intelligent-Tiering automatically optimizes storage costs.

Cost: Slightly more expensive than Standard for frequent access but saves cost by automatically moving infrequent data to cheaper tiers.


3. S3 Standard-IA (Infrequent Access)

  • Use Case: Data accessed less frequently but still requires quick retrieval.

  • Features:

    • Lower storage cost than S3 Standard.

    • Slightly higher retrieval cost.

    • Stored across multiple AZs.

Example: Monthly sales reports that are accessed during audits but need to be available on-demand.

Cost: Cheaper storage cost with higher retrieval charges compared to S3 Standard.


4. S3 One Zone-IA (Infrequent Access in a Single Zone)

  • Use Case: Data that can be recreated easily if lost and doesn't need multi-AZ replication.

  • Features:

    • Lower cost than Standard-IA.

    • Data is stored in only one AZ, so less durable in case of AZ failure.

Example: Backup copies of non-critical data like processed log files that can be regenerated.

Cost: Lowest cost for infrequent access data but slightly less reliable due to single-AZ storage.


5. S3 Glacier (Archival Storage)

  • Use Case: Data that is rarely accessed but must be retained for compliance or backup purposes.

  • Features:

    • Low-cost storage designed for long-term data archiving.

    • Retrieval times: Minutes to hours (depending on retrieval option).

Example: A movie production company archives old film footage that is rarely accessed but must be preserved.

Cost: Very low storage cost but retrieval charges apply. Retrieval time is slower compared to other classes.


6. S3 Glacier Deep Archive (Lowest Cost Archival Storage)

  • Use Case: Data accessed very rarely (e.g., once a year) but must be preserved for regulatory compliance.

  • Features:

    • Cheapest storage option.

    • Retrieval times: 12 to 48 hours.

Example: Banking institutions store old financial transactions for legal compliance, accessed only during audits or legal disputes.

Cost: Cheapest option for long-term archival, but retrieval is slow and costly.

S3 Lifecycle Rule:

Amazon S3 Lifecycle Rules help you automatically manage the storage of objects in your bucket by transitioning them to a more cost-effective storage class or by deleting them after a set period of time.


Why Use Lifecycle Rules?

  • Save Money: Move rarely accessed data to cheaper storage (like Glacier or Intelligent-Tiering).

  • Automate Cleanup: Delete old or unnecessary files automatically.


Real-Life Example: S3 Lifecycle Rules

Scenario:

You manage a video streaming platform where users upload videos daily. The videos are accessed frequently in the first month but rarely after that. To save costs, you decide to optimize your storage based on the access pattern.


Solution Using S3 Lifecycle Rules:

  1. Storage Policy:

    • First 30 days: Store videos in the S3 Standard storage class for fast access.

    • Day 31 to Day 90: Move videos to S3 Standard-IA (Infrequent Access) to reduce costs since they are rarely accessed.

    • After 90 days: Archive videos to S3 Glacier for long-term storage at the lowest cost.

    • After 1 year: Delete videos automatically if they are no longer needed.

  2. Lifecycle Rule Configuration:

    • Transition to Standard-IA after 30 days.

    • Transition to Glacier after 90 days.

    • Delete objects after 1 year.

Important AWS CLI S3 Commands :

CommandPurpose
aws s3 lsList all buckets.
aws s3 mb s3://bucket-nameCreate a new bucket.
aws s3 rb s3://bucket-nameDelete a bucket (bucket must be empty).
aws s3 cpCopy files between local system and S3.
aws s3 mvMove files between local system and S3.
aws s3 rmDelete objects in S3.
aws s3 syncSync local folder with S3 bucket.
aws s3 presignGenerate a pre-signed URL for an object in S3.

Outcomes of the s3 ls,s3 mb,s3 rb commands :

Outcomes of the s3 cp command for COPYING files and directories :

Using s3 cp command to download :

SYNTAX to Download Data from S3:

  1. Download Single File:

     aws s3 cp s3://your-bucket-name/file.txt /path/to/local/
    

    Example:

     aws s3 cp s3://my-bucket/index.html ./
    
  2. Download Entire Bucket:

     aws s3 cp s3://your-bucket-name/ /path/to/local/ --recursive
    

So above , we have downloaded the myapp.py file from the bucket.

Command to List All Contents of an S3 Bucket

aws s3 ls s3://<bucket-name> --recursive

Remove Data

  1. Delete a File:

     aws s3 rm s3://your-bucket-name/file.txt
    

  2. Delete All Files in a Bucket:

     aws s3 rm s3://your-bucket-name/ --recursive
    

Generate Pre-Signed URL

Create a pre-signed URL to share a private file:

aws s3 presign s3://your-bucket-name/file.txt --expires-in 3600

This creates a URL valid for 1 hour (3600 seconds).

Sync Data

Why Do We Sync Data?

Syncing data ensures that the content between two locations (e.g., local system and S3 bucket) is consistent.

Why Sync Is Better Than cp?

  • aws s3 cp: Copies files from one location to another without checking for duplicates or updates. It’s ideal for single file transfers.

  • aws s3 sync: Detects differences (new, modified, or missing files) and only transfers those. It’s efficient for maintaining consistency between two locations.

  1. Sync Local Directory to S3:

     aws s3 sync /path/to/local/dir s3://your-bucket-name/
    
  2. Sync S3 Bucket to Local Directory:

     aws s3 sync s3://your-bucket-name/ /path/to/local/dir
    

S3 Cross-Region Replication (CRR)

What is CRR?

Cross-Region Replication automatically copies objects from one Amazon S3 bucket to another bucket in a different AWS region.

Why Use It?

  • Disaster Recovery: If one region goes down, data is still available in another region.

  • Performance: Serve content to users from a closer region for lower latency.

  • Compliance: Meet regulations that require storing data in specific regions.

Example Scenario:

You run an e-commerce website. Your main S3 bucket is in the US-East (Virginia) region. To serve European users faster and ensure redundancy, you replicate the bucket to EU-West (Ireland).

How It Works:

  1. Source Bucket: Your primary bucket where data is initially uploaded.

  2. Destination Bucket: The bucket in the different region where data gets replicated.

  3. Replication Rule: You define what objects to replicate (e.g., all objects or only those with a specific tag).


Key Points:

  • Requires enabling versioning on both buckets.

  • Can replicate specific objects or all objects.

  • One-way replication: Changes in the destination bucket are not replicated back to the source.

PRACTICAL :

Suppose I have two buckets : my-example-bucket69 {Source bucket; us-east-1} and my-example-bucket70 {Destination bucket; ap-southeast-1} . Also , I have enabled versioning in both of these buckets {COMPULSORY}.

I created the replication rules :

Now, suppose if I create a new folder in the source bucket named “Kishaloy“ .

Then, automatically we get the folder Kishaloy in the destination bucket:

S3 Cross-Account Access

What is Cross-Account Access?

Allows you to grant another AWS account access to your S3 bucket.

Example Scenario:

A media company (Account A) uploads high-quality videos to an S3 bucket. Their marketing partner (Account B) needs access to those videos for promotional campaigns.

How It Works:

  1. Bucket Owner (Account A):

    • Creates an S3 bucket.

    • Grants access to Account B using a bucket policy or Access Control List (ACL).

  2. Other Account (Account B):

    • Accesses the bucket using AWS CLI, SDK, or console, as permitted by the policy.

Key Points:

  • Policies can be restrictive (read-only) or permissive (read/write).

  • You can use IAM roles for temporary access instead of sharing keys.

What are the factors on which S3 billing happens?

  1. Amount of data (GB's) which is store on S3.

    Example: If you store 500 GB in S3, you pay for those 500 GB.

  2. Based on storage Class.

    Example:

    • Standard Class (frequent access): Higher cost but faster retrieval.

    • Glacier Class (archival): Lower cost but slower retrieval.

  3. The amount of data out which happens from your bucket - Data out charges you have to pay.

    Example: A 1 GB file downloaded from S3 to your local machine incurs a data-out cost.

  4. The amount of request which happens on your S3 bucket.

    Example:

    • Uploading 1000 files (using PUT requests) incurs charges for 1000 requests.

    • GET requests (e.g., downloading files) also have a cost.

  5. Request Put object, get object, delete object, move object, list obj.

    Example:

    • PUT, COPY, POST, LIST: Higher cost because they involve data writing or organization.

    • GET and SELECT: Lower cost because they involve data retrieval.

Setting Up Your Own Private Cloud in AWS:

Creating a private cloud in AWS involves using Amazon Virtual Private Cloud (VPC). A VPC is a logically isolated section of AWS where you can launch resources like EC2 instances in a secure, controlled environment.

What is a VPC?

  • Definition: A VPC is your private cloud within AWS. You control its network, such as IP ranges, subnets, route tables, gateways, and security settings.

  • Example: Imagine you're building a company's private IT infrastructure but in the cloud. AWS gives you a virtual "network box" (VPC) to set up your environment securely.

Why Use a VPC?

  1. Isolation: Keep your resources private and secure.

  2. Customization: You control IP ranges, subnets, and routing.

  3. Security: Apply firewalls, security groups, and network ACLs.

  4. Integration: Connect your on-premises data center with AWS.


VPC Architecture Components

  1. CIDR Block (IP Address Range):

    • Definition: The range of private IP addresses for your VPC (e.g., 10.0.0.0/16).

    • Example: Think of it as your private internet network.

    • Key Tip: Start with a wide range (e.g., /16 gives you 65,536 IPs).

  2. Subnets:

    • Definition: Sub-divisions of a VPC to group resources.

    • Example: One subnet for public-facing resources (e.g., web servers) and another for private resources (e.g., databases).

    • Types: Public (accessible from the internet) and Private (restricted).

  3. Internet Gateway (IGW):

    • Definition: Connects your VPC to the internet.

    • Example: Like the main door to your house.

  4. NAT Gateway (Network Address Translation):

    • Definition: Allows private instances to access the internet (e.g., for updates) without being exposed.

    • Example: Like a proxy server for private resources.

  5. Route Tables:

    • Definition: Defines the paths that network traffic follows.

    • Example: A route table with a rule: "Send internet traffic (0.0.0.0/0) to IGW."

  6. Security Groups:

    • Definition: Acts as a firewall for resources, controlling inbound/outbound traffic.

    • Example: Allow SSH (port 22) access to EC2 instances from your office IP.

  7. Network ACLs (Access Control Lists):

    • Definition: Optional layer of security at the subnet level.

    • Example: Block all traffic from a suspicious IP range.

  8. Peering Connections:

    • Definition: Connect two VPCs privately.

    • Example: Connect your VPC in the US with another VPC in Europe.

  9. VPC Endpoints:

    • Definition: Securely connect to AWS services without an internet gateway.

    • Example: Access S3 from your VPC without using the public internet.

Practical: Step-by-Step to Set Up a Private Cloud in AWS

  1. Go to the AWS Management Console > VPC Dashboard.

  2. Click Create VPC.

  3. Enter:

    • Name: MyPrivateCloud

    • CIDR Block: 10.0.0.0/16

  4. Customize the Availability Zones.

  5. Select the required number of public and private subnets.

  6. Select for NAT gateways and VPC endpoints.

  7. Enable DNS resolution and DNS hostnames.

See the execution below :-

Final outcomes :-

Advantages of Using Private Cloud in AWS

  1. Customizable: Full control over network settings.

  2. Security: Isolated network with fine-grained permissions.

  3. Scalability: Add resources or connect with other regions/VPCs.

  4. Integration: Securely extend your on-premises data center.


Disadvantages

  1. Complexity: Requires network knowledge to design properly.

  2. Cost: Components like NAT Gateways and data transfers add to costs.

  3. Management Overhead: You must maintain IP ranges, routing, and security.

My above VPC Setup Overview:

  1. VPC Name: MyPrivateCloud-vpc

  2. Subnets:

    • Public Subnet: MyPrivateCloud-subnet-public1-ap-southeast-1a in ap-southeast-1a.

    • Private Subnet: MyPrivateCloud-subnet-private1-ap-southeast-1a in ap-southeast-1a.

  3. Route Tables:

    • Public Route Table: associated with the public subnet and routes traffic to the Internet Gateway.

    • Private Route Table: associated with the private subnet and routes traffic through the NAT Gateway. The private route table also includes a route to the VPC Endpoint for S3 (helpful if we want instances in the private subnet to access Amazon S3 without using the public internet).

  4. Network Connections:

    • Internet Gateway (IGW): MyPrivateCloud-igw for internet access.

    • NAT Gateway: MyPrivateCloud-nat-public1-ap-southeast-1a for private subnet internet access.

    • VPC Endpoint for S3: MyPrivateCloud-vpce-s3 to connect securely to S3 without using the public internet.

Verify Connectivity and Test Your VPC Setup

Now, let’s test the VPC configuration by launching instances and verifying functionality:


Step 1: Test the Public Subnet

  1. Launch an EC2 instance in the public subnet (MyPrivateCloud-subnet-public1-ap-southeast-1a).

    • Assign a public IP address.

    • Associate a security group allowing SSH (port 22) and HTTP (port 80) access from your IP or the internet.

  2. Connect to the instance using SSH.

    • Run a ping command to test internet connectivity:

        ping google.com
      
    • If the connection works, your public subnet is configured correctly.

Therefore, the public subnet is configured correctly.

Step 2: Test the Private Subnet

  1. Launch an EC2 instance in the private subnet (MyPrivateCloud-subnet-private1-ap-southeast-1a).

    • Do not assign a public IP address.

    • Use a security group that allows SSH only from the public instance. [ Note: the Private IP of the public instance must be used as Source ]

  2. Connect to the private instance through the public instance using SSH bastion:

    • SSH into the public instance first.

    • From the public instance, SSH into the private instance using its private IP.

    • In order to do that , use the command : ssh -i <PRIVATE_KEY.pem> username@<PRIVATE_INSTANCE_IP>

  3. Test internet connectivity:

    • Try to ping an external site (e.g., ping google.com).

    • If it works, your NAT Gateway is configured correctly.

Since the above ping is successful , thus , NAT GATEWAY is working fine.

If we try to ssh into the private instance from any other system (apart from the public ec2 instance) , then connection will obviously get refused :

Step 3: Test the S3 Endpoint

  1. Log in to the private instance.

  2. Install the AWS CLI if not already installed.

  3. Use the CLI to list objects in an S3 bucket:

     aws s3 ls s3://your-bucket-name --region ap-southeast-1
    
    • This should work because your S3 VPC endpoint (MyPrivateCloud-vpce-s3) enables direct access to S3.

Initially , the above command wasn’t working fine but then I realized that instance shall have an IAM role with the appropriate permissions attached:

Therefore, the S3 VPC endpoint is working fine .

SOME EXTRA THEORY => IPv4 (Internet Protocol version 4) vs IPv6 (Internet Protocol version 6) :

1) IPv4 (Internet Protocol version 4):

  • Address Format: IPv4 addresses are 32-bit numbers, written as four decimal numbers separated by dots. Example: 192.168.1.1

  • Total Number of Addresses: About 4.3 billion unique addresses (2³²).

  • Example:

    • Your home router might have an IPv4 address like 192.168.0.1.

2) IPv6 (Internet Protocol version 6):

  • Address Format: IPv6 addresses are 128-bit numbers, written as eight groups of hexadecimal numbers separated by colons. Example: 2001:0db8:85a3:0000:0000:8a2e:0370:7334

  • Total Number of Addresses: a really huge number (2¹²⁸ addresses).

  • Example:

    • A server or cloud instance might have an IPv6 address like 2401:db00:3020:70e8::1.