DEV Community: Okoye Genevieve

AWS S3 Essentials: Real-World Training on Buckets, Hosting, and Snow Family

Okoye Genevieve — Sun, 03 Aug 2025 10:37:55 +0000

📘 Introduction: Why Learn Amazon S3?

Amazon S3 (Simple Storage Service) is more than just a place to store files in the cloud — it’s a powerful, scalable, and secure backbone for countless web apps, backups, data pipelines, and even static websites. Whether you're just starting your cloud journey or building hands-on AWS skills, understanding S3 is foundational.

In this training, I went beyond theory and dove into real-world scenarios that demonstrate how S3 works in practice. From creating and securing buckets to hosting websites and replicating data across regions, each session was designed to build practical knowledge through step-by-step labs and relatable examples.

This post is a full recap of what I learned, including key features like versioning, encryption, storage classes, the AWS Snow Family, and more. If you’re looking for a beginner-friendly breakdown with practical context, you’re in the right place.

Practical Scenario: Hosting a Global NGO Website Using Amazon S3

Background:
Imagine you're helping a global NGO launch a simple, low-cost website that people can visit from anywhere in the world. The site only uses static files like HTML, CSS, and images. Amazon S3 is a great fit because it’s cheap, fast, and scalable.
(Beginners guide)
Step 1: Create an S3 Bucket
• Open the AWS Console and go to the S3 service
• Click “Create bucket”

• Give it a unique name like global-ngo-website
• Choose a region close to your users (e.g., US-East-1)

-Enable versioning :Although I enabled versioning during the initial bucket creation—rather than navigating through the detailed “Properties” tab—the purpose remains the same: to safeguard my data. S3 Versioning is a crucial feature that ensures every change to an object is preserved, not overwritten. This means if I ever upload a new index.html file with the same name, the previous version is still securely stored and can be retrieved, restored, or deleted at any time.

In real-world scenarios, versioning acts like a built-in backup system—protecting against accidental deletions, overwrites, or even malicious changes. For a website or project where content accuracy matters, this feature adds an essential layer of safety and traceability.

-Unblock all public access

• Leave other settings as default and click “Create bucket”

Step 2: Upload Your Website Files, you do not need to worry about the code all you need to do is to generate it with ChatGPT,Gemini or any other AI.Then paste and save it via VScode(more info will be on the diragrams)
• Upload two basic files:
o index.html: The main homepage
o error.html: A page shown if someone visits the wrong URL
• Click your new bucket → Click “Upload” → Add the files → Click “Upload”

Step 3: Set Up Static Website Hosting
• Go to the “Properties” tab of your bucket

• Scroll to “Static website hosting” → Click “Edit” → Enable it

• For Index Document, enter: index.html (the name of your main page)
• For Error Document, enter: error.html (the name of your error page)

→ Save changes
lets check if we can now access our file on our browser, copy the url and paste it on your browser.

oops! now lets go and configure the permissions proper .
**Step 4: **Allow Public Access to Website Files
• Go to “Permissions” → Click “Edit” under “Bucket Policy”
• Paste this policy (replace your-bucket-name with yours):

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPublicRead",
"Effect": "Allow",
"Principal": "",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket-name/"
}
]
}
• Save the policy

now lets refresh our page and retry

great!
now make a slight mistake on our bucket name will bring up our error page

Step 5: Assign Different Storage Classes
• Click on your bucket name (e.g. mybucketwife)
• Go to the Objects tab
You’ll see the list of uploaded files like index.html, image.png, report.pdf, etc.
• Select a file you want to change
• Click the checkbox next to the file (e.g. report.pdf)
• Click on “Actions” (or right-click)
• Choose “Change storage class”
• Choose the new class
• For example:
o Standard (keep it like that for homepage files)
o Standard - Infrequent Access
o Glacier (for archive)
• Click Save/Apply

_And with that concludes this session !
The next project on s3 will be on replication and IAM !
_

make sure to like and follow for more contents like this and also remember to delete your resources to avoid charges!

What Comes After a VPC? Routing, Firewalls, and Security Rules in AWS

