DEV Community: Ayo

Beginner's AWS Guide: Containers and Infrastructure as Code (Part 8)

Ayo — Fri, 08 Aug 2025 16:54:12 +0000

Objective:

This section explores containerisation and Infrastructure as Code (IaC) in AWS. We delve into Docker containers and how they solve deployment challenges, along with AWS ECS. We also examine the IaC service CloudFormation as a means for automating and managing cloud infrastructure through code rather than manual configuration!

Key IT Terminology: Containerisation 📦

Containerisation is like filling an isolated box with everything an application needs to run — instructions, tools, and supplies.

Once sealed, this box can be:

Shipped to any environment (local, test, production).
Duplicated to make identical containers.
Opened/ran anywhere with consistent behaviour — eliminating the “it only works on my machine” problem!

Image sourced from: https://www.xenonstack.com/insights/containerization

Key IT Terminology: Docker 🐳

Docker is a popular containerisation platform as it helps us package an app and everything it needs to run on any system — not just the one it was built on.

When packaging an app with Docker, we typically include:

The application code
Dependencies (supporting libraries, frameworks, packages)
A runtime version (e.g. Node.js, Python, Java)
System files, like environment variables and config files (setup blueprints)
A minimal OS layer, e.g. Linux or Windows (not the full OS, just what is needed)

Docker Hierarchy: Containers are built in layers

Dockerfile – A script with step-by-step instructions on what to put inside our box (our packing list).
Docker Image – A snapshot built from the Dockerfile (the sealed box). We can store images in registries like DockerHub or Amazon ECR to reuse them later.
Container – A running instance of that image (the opened box in action). We can run many containers from the same image!

ECS: Elastic Container Service 📦

Amazon ECS is a container orchestration service which helps us to deploy, manage, and scale Docker containers across AWS infrastructure.

We can run containers on two types of infrastructure:

EC2 launch type – We manage the server instances.
Fargate launch type – AWS manages the servers (serverless approach!).

Example: ECS Task Definition (EC2 launch type)

{
  "family": "simple-web-app",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "nginx:latest",           // Docker image for the container
      "cpu": 256,                        // CPU units
      "memory": 512,                     // Memory in MB
      "portMappings": [                  // Port mapping for network configuration
        {
          "containerPort": 80,           // Port inside the container
          "hostPort": 80                 // Port on the ECS host
        }
      ],
      "environment": [                   // Environment variables
        {
          "name": "ENV",
          "value": "production"
        }
      ],
      "essential": true              // Marks this container as essential for the task
    }
  ],
  "requiresCompatibilities": ["EC2"],    // Compatible with EC2 launch type
  "cpu": "256",                          // Total CPU for the task
  "memory": "512",                       // Total memory for the task
  "taskRoleArn": "arn:aws:iam::123456789012:role/myTaskRole"
}

💡 EKS (Elastic Kubernetes Service) is another AWS orchestration tool — more advanced and Kubernetes-based.

CloudFormation: Infrastructure as Code (IaC) 🏗️

CloudFormation lets us write templates that define our desired AWS infrastructure using code rather than clicking through the AWS Console.

Templates are written in JSON or YAML (YAML is preferred), and can describe entire AWS environments, including EC2 instances, VPCs, databases, security groups, and their relationships.

CloudFormation Advantages:

CloudFormation Hierarchy

💡 One template can lead to many different stacks depending on the input parameters and conditions we set in our JSON/YAML file!

CloudFormation: Template Components Overview

IaC Example: S3 Bucket


AWSTemplateFormatVersion: '2024-09-09'
Description: Simple S3 bucket for storing application data

Parameters:
  BucketName:
    Type: String
    Description: The name of the S3 bucket to create
    Default: my-simple-app-bucket

Resources:
  MyS3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Ref BucketName
      VersioningConfiguration:
        Status: Enabled
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

Outputs:
  S3BucketName:
    Description: Name of the created S3 bucket
    Value: !Ref MyS3Bucket

  S3BucketArn:
    Description: ARN of the created S3 bucket
    Value: !GetAtt MyS3Bucket.Arn

🎯 TL;DR

Docker packages our app and everything it needs into portable containers.
ECS orchestrates and manages our Docker containers across AWS infrastructure.
CloudFormation templates define our infrastructure as code for consistency and repeatability, while stacks are running instances of our templates.

✨ This is part of a mini-series where I delve into everything cloud-related. Check out my other posts for further learning! ✨

Beginner's AWS Guide: Serverless and Modern Computing (Part 7)

Ayo — Fri, 08 Aug 2025 16:54:08 +0000

Objective:

This section explores serverless architecture in AWS. We delve into its meaning and the associated services available in AWS, including Lambda (serverless functions) and API Gateway (serverless APIs) as means for building modern, cost-effective applications in the cloud.