Okoye Genevieve — Thu, 31 Jul 2025 21:46:10 +0000

⚠️ Before You Dive In...

This post is a continuation of my AWS networking journey. If you're new to VPCs, subnets, and internet gateways, I highly recommend checking out my previous post — “Mastering AWS Networking: Building My First VPC!”

In that post, I walked through the foundational steps of creating a Virtual Private Cloud (VPC), setting up subnets, and attaching an internet gateway.

This current guide builds on those concepts and focuses on configuring route tables, security groups, and network ACLs to secure and control traffic flow within your network.

So if you're just starting out, go through that first — it’ll make this guide much easier to follow and more meaningful!

🧭 1. Create and Associate a Route Table

What is a route table : A route table acts like a traffic controller for your network. It is a set of rules, or routes, that determine where network traffic from a subnet or gateway is directed. It lists the routes to specific network destinations and contains information about the network topology immediately around it.
✅ Step 1: Navigate to Route Tables
In the VPC Dashboard, select “Route Tables” from the left-hand menu.
--Click “Create route table.”

✅ Step 2: Set Route Table Details
--Name your route table (e.g., PublicRouteTable).
--Select the VPC you previously created.
--Click “Create route table.”

✅ Step 3: Edit Routes to Add Internet Gateway
--Select your newly created route table.
--Go to the “Routes” tab and click “Edit routes.”

--Click “Add route.”
--Destination: 0.0.0.0/0
--Target: Select your Internet Gateway (e.g., igw-xxxxxxxx)
--Click “Save changes.”

✅ Step 4: Associate with Subnet
--Go to the “Subnet associations” tab.
--Click “Edit subnet associations.”

--Select the subnet you want to make public.
--Click “Save associations.”

✅ Your subnet is now public and can access the internet!

🔐 2. Configure a Security Group

A security group acts as a virtual firewall for your Amazon EC2 instances, controlling inbound and outbound traffic. Its main advantage is that it provides a powerful and easy-to-manage layer of security, allowing you to define granular rules to filter traffic at the instance level.
✅ Step 1: Navigate to Security Groups
--Still in the VPC Dashboard, click “Security Groups.”
--Click “Create security group.”

✅ Step 3: Configure Inbound Rules
--Click “Add Rule.”
--Type: HTTP
--Protocol: TCP
--Port: 80
--Source: Anywhere (0.0.0.0/0)
--(Optional) Add another rule for SSH (port 22) if you want SSH access.
--Then click on create

🔒 3. Set Up a Network ACL (Optional Advanced Step)

A Network Access Control List (Network ACL) is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. Its advantage is that it provides an additional, stateless layer of security at the subnet level, allowing you to define a broader set of rules for traffic entering or leaving a subnet, which complements the instance-level security provided by security groups.
✅ Step 1: Navigate to Network ACLs
--On the VPC dashboard, click “Network ACLs.”
--Click “Create network ACL.”

✅ Step 2: Configure the ACL
--Name your ACL (e.g., PublicSubnetACL).
--Select your VPC.
--Click “Create.”

✅ Step 3: Add Inbound Rules
--Select your ACL and go to “Inbound rules.”
--Click “Edit inbound rules.”

--Add rule:
--Rule #: 100
--Type: HTTP
--Protocol: TCP
--Port Range: 80
--Source: 0.0.0.0/0
--Allow/Deny: Allow
--Repeat as needed (e.g., SSH on port 22).

"I challenge you to edit your inbound rule "

✅ Step 5: Associate with Subnet
--Go to “Subnet associations”.
--Click “Edit subnet associations.”
--Select your subnet.
--Save.
✅ Now your subnet is protected by both a security group and a network ACL.

✅ Wrapping Up

And that’s it! You've now taken your VPC setup to the next level by configuring route tables, security groups, and network ACLs — key tools for managing and securing traffic in your AWS network.

These components may seem small on their own, but together, they play a critical role in keeping your infrastructure functional and secure.

🔒 Up next in the series: Creating a Private Subnet — where we’ll explore how to isolate resources, use NAT gateways, and build a more production-ready network.

Stay tuned, and thanks for following along on this journey through AWS networking!

Step-by-Step: Creating a VPC, Subnet & Gateway on AWS (Beginner-Friendly)

Okoye Genevieve — Thu, 31 Jul 2025 20:34:35 +0000

Why AWS VPC?
Amazon Virtual Private Cloud (VPC) is a service that allows you to provision a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network. VPCs are essential for creating a secure and organized structure for your infrastructure in the Cloud, helping to reduce the risk of losing control over your resources.

I used Amazon VPC in this project to create subnets, assign IP addresses and CIDR blocks, enable auto-assign for public IPs, and connect my VPC to the internet using an Internet Gateway.

Here's how I set up my VPC and related resources in AWS:
*First the VPC *
✅ Step 1: Search for VPC
Head to the AWS Management Console.

In the search bar at the top, type “VPC”.

From the dropdown or results page, click on the VPC Dashboard (refer to the diagram above for visual aid).

✅ Step 2: Start the VPC Creation Process
On the VPC Dashboard, click the “Create VPC” button.

If you're unsure at any point, feel free to refer back to the diagrams provided.

✅ Step 3: Configure VPC Settings
Under Resource to create, select “VPC only”.

Enter a name for your VPC (e.g., MyFirstVPC).

Under IPv4 CIDR block, choose “Manual input”.

Type in your desired CIDR block (e.g., 10.0.0.0/16).

Leave all other settings as default (you can add tags if you like for better organization).

Once everything looks good, click “Create VPC”.

✅ You’ve successfully created a VPC!

Next, let’s move on to creating a Subnet.

Subnets are subdivisions of a VPC network. They allow you to segment your VPC into smaller, manageable networks. Note that there might already be default subnets in your account, one for every Availability Zone in your chosen region.
✅ Step 1: Navigate to the Subnet Section
--In the VPC Dashboard, scroll down the left-hand menu and click on “Subnets.”

--Then click the “Create Subnet” button at the top right.

✅ Step 2: Configure Subnet Settings
Name tag: Give your subnet a descriptive name (e.g., PublicSubnet1).

VPC ID: Choose the VPC you just created from the dropdown.

Availability Zone: Select one (e.g., us-east-1a) or leave it to be auto-assigned.

IPv4 CIDR block: Enter a smaller subnet of your VPC range (e.g., if your VPC CIDR is 10.0.0.0/16, a subnet could be 10.0.1.0/24).

⚠️ Tip: Make sure your subnet CIDR block fits within your VPC CIDR range.

Leave the other options at their default unless you have specific requirements.

Click “Create Subnet.”

🌍 Creating an Internet Gateway

Internet Gateways are essential for making applications available on the internet. By attaching an internet gateway, your instances can access the internet and be accessible to external users.
✅ Step 1: Go to Internet Gateways
--In the VPC Dashboard, click “Internet Gateways” on the left menu.

--Click the “Create internet gateway” button.

✅ Step 2: Set Up the Gateway
--Give your gateway a name tag (e.g., MyIGW).

--Click “Create internet gateway.”

✅ Step 3: Attach Gateway to Your VPC
--After creating the gateway, select it from the list.

--Click “Actions” > “Attach to VPC.”

--Choose your VPC and confirm.

*✅ Now your VPC has a subnet and an internet gateway attached.
You’re almost ready to make your subnet public by updating the route table, but that will be on my next post so stay tuned!
*

Mastering AWS Networking: My Journey Begins!

Okoye Genevieve — Thu, 31 Jul 2025 13:24:49 +0000

I'm incredibly excited to announce that I'm diving deep into the world of AWS Networking, and I'm kicking off an "AWS Networking Series" to share my learning journey with all of you! My goal is to build a solid understanding of cloud networking architecture.

Why Cloud Networking?
Traditionally, businesses had to build their own data centers, hire network administrators, and manage all their servers. Cloud networking has revolutionized this by offering elasticity – meaning you only pay for the resources you use – and by shifting the management to cloud network engineers. This shift makes cloud networking a vital skill that I'm eager to master.