Key IT Terminology: Serverless 🧠

Serverless doesn't mean "no servers" — it just means we don’t manage them. AWS handles all the infrastructure provisioning, scaling, and maintenance of servers behind the scenes. We just focus on writing code or storing data!

Serverless Examples:

DynamoDB – Fully managed NoSQL database
AWS Lambda – Run functions without managing servers
API Gateway – Expose APIs to the internet without managing servers

Here's an AWS Serverless overview, if you would like to dive deeper: https://aws.amazon.com/serverless/

AWS Lambda 🔁

AWS Lambda lets us run code in response to events — without provisioning or managing servers. It supports various languages, including:

Node.js (JavaScript)
Python
Java
C#
Ruby
Custom Runtime APIs

How Lambda works

We upload our code (as a function), and Lambda runs it automatically when triggered by an event (e.g. file upload, API request, database update).

With Lambda, we only pay for:

Number of invocations
Execution duration × memory allocated

It is still a server at the end of the day that requires CPU and memory to work efficiently!

For example, let’s say we upload images to an S3 bucket. A Lambda function can automatically resize those images and save them to another bucket — all without a single server setup.


// Sample Node.js Lambda function with Sharp and S3

const AWS = require('aws-sdk');
const sharp = require('sharp');
const s3 = new AWS.S3();

exports.handler = async (event) => {
  const bucket = event.Records[0].s3.bucket.name;
  const key = event.Records[0].s3.object.key;

  const original = await s3.getObject({ Bucket: bucket, Key: key }).promise();

  const resizedBuffer = await sharp(original.Body)
    .resize(300, 300)
    .jpeg({ quality: 80 })
    .toBuffer();

  const newKey = `resized/${key.replace(/\.[^/.]+$/, '')}-resized.jpg`;

  await s3.putObject({
    Bucket: 'my-resized-images-bucket',
    Key: newKey,
    Body: resizedBuffer,
    ContentType: 'image/jpeg'
  }).promise();

  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'Resized successfully!', original: key, resized: newKey })
  };
};

Uploading code to Lambda - 3 Options depending on Complexity

(1) Inline Editor

We can directly write or paste code into the inline editor on the console. This approach is best for small/test functions.

(2) Upload .zip file

We can write code locally in an IDE and compress it into a .zip file (up to 50MB), which we then upload via the AWS console or CLI.

(3) From S3

For larger codebases (>50MB compressed, up to 250MB uncompressed) or CI/CD pipelines, we upload our .zip file to an S3 bucket. Lambda then retrieves and deploys the code directly from S3.

Concurrency: What If Multiple Events Trigger Lambda?

Lambda has what we call concurrency - it automatically scales, creating multiple instances of our function to handle simultaneous requests.

1 event → 1 function instance
1000 events → 1000 isolated instances run in parallel

Each event gets its own container, so processing is isolated and doesn’t block others.

💡 For example, if 1000 users uploaded photos simultaneously to our S3 bucket, Lambda automatically spins up 1000 separate instances of our resize function - each processing one image.

AWS API Gateway 🚪

API Gateway is a serverless service for building, publishing, and managing REST/HTTP API endpoints. It basically acts as the solitary front door for applications to access data or services.

Analogy: Hospital Reception

Reception Desk = API Gateway
Patients = Make API requests

Each department = An endpoint

/emergency → A&E
/results → Lab reports
/appointments → Booking system

API Gateway routes traffic, handles authentication, enforces rate limits, and provides monitoring — all without server management.

What Do We Pay For?

Even though API Gateway is serverless, we pay for the infrastructure AWS handles behind the scenes:

Requests (number of API calls)
Data Transfer
Caching (if enabled)
Custom domain usage

💡 Just like paying reception staff to direct patients efficiently, we pay for API Gateway to route and process traffic.

🎯 TL;DR

Serverless means AWS manages the servers for us - we just focus on our code.
Lambda runs our code as functions when triggered by events - we only pay when it runs.
API Gateway creates and manages our API endpoints without server management.

✨ This is part of a mini-series where I delve into everything cloud-related. Check out my other posts for further learning! ✨

Beginner's AWS Guide: IAM and Security Fundamentals (Part 6)

Ayo — Fri, 08 Aug 2025 16:54:04 +0000

Objective:

This section looks into IAM and security fundamentals in AWS. We cover the role of IAM in controlling user access to AWS resources and monitoring AWS activity with services including CloudWatch and CloudTrail.

IAM: Identity & Access Management 👤

IAM is AWS’s security layer for managing who can access what in our cloud account, and how they can do it. It fundamentally looks at Authentication (who are you?) and Authorisation (what can you do?).

Principals

(1) Root User