What I'm Learning
In this hands-on series, I'll be exploring key networking concepts within the cloud. By the end of 9 projects, I aim to have a comprehensive understanding of networking.

So, what exactly are *networks? *

Simply put, computer networks are systems that allow multiple computers to communicate. They are a collection of devices that can exchange data packets, with IP addresses guiding these packets to their destinations.

*And what about a VPC? *

A Virtual Private Cloud (VPC) is essentially a private, isolated section of a network that an organization owns within a cloud provider's infrastructure. It's crucial because it allows organizations to control and filter what enters and exits their network, and precisely manage access for devices, services, or people.

My Commitment
I'm dedicating 10 hours every week to this networking series, and I'll be holding myself accountable by consistently reminding myself of my goals. My reward? Achieving these goals and more!

I'm particularly excited to share my progress as I build a VPC with you!

Stay tuned for more updates as I delve deeper into AWS networking. Let's learn together!

Practical AWS Solutions: Overcoming Real-World Infrastructure Challenges (EC2, ELB, ASG)

Okoye Genevieve — Thu, 17 Jul 2025 09:41:54 +0000

introduction:

Greetings, fellow cloud enthusiasts!

Over the past few days, I had the opportunity to tackle several real-world cloud infrastructure scenarios within a simulated environment at TechNova. What initially appeared to be straightforward tasks often revealed valuable complexities during implementation.

This post details my approach to solving these challenges using core AWS services, including EC2 instances, Load Balancers, and Auto Scaling Groups (ASGs). My aim is to share practical insights and best practices gained from navigating these scenarios, which I believe will be particularly beneficial for those advancing in their cloud engineering journey.

*🏢 Scenario 1: Deploying a Load Balancer for a Company Web Application
*
The Task:
TechNova recently launched a product website hosted on EC2. The objective was to enhance its availability and fault tolerance by deploying an Application Load Balancer (ALB) to distribute incoming traffic across two EC2 instances situated in distinct Availability Zones.

Key Learnings:

While the ALB setup process in the AWS console is largely intuitive, the criticality of accurate instance tagging and meticulous security group rule configuration became immediately evident.

Ensuring the health checks were properly configured was paramount; instances would not register with the ALB without correctly passing these checks.

A common initial oversight involved unconfigured inbound rules for port 80, a fundamental requirement for web traffic.

⚡ Scenario 2: Implementing Auto Scaling Based on Traffic

The Task:
Given TechNova's varying traffic patterns—spikes during work hours and drops off-peak—the requirement was to configure an Auto Scaling Group (ASG) for dynamic scaling based on CPU utilization.

Challenges & Resolutions:

My initial attempt involved correctly creating the launch template and the scaling policy. However, I inadvertently omitted the crucial step of attaching this policy to the ASG itself. This oversight temporarily prevented the desired dynamic scaling behavior. Upon rectifying this, observing the ASG's effective response to simulated CPU load confirmed the successful implementation and validation of the scaling mechanism.

📊 Scenario 3: Scheduled Scaling for Cost Optimization

The Task:
Management sought to optimize infrastructure costs by implementing scheduled scaling actions to reduce instance count during off-peak hours at night and scale up prior to 9 AM on weekdays.

Advantages of Scheduled Scaling:

Configuring scheduled actions within the ASG proved to be remarkably straightforward and efficient.

A key consideration was ensuring all scheduled times were configured in UTC to avoid potential time zone-related discrepancies.

The precise, automated provisioning and de-provisioning of instances according to the defined schedule offered clear operational and cost benefits.

⚙️ Technical Detour: Navigating Linux Distribution-Specific Tooling

During one of these scenarios, as an avid Ubuntu user, I encountered a common distribution-specific pitfall: attempting to use amazon-linux-extras enable epel on an Ubuntu instance. This necessitated a brief, yet insightful, detour to identify the equivalent package management commands for Ubuntu (specifically, apt install software-properties-common and add-apt-repository). This highlighted the importance of understanding the underlying OS environment.

💬 Concluding Thoughts

These scenarios profoundly underscored the paramount importance of meticulous attention to detail in cloud infrastructure deployment. Even minor oversights in configuration—a missed checkbox or an incorrect flag—can significantly impact functionality. This reinforces the principle that troubleshooting and rectifying such issues are invaluable components of the learning process.

For those currently navigating AWS projects and perhaps feeling overwhelmed, I encourage a deliberate, step-by-step approach. Embrace the troubleshooting process as an invaluable part of skill development, and remember that encountering challenges is a natural and often necessary step toward mastery.

🙋‍♀️ Questions or Collaboration?

Your insights and questions are highly welcome. Please feel free to engage in the comments section or reach out directly for further discussion or assistance. Let's continue to foster collective learning, one cloud scenario at a time. 🚀

AWS EC2 + Nginx: Your First Web Server on Ubuntu

Okoye Genevieve — Mon, 16 Jun 2025 14:47:21 +0000

The prerequisite of this section is to know how to comfortably launch an EC2 instance, but if you can't you can check out my previous posts which shows the steps on how to deploy an EC2 instance.

Setting Up Your AWS EC2 Web Server

Step 1: Connect to Your EC2 Instance

Navigate to your key file directory.
Connect using ssh -i "C:\Users<YourName>\Downloads\nginx-key.pem" ubuntu@.

Step 2: Update Packages & Install Nginx

Update your instance's package list: sudo apt update.
Install the Nginx web server: sudo apt install nginx.

Step 3: Start & Enable Nginx

Start the Nginx service: sudo systemctl start nginx.
Enable Nginx to start on boot: sudo systemctl enable nginx.
Check Nginx status: sudo systemctl status nginx.

.
Step 4: Verify Web Server Access

Copy your instance's Public IPv4 address from the AWS console.
Paste the IP into a web browser to see the Nginx welcome page.

Step 5: Edit Web Page Content

Open the default Nginx HTML file (e.g., /var/www/html/index.nginx-debian.html) using sudo nano.
To edit the file to display "Gene first time here":
Inside the nano editor, press Ctrl + A to select all existing code.
Press Delete, ctrl+k or Backspace to remove the selected HTML.
Save changes by pressing Ctrl + X, then Y, then Enter.
Finally, refresh your browser using the Public IP to see the updated page.

Congratulations! You've successfully deployed your very own Nginx web server on an AWS EC2 instance and even customized its content. This is a significant milestone in your cloud journey!

Remember, every great project starts with a single step, and you've just taken a powerful one into the world of cloud computing and web hosting. Don't stop here! Use this newfound knowledge as a springboard to explore more advanced configurations, delve into front-end development, or integrate other AWS services.

The cloud is vast, and your potential is limitless. Keep building, keep learning, and keep sharing your progress! Happy coding!

From Zero to Web Server: Deploying Apache on AWS EC2

Okoye Genevieve — Sat, 14 Jun 2025 23:50:07 +0000

STEP 1:This is where we set up our virtual server in the cloud.

Accessing EC2 Dashboard: First, navigate to the EC2 service within the AWS Console.
Instance Details: We give our instance a name (like web-server1), choose the operating system (e.g., Amazon Linux 2023 AMI), and select an instance type (like t2.micro for Free Tier eligibility, which defines its CPU and memory).
Key Pair: We create or select a key pair, which is a crucial security measure that allows us to securely connect to our instance later.
Network Settings & Security Groups: We configure network settings, ensuring a public IP is assigned. Crucially, we set up a security group (a virtual firewall). For a web server, we specifically enable SSH (Port 22) for secure remote access, and HTTP (Port 80) to allow web traffic to reach our server from the internet.
Finally, we click "Launch instance" to provision our server.

STEP 2:Once the instance is running, we need to connect to it to install software.