When we first create an AWS account, we get a Root User - the account owner with full access to everything. This account should only be used for tasks including: setting up billing, emergency access, or creating initial IAM users or Identity Center setup.

(2) IAM Users

IAM Users are identities with permanent credentials (username/password or access keys) that can be grouped into IAM Groups for permission inheritance. We commonly use it for programmatic access (e.g., an application needing AWS SDK credentials).

💡 IAM Identity Center (formerly AWS SSO) is the preferred way to create and manage human access across multiple accounts using federated login.

(3) IAM Roles

IAM Roles provide temporary credentials and are assumed by users or services that need specific, time-limited access.

Roles are used for:

AWS Services (e.g. EC2 instance accessing S3)
Cross-account access
Temporary user access (e.g., external contractors or federated identities)

IAM: Authentication 👤

If we have an IAM user account, there are three primary ways to connect and interact with AWS services and resources:

IAM: Authorisation 👤

Once a principal (user, role, etc.) has been authenticated, we control what they can do using policies and permission boundaries. These define what AWS actions and resources the principal can access.

Here are the main types of authorisation mechanisms:

Inline Policies

They are attached directly to a specific user, group, or role, and are best used for one-off or tightly scoped permissions.

Resource-Based Policies

They are attached to AWS resources like S3 buckets, SNS topics, or Lambda functions to define which principals can access the resource and what actions they can take.

Managed Policies (AWS or Customer-Managed)

Reusable policies created and maintained either by us or AWS. They make it easier to apply policies consistently across multiple users or roles.

Permissions Boundaries

They set the maximum permissions a user or role can have, even if other policy types grant more.

Service Control Policies (SCPs)

They only apply within AWS Organisations. SCPs define the maximum allowed permissions across all accounts in an organisation or organisational unit (OU)

Image sourced from: https://www.tecracer.com/blog/2022/03/using-permission-boundaries-to-balance-security-and-developer-productivity.html

CloudWatch (Monitoring) 🔎

Many AWS services automatically send metrics to CloudWatch at regular intervals (typically every 1 or 5 minutes, depending on the service and plan).

It's essentially a system that tracks, collects, and responds to resource performance and operational data.

CloudWatch Metrics → Performance numbers that appear on a dashboard (CPU usage, storage space, request count, etc.)
CloudWatch Logs → Detailed text records that document every message from a resource, e.g. timestamp, log group, etc
CloudWatch Alarms → Notifications when thresholds are breached (email me when CPU > 80%)
CloudWatch Events (EventBridge) → Automating responses (e.g. restarting a server when an alarm triggers)

Each resource type typically sends its own specific set of metrics, for example:

EC2 specifically sends CPU utilisation, network traffic
S3 sends request counts, storage usage
Custom applications will send their own metrics manually via a CLI or SDK (for apps or on-prem monitoring).

Metric Structure Example:

Metric Name → CPUUtilisation
Namespaces → Categories (like "AWS/EC2", "AWS/S3")
Dimensions (Key-Value) → Specific resource identifiers (InstanceId=i-1234567, BucketName=my-bucket)
Metric Value → 50%
Timestamp → 2024-11-01

CloudTrail (Auditing) 🔎

CloudTrail captures all control plane API activity (e.g., resource creation, deletion, etc.). It records what action was taken, by whom, when, on what resource, from what IP, and using what method (Console, CLI, SDK).

It can also be configured to capture data events, such as S3 GetObject, PutObject (but this is not enabled by default).

💡 Multi-region logging is enabled by default in CloudTrail, but we can customise its regional scope in the console. The actual audit logs are collected and stored in an S3 bucket (optionally forwarded to CloudWatch Logs)!

🎯 TL;DR

IAM controls who can do what.
CloudWatch monitors how resources are performing.
CloudTrail audits what actions were actually taken.

✨ This is part of a mini-series where I delve into everything cloud-related. Check out my other posts for further learning! ✨

Beginner's AWS Guide: Databases (Part 5)

Ayo — Fri, 08 Aug 2025 16:54:00 +0000

Objective:

This section dives into databases and builds upon the storage concepts covered in the Beginner's AWS Guide: Storage Services (Part 3). Here, we explore databases and look into RDS (relational databases) and DynamoDB (NoSQL) as popular service options available in AWS.

Databases vs Storage Services

A database is a system that stores, organises, and queries structured or semi-structured data at scale.

Simple Library Analogy for Databases

The library shelves = tables
Academic books = structured data
Magazines = semi-structured data
Search system = query engine

We don't just store data in a library — we organise and query it efficiently. This has its benefits, including being able to:

Model relationships in data.
Query data quickly and flexibly.
Support multi-user reads/writes (multiple people using the library at the same time).
Enable transactional consistency (ACID compliance - updates in near real-time).