Locate your Key Pair: We navigate to the directory where our .pem key pair file is saved (e.g., your Downloads folder).
Set Permissions: Before using the key, we must set its permissions to be very restrictive (chmod 400 your-key.pem). This ensures only you can read it, which is required for SSH to work.
SSH Command: We then use the ssh command, specifying our key (-i), the default username (ec2-user for Amazon Linux), and the instance's Public IP address. This establishes a secure shell connection to our remote server.

STEP 3:Installing and Starting Apache HTTPD

With a secure connection established, we can now configure our web server.

Update Packages: First, we update the instance's package lists and existing software to the latest versions using sudo yum update -y.
Install Apache: Next, we install the Apache HTTP Server package with sudo yum install httpd -y.
Start Apache Service: We start the Apache service using sudo systemctl start httpd.
Enable on Boot: To ensure Apache restarts automatically if the server reboots, we use sudo systemctl enable httpd.
Check Status: We can verify the service is running correctly with sudo systemctl status httpd

STEP 4: Verifying Web Server Access

The final step is to confirm our web server is accessible from the internet.

Get Public IP: We go back to the EC2 Instances dashboard and copy the Public IPv4 address of our running instance.
Test in Browser: We paste this Public IP address into a web browser. If everything is configured correctly, you should see the default Apache test page, confirming your web server is live!
Security Group Adjustment (Optional but shown): The 2025-06-09_13h47_39.png image shows a step where you might have adjusted the SSH inbound rules to limit the source IP to a specific address, rather than "Anywhere". This is a good security practice to restrict who can connect via SSH.

How to Launch and Connect to an AWS EC2 Instance (with SSH)

Okoye Genevieve — Mon, 09 Jun 2025 16:23:29 +0000

This post will guide you through the process of launching an Amazon EC2 (Elastic Compute Cloud) instance and securely connecting to it using SSH from your local machine. EC2 instances are virtual servers in the AWS cloud, providing scalable compute capacity.

Our Goal:

Our objective is to launch an EC2 instance within a VPC and subnet, then establish an SSH connection to it from our local system administrator's machine using a private SSH key. We'll configure a security group to allow SSH access on port 22.

The first step in the AWS Management Console is to locate the EC2 service.

After selecting the EC2 service, you will be directed to the EC2 Dashboard. From here, we will begin the process of launching a new virtual server.

Configure Instance Details and Key Pair

In the launch wizard, after selecting your desired AMI and instance type, you will need to create a new key pair (highlighted by the arrow). This key pair is essential for securely connecting to your instance later via SSH.

When you'er done with your configuration which is to choose the OS, the CPU, stoage... then you can go over to the next step, mind you that this method of creating an instance varies depending on the workload of your project.

Verify Instance Launch and Access Security Groups

After successfully launching your instance, you'll be redirected to the EC2 Instances dashboard.

Focus Area: The arrows indicate two important things:

Your newly launched instance (e.g., "front-end server") is now listed and in a "Running" state.
The left navigation panel shows "Security Groups" under "Network & Security." We'll navigate here to review or modify the security rules that govern access to your instance.

Review and Edit Security Group Inbound Rules

You are now on the Security Groups details page, specifically viewing the rules associated with the security group created during your instance launch.

Focus Area: The red arrow clearly points to the "Edit inbound rules" button. This is where you can modify which types of traffic (like SSH, HTTP, HTTPS) are allowed to reach your EC2 instance from external sources. We'll proceed to edit these rules.

Confirm or Adjust SSH Inbound Rule Source

On the "Edit inbound rules" page, you can see and modify the existing rules.

Focus Area: The red arrow highlights the "Custom" source field, specifically showing your public IP address (e.g., 154.120.95.81/32). This confirms that SSH (Port 22) traffic is allowed only from your machine's IP. While "My IP" automatically populates this, you could manually enter a specific IP address range (CIDR block) or choose other options like "Anywhere" (not recommended for SSH) if needed. Ensure this rule is correctly configured for your connection.

Retrieve Your Instance's Public IP Address

After confirming your security group rules, the last piece of information you need to connect to your EC2 instance is its public IP address.

Focus Area: Back on the EC2 Instances dashboard, locate your running instance. The red arrow points directly to the "Public IPv4 address" column. This is the IP address you will use to establish an SSH connection from your local machine. Copy this IP address.

You now have all the necessary information to connect to your EC2 instance using an SSH client like MobaXterm and the private key you downloaded

Connect to Your EC2 Instance via SSH

With your EC2 instance running, its security group configured to allow SSH from your IP, and your public IPv4 address copied, you are now ready to connect!

What you'll need:

Your Private SSH Key: The .pem file you downloaded in Step 4.
The Public IPv4 Address of your EC2 instance (from Step 9).
SSH Client: (e.g., MobaXterm Professional, as shown in your architecture, or PuTTY, OpenSSH on Linux/macOS).
Default Username: For Amazon Linux AMIs, it's ec2-user. For Ubuntu, it's ubuntu. For others, consult the AMI documentation.

Click on "Session".
Choose "SSH".
Enter the "Remote host" (your Public IPv4 address).
Specify the "Username" (e.g., ec2-user or ubuntu).
Under "Advanced SSH settings", check "Use private key" and browse to your .pem file.
Click "OK" to establish the connection.
Once connected, you'll have command-line access to your brand-new EC2 instance in the cloud!

Conclusion

Congratulations! You have successfully launched an Amazon EC2 instance and securely connected to it using SSH. You've learned how to:

Navigate the AWS EC2 console.
Launch a virtual server.
Create and manage SSH key pairs for secure access.
Configure security group rules to control network traffic.
Retrieve the public IP address of your instance.
Connect to your instance using an SSH client.
This EC2 instance now serves as a powerful foundation for hosting web applications, running backend services, or performing various computational tasks in the cloud. Remember to always follow best practices for security, such as restricting SSH access to known IPs and regularly reviewing your security group rules.

Feel free to explore further configurations and services within AWS to expand the capabilities of your cloud infrastructure!

Understanding Servers and Cloud Computing

Okoye Genevieve — Wed, 28 May 2025 16:07:43 +0000

Introduction

This document explores the foundational concepts of Servers and Cloud Computing. It delves into the distinctions between hardware and software server environments, outlines various server types, and clarifies different cloud deployment models. Furthermore, it provides a comparative analysis of key cloud service models (IaaS, PaaS, SaaS) and applies this knowledge to a practical business scenario, recommending suitable cloud infrastructure and AWS services.

Understanding Servers and Cloud Computing
Part A : Difference between hardware and software servers?
The difference between hardware and software server is that hardware server are the ones that we have on premise on our organization and the one we manually update and manage while software servers are the ones that are virtualized and we can rent on the cloud. They run on the hardware servers.
Example of 3 types of servers?

a. Web Server: Serves web pages (e.g., Apache HTTP Server, Nginx).
b. File Server: Stores and manages access to files (e.g., FTP server, SMB/NFS server).
c. Database Server: Stores, manages, and retrieves structured data (e.g., MySQL, PostgreSQL, MongoDB).
Cloud deployment models?
o Public Cloud
o Private Cloud
o Hybrid Cloud

Comparing IaaS, PaaS, SaaS with examples.

• IaaS (Infrastructure as a Service): Provides virtualized computing resources (VMs, networks). Ex: AWS EC2, Azure VMs. You manage OS, applications.
• PaaS (Platform as a Service): Provides a platform for developing, running, and managing applications without building/maintaining infrastructure. Ex: AWS Elastic Beanstalk, Heroku. You manage code.
• SaaS (Software as a Service): Fully managed application accessible over the internet. Ex: Gmail, Salesforce ,and other CRM web applications. You just use it.

Part B:

SaaS lets users manage everything - False
On-premises can scale easily - False.
DNS converts IP to domain names - True.
Cloud requires upfront hardware payment - False

Part C: Scenario-Based
Model: Public Cloud (Scalability, cost-effectiveness, agility for a startup)
For a new business, I'd choose the Public Cloud model for its rapid scalability and cost-efficiency. AWS services would be Amazon S3 for storage, AWS Lambda and API Gateway for the backend, and either Amazon RDS or DynamoDB for the database.