The link below discusses Relational Databases vs. NoSQL Document Databases in greater depth. I highly recommend having a read to understand the differences between the two: https://lennilobel.wordpress.com/2015/06/01/relational-databases-vs-nosql-document-databases/

RDS: Relational Database Service 🏢

RDS is a managed AWS service for creating and managing SQL-based relational databases. For example, we can choose from popular database engines such as:

PostgreSQL
MySQL
Microsoft SQL Server
Oracle
MariaDB
Aurora (AWS's own SQL database engine)

💡 We configure RDS, even though it uses EC2 instances behind the scenes to run our databases.

RDS handles the entire EC2 layer for us — including provisioning the server, managing the operating system, handling scaling, and monitoring — so we never need to access or manage the EC2 instance directly.

We simply choose our engine options, instance type, storage, and other settings — and RDS takes care of the rest.

RDS: Creating a Database 🏢

Choose Engine
Configure DB instance settings (storage, memory, availability, VPC/network settings, security groups)
Launch DB Instance (AWS handles provisioning)
Connect & Use

DB connection info to note via the AWS console:

Our set DB name
Master Username/Password - DB login details
DNS Connection Endpoint (e.g. mydb.abc123.rds.amazonaws.com)
Port (e.g., default: 5432 for PostgreSQL)

💡 The DNS endpoint is how AWS gives us a stable and reliable way to connect to our database — even if the underlying IP changes. Meanwhile, the port is required as it tells the OS which application (PostgreSQL, MySQL, etc.) is handling the request!

Connect via:

GUI tools (e.g., pgAdmin, DBeaver)
CLI tools (e.g., psql)
Application code (e.g., Python, Node.js + drivers)

Once connected, we can finally create our database structure, i.e. create tables, insert data, and run queries.

DynamoDB: NoSQL Database Service 🏢

DynamoDB is AWS’s serverless NoSQL database designed for speed, scalability, and simplicity. We delve into serverless computing in "Serverless and Modern Computing (Part 7)", but essentially it means we do not need to manage any server infrastructure (AWS does!).

DynamoDB stores data in tables using:

Key-value pairs
Documents (typically in a JSON-like format)

Each row in a table is called an 'item', and each item can be up to 400KB in size.

Partition Key: Groups related items under a unique identifier
Sort Key (optional): Orders items within the group
Attributes: The actual data stored within the item

EXAMPLE: ONLINE-STORE

When a customer makes a purchase, they are assigned a partition key, e.g. Customer-ABC, to uniquely identify them.
By adding a sort key (e.g. OrderDate or OrderID), we can store multiple orders under that same customer and organise them chronologically or by another order-specific attribute.
This structure lets us group and query all of a customer's purchases easily, enabling features like tracking spending patterns, generating order histories, or sending targeted promotional offers.

DynamoDB: Creating a Database 🏢

(1) Create a Table

Set the table name (e.g. Users)
Define a partition key (e.g. UserID)
Add an optional sort key (e.g. Timestamp)

(2) Configure Table Settings

Read/Write Capacity (how much traffic our table can handle)
On-Demand vs Provisioned mode (auto scaling our table or setting planned capacity)
Optionally enable Global Tables, which quickly replicates our table across multiple AWS regions

(3) Add Data via:

AWS Console (manually)
AWS CLI (put-item)
SDKs (Python boto3, JavaScript, etc.)

Summary: RDS vs. DynamoDB 🏢

🎯 TL;DR

RDS provides all-in-one managed relational database engines (MySQL, PostgreSQL)
DynamoDB is a fast NoSQL database perfect for quick retrieval of lightweight data
AWS handles scaling and maintenance in both, so that we can prioritise focus elsewhere.

✨ This is part of a mini-series where I delve into everything cloud-related. Check out my other posts for further learning! ✨

Beginner's AWS Guide: Network Fundamentals (Part 4)

Ayo — Fri, 08 Aug 2025 16:53:52 +0000

Objective:

This section introduces key cloud networking concepts, including Virtual Private Clouds (VPCs), Subnets, Internet Gateways (IGWs), NACLs, and Security Groups. By the end, you'll have a solid understanding of how AWS networking works behind the scenes and how cloud resources communicate securely.

VPC: Virtual Private Cloud 🏢

A Virtual Private Cloud (VPC) is like having our own private room in the AWS cloud - isolated from other AWS users. Inside this room, we can place resources like EC2 instances, databases, and more. By default, we're allowed up to 5 VPCs per region, but this limit can be increased.

💡 Each resource inside a VPC needs a private IP address so it can be uniquely identified, to send/receive data, and to avoid IP conflicts.

When we create a VPC, we customise it by assigning:

A name (e.g. dev-vpc, prod-vpc)
An IPv4 CIDR block – this defines the number of private IP addresses available inside our VPC

Resources in our VPC must select an IP from one of the following private block address ranges to function accordingly (defined by RFC 1918):

10.0.0.0 to 10.255.255.255 (/8)
172.16.0.0 to 172.31.255.255 (/12)
192.168.0.0 to 192.168.255.255 (/16)

These private IP ranges allow for internal (non-public) communication between our resources. However, for a resource to access the internet, it must have:

A public IP
A connected Internet Gateway (IGW)
A route in the route table directing outbound traffic (e.g. 0.0.0.0/0) to the IGW

Example CIDR Breakdown

If we set our VPC's CIDR block to 10.0.0.0/18:

10.0.0.0 is the starting IP

The /18 means the first 18 bits of the 32-bit IP address are reserved for the NETWORK portion.

That leaves 14 bits (since 32 - 18 = 14) for the HOST portion — i.e. for AWS to allocate individual IP addresses to resources within the network.

We therefore get 2¹⁴ = 16,384 private IPs, ranging from 10.0.0.0 to 10.0.63.255

Please let me know if you would like more information on IP addresses in AWS. I appreciate it's a complex topic!

Subnets: Breaking VPCs into Zones

A Subnet is a smaller network inside our VPC that is tied to a specific Availability Zone (AZ). It is made by carving out portions of our VPC’s IP range and then assigning them to different AZs.

💡 So where a VPC exists within a single AWS region, a subnet exists within a single Availability Zone.

We use multiple subnets to separate and configure public-facing and internal-only resources. With route tables defining how traffic moves between subnets or out to the internet.

IGW: Internet Gateway 🌐

We have hinted at the IGW already, but to confirm, it is an AWS component that allows resources in our VPC to connect to the internet. It's not something we need to manage or worry about failing, as it is highly available and scales automatically!

For example, to enable internet access for an EC2 instance, we require just the following:

A public subnet
A public IP address
An IGW attached to our VPC
A route in our route table sending outbound traffic (0.0.0.0/0) to the IGW

💡 In AWS, there are two main ways to get a public IP address for EC2 instances and services that run on EC2 infrastructure:

(1) Automatically Assigned by AWS (Dynamic Public IP)

When we launch an EC2 instance in a public subnet, AWS can automatically assign a dynamic public IPv4 address. This public IP is ephemeral, meaning it changes whenever we stop and start the instance.

(2) Elastic IP Address (Static Public IP)

This is a static public IPv4 address that we allocate to our AWS account. We can attach/reattach it to an EC2 instance if and when required, and it is free only when we associate it with a running instance.

The diagram below highlights what a configured route table looks like behind the scenes!

Network Protection: NACLs vs. Security Groups 🔑

AWS offers two main layers of network protection, each with its own purpose that I believe are worth highlighting:

💡 Each subnet can only have one NACL attached to it, but one NACL can be shared across multiple subnets.

🎯 TL;DR

VPC creates our own private section of AWS cloud.
Subnets divide our VPC into public (internet-facing) and private sections.
Internet Gateway connects our VPC to the public internet.
Security Groups and NACLs control what traffic can reach our resources.

✨ This is part of a mini-series where I delve into everything cloud-related. Check out my other posts for further learning! ✨

Beginner's AWS Guide: Storage Services (Part 3)

Ayo — Fri, 08 Aug 2025 16:53:48 +0000

Objective:

This section builds upon a key component of servers - Storage as covered in the Beginner's AWS Guide: Virtual Servers (Part 2). Here, we delve into the available data storage services in AWS, including S3, EBS, and EFS.

S3: Simple Storage Service 🪣

Servers need a place to store and retrieve data, and in this case, AWS S3 is a very popular option. We can store and access many data types, including;

Images (JPG, PNG)
Documents (PDF, DOCX)
Videos (MP4, MOV)
Audio (MP3)
Static files (HTML, CSS, JS)

More precisely, S3 is an object storage service that allows us to store files (called objects) in buckets, which act like top-level folders, and to access objects directly via URL.

Each object can be up to 5TB in size, and buckets can hold an unlimited number of objects.

Each object consists of:

The data itself (e.g. a photo, video, document).
A unique key (how we identify it in the bucket).
Optional metadata (e.g. content type, author, timestamp).

💡 Each newly created bucket must have a globally unique name. When we create a bucket, it becomes part of a public web address (URL). Just like two websites can't share the same domain name, two S3 buckets can't have the same name, otherwise, AWS wouldn't know which bucket to route the request to!

EXAMPLE:

https://my-GLOBALLY-unique-bucket-name.s3.us-east-1.amazonaws.com/photo.jpg

We can make URL links publicly accessible or limit accessibility using bucket/object policies, which we cover in IAM and Security Fundamentals (Part 6).

S3 FAQs 🪣

✨ Q. Can we directly upload 5TB in one go? ✨

No. AWS limits a single PUT request per object to 5GB, so anything larger must use a multipart upload — splitting the file into parts that are uploaded separately.

✨ Q. Is S3 free? ✨

Not quite, but it's very low cost, and we only pay for what we use:

Storage used (GB/month)
Data transferred (in/out)

We can also enable Requester Pays, which charges users for downloading our data.

✨ Q. Does S3 come with additional features? ✨

Yes — AWS offers features to assist with our goals and objectives, including:

Cross-region replication
Access logging
Versioning
Lifecycle rules
Transfer Acceleration for faster uploads worldwide

These are advanced features that I can cover in future posts!

S3 Storage Classes 🪣

When we upload an object, it's stored in S3 Standard (General Purpose) by default. But S3 offers several storage classes to optimise cost and performance based on how frequently we access the data.

💡 Intelligent-Tiering is used if we’re unsure of access patterns. It will move objects between tiers automatically (for a small monitoring fee).

EBS Volume: Elastic Block Store 💽

Think of an EBS Volume as a cloud-based external hard drive (like a USB stick) that we can attach to EC2 servers. It gives us persistent storage, which survives even if we delete the server.

Just like physical drives, we can attach/detach EBS volumes from servers, format them, and use them to store logs, databases, or other data.

EBS volumes are created within a specific Availability Zone (AZ). We can attach/detach volumes between EC2 instances in the same AZ. But to move a volume to another AZ, we must:

Create a snapshot (a copy) of the volume.
Use the snapshot to create a new EBS volume in the target AZ.
And then attach our volume to another EC2 instance.

EBS: Volume Types 💽

AWS offers different volume types based on performance and price. We determine the type of volume we want based on the following:

Size (GB) — how much overall space we want.
Throughput (MB/s) — how much data can be read/written per second. A lower throughput means it takes longer to move large amounts of data, while higher throughput allows for faster bulk data transfers.
IOPS — how many read/write ops per second (important for database-style workloads). A Higher IOPS means our storage can handle more read/write operations per second, resulting in faster application performance.

💡 For further info on EBS Volume specs, please check out - https://digitalcloud.training/amazon-ebs/

EFS: Elastic File System 📠

Whereas S3 is object storage and EBS is block storage, EFS is network file storage - just like a regular file system on our computer.

💡 A file system is where we can store and access files in folders, and further place those folders inside other folders, and so forth.

EFS lets multiple servers simultaneously mount and access the same folder structure, which makes it perfect for shared storage scenarios (e.g. logs shared across multiple instances).

How EFS works

We create an EFS file system in AWS. AWS provides a DNS name (per file system, region, and VPC) to use for mounting.
We install the EFS utilities on our Linux EC2 instances, which let us communicate with the file system using the mount.efs helper.
We configure mount targets across Availability Zones within a VPC (one per subnet/AZ). This ensures EC2 instances in each AZ can access EFS with low latency.
Finally, we mount the file system using the DNS-based mount target.

EXAMPLE

# Example EFS Mount Target DNS
fs-12345678.efs.us-east-1.amazonaws.com

# Install EFS utilities (Amazon Linux)
sudo yum install -y amazon-efs-utils

# Make a directory on the EC2 instance to mount the EFS
sudo mkdir -p /mnt/efs

# Mount the EFS file system (with encryption in transit)
sudo mount -t efs -o tls fs-12345678.efs.us-east-1.amazonaws.com:/ /mnt/efs

# Once mounted, it's just a folder path!
# We can create directories and write files in EFS from the instance:

sudo mkdir -p /mnt/efs/app-logs
sudo mkdir -p /mnt/efs/shared-data
sudo mkdir -p /mnt/efs/backups

echo "log data" | sudo tee /mnt/efs/app-logs/app.log
sudo cp important-file.txt /mnt/efs/shared-data/

💡 EFS has different performance and throughput modes depending on our use case.

🎯 TL;DR

S3: Scalable object storage for files, accessible via URL — great for backups, media, and static content.
EBS: Block-level storage (like a cloud hard drive) attached to one server at a time.
EFS: Shared file system that multiple servers can access at once — perfect for collaboration and distributed workloads.
Choose storage based on how often, how fast, and by whom the data needs to be accessed.

✨ This is part of a mini-series where I delve into everything cloud-related. Check out my other posts for further learning! ✨

Beginner's AWS Guide: Virtual Servers (Part 2)

Ayo — Fri, 08 Aug 2025 16:53:11 +0000

Objective:

This section explores virtual servers in the cloud, and their role in cloud operations. Here, we dive into managing virtual servers using AWS's primary service, the Elastic Compute Cloud (EC2), along with Elastic Load Balancing (ELB) for distributing traffic and Auto Scaling Groups (ASG) for automatically managing server capacity.

EC2: Elastic Compute Cloud 💻

Amazon EC2 is a service that provides scalable virtual servers (called instances) in the cloud. These virtual servers run on physical hardware in AWS data centres, but we don't need to manage or buy the hardware itself.

Thanks to a software layer called a hypervisor, multiple virtual servers (EC2 instances), including those from different AWS customers, can run safely and independently on the same physical machine!

Simple Analogy:

The physical server is like a large apartment building.
Each EC2 instance (virtual server) is like a separate apartment unit.
The hypervisor is like the building manager who ensures each apartment is isolated, secure, and gets the right utilities (CPU, memory, etc.).

EC2: Instance Purchasing Options 💰

When we use EC2, we're renting virtual servers (compute power) from AWS. The base cost comes from AWS managing the physical servers, networking, and infrastructure behind the scenes.

However, on top of this, AWS offers different pricing models to suit varying budgets, workloads, and time commitments.

Here's a quick overview of the most common EC2 pricing models:

EC2: Instance Set Up 💻🛠️

To launch a virtual server (EC2 instance), we must first choose an Amazon Machine Image (AMI), which is basically a pre-configured template that includes:

The operating system (e.g., Ubuntu, Amazon Linux, Windows)
Pre-installed applications
Software configurations

Then, from this, we configure our instance by selecting the following components:

Image showing a chart of the EC2 instance type options with an accompanying description and mnemonic.

Simple Analogy: Launching an EC2 Instance is essentially like ordering a custom laptop!

AMI - Choosing our OS and default software
Instance Type - Selecting CPU/RAM (hardware specs)
Storage - Picking SSD/HDD or external drives
Security & Networking - Setting up Wi-Fi, firewall, and login password

💡 Golden AMI: Instead of manually configuring an AMI from scratch every time, we can save a customised AMI with all our preferred software and settings, and quickly configure an instance from it.

💡 User Data: We can also run custom setup scripts (process called bootstrapping) when our instance first launches, which helps with automation. Common examples include:

Installing packages
Downloading files
Starting apps or services

EC2: Connecting to our Instance 🔗

To securely log in to our EC2 instance, we need a key-pair, which is basically a secure digital password. Depending on the operating system and setup, we can connect using:

ELB: Elastic Load Balancing ⚖️

Elastic Load Balancing (ELB) is a fully managed AWS service that automatically distributes incoming traffic across multiple downstream server targets and IP addresses. Under ELB, there are 3 different types of load balancers with unique attributes (ALB, NLB, GLB).

Simple Analogy:

Imagine a busy supermarket with multiple checkout tills (servers).
Instead of everyone rushing to one till, a smart cashier (the ELB) routes each customer (user request) to the shortest available queue.
This keeps things flowing smoothly and prevents an overload on any one till.

Why Use an ELB?

Single Access Point: Clients connect to one DNS name (provided by the ELB), rather than targeting specific servers.
Traffic Distribution: Spreads traffic evenly across healthy servers, boosting performance.
Fault Tolerance: If one server fails, ELB redirects traffic to healthy ones.
Health Monitoring: ELB runs regular checks to ensure targets are responsive.

💡 We can map DNS names to a custom domain (e.g. myapp.com) using DNS records for user-friendly access.

ASG: Auto Scaling Groups 🔃

Auto Scaling Groups (ASG) are another free, managed AWS service that automatically launches or terminates EC2 instances based on real-time demand. This helps us with optimising costs and managing server availability!

How ASG Works:

We initially define rules like keep at least 2, but no more than 5 instances running.
ASG listens to CloudWatch metrics to make decisions. (Covered further in IAM and Security Fundamentals (Part 6)).
Based on demand(s), it automatically scales out (adds instances) or scales in (removes instances).

Essentially, AWS CloudWatch monitors metrics on our instance that we want to track. It then triggers an alarm when thresholds are breached, with ASG responding accordingly. For example, observable metrics could include:

CPU utilisation
Memory usage
Network traffic
Custom metrics (e.g. number of active users)

💡 ASG relies on a Launch Template that acts like a blueprint, defining exactly what type of EC2 instance to create and how to configure it, including the scaling strategy for when to add or remove instances.

🎯 TL;DR

EC2 provides virtual servers in the cloud that we can configure and control.
Choose instance types based on CPU, memory, and storage needs.
ELB spreads traffic across multiple servers for better performance.
ASG automatically adds/removes servers based on demand.
By combining EC2 + ELB + ASG, we create a resilient, scalable, and cost-efficient setup

✨ This is part of a mini-series where I delve into everything cloud-related. Check out my other posts for further learning! ✨

Beginner's AWS Guide: Cloud Computing (Part 1)

Ayo — Tue, 10 Jun 2025 15:52:58 +0000

About Me 👾

Hi, I'm Ayo – a self-directed developer from the UK, passionate about cloud and software engineering!

Whether you want to learn more about the cloud, are starting your cloud journey, or are looking to deepen your AWS knowledge, my goal with this series is to provide clear explanations that make topics surrounding the cloud more understandable.

I hope that by sharing how I've approached various concepts and AWS services, you'll find valuable takeaways for your own personal growth and development.

For context, I have achieved the following AWS certifications:

AWS Certified SysOps Administrator - Associate (SOA-C02)
AWS Certified Developer - Associate (DVA-C02)
AWS Certified Solutions Architect - Associate (SAA-C03)
AWS Certified Cloud Practitioner (CLF-C02)

If you find inspiration or develop a greater understanding of AWS Cloud from my work, please share with your wider network and leave a comment below! 😄

Objective:

This section introduces the fundamentals of cloud computing and its core infrastructure concepts. Here, we explore the different Cloud Service Models (IaaS, PaaS, SaaS), examine Server Architecture, and understand the AWS Global Infrastructure, including regions, availability zones, and local zones that form the backbone of modern cloud services.

Cloud Computing ☁️

Cloud computing is like renting equipment or services on demand instead of buying them outright. We can easily set up different services based on our requirements, and scale and measure our service usage.

Key cloud computing features to note:

Pay-as-you-go: We only pay for what we use.
Instant access: We obtain instant access to resources without having to set up hardware or services.
Everything-as-a-service: We have web access to services, including database servers, AI tools, computing services, and storage options.

Cloud Computing Models: IaaS, PaaS, SaaS ☁️

Not all cloud services work the same way. Some require more work from us, while others do more of the work for us. This is where cloud computing models come in — they help explain how much responsibility is ours versus what the cloud provider handles.

Here are the three main models:

As we move from IaaS to PaaS to SaaS, we trade control for convenience. IaaS gives us the most flexibility but requires the most technical expertise, whereas SaaS is the easiest to use but gives us the least customisation options!

Key IT Terminology: Servers 🖥️

A server is a physical or virtual computer with a unique IP address that stores, processes, and shares information. It responds to requests from other computers, known as clients, over a network (like the internet or through a private system).

While we use servers to host websites, run applications, store files, manage databases, etc, clients are devices that can request data from a server, for example, our phones and laptops.

And for both the client and server to successfully exchange information over a network, a server needs to implement a type of protocol like HTTP, FTP, or SMTP, which are essentially communication rules that must be followed.

In the Beginner’s AWS Guide: Virtual Servers (Part 2), we dive into virtual servers in the cloud and explore their role and significance in modern cloud computing.

AWS Global Infrastructure 🧱

AWS hosts physical servers in data centres worldwide, which are organised into Regions and Availability Zones (AZs):

A Region is a geographically distinct area, such as eu-west-1 (Ireland) or us-east-1 (N. Virginia).
Each Region contains multiple Availability Zones (AZs), which are isolated data centres (or groups of data centres) in that region. AZs help with fault tolerance and high availability.

Typically, each Region has at least 3 AZs, while some have up to 6!

When deciding where our server will physically run in the world, we must weigh several trade-offs, including:

Local Zones 🏡

Local Zones are smaller data centres placed in or near major cities to reduce network latency for end users. They essentially act as extensions of AWS Regions, allowing us to run certain AWS services closer to users.

💡 Remember, the closer our compute resources are to users, the faster and smoother their experience will be!

For example, we could have the region US-East-1 (US East, N. Virginia), with Local Zones placed in nearby cities such as Atlanta and Boston.

🎯 TL;DR

Cloud computing is like renting IT resources instead of buying them.
Instant access to servers, databases, and tools without hardware setup.
IaaS, PaaS, and SaaS offer different levels of management vs control.
AWS global infrastructure (Regions, AZs, Local Zones) provides worldwide availability and disaster recovery.

✨ This is part of a mini-series where I delve into everything cloud-related. Check out my other posts for further learning! ✨

Step 1: What you WANT to know about REACT.js

Ayo — Wed, 13 Sep 2023 15:13:04 +0000

React.js

What is it?

It's a front-end javascript library that helps us build user interface (UIs) by employing reusable components

FOR EXAMPLE

Let's say you're looking to build a city from scratch right? Now, to build a city you're going to need a few things. Let's say a park, some houses, a few skyscrapers, maybe a few pandas too from China etc;

(IT'S A WEIRD CITY, I KNOW!)

So:

UI = Our City
Reusable Components = Your individual park, house, skyscraper, panda components etc; etc;

Components in this manner are just building blocks that we can either create and/or import to help build our overall UI!!

And if you're STILL in doubt and someone asks you what React is, then just say its lego blocks but for computers 🤣 - hey, it worked for me!