DEV Community: Baraa Mohamed

Saving Plan vs Reserved Plan

Baraa Mohamed — Tue, 11 Aug 2026 15:42:51 +0000

If you're not picturing the difference — say you have one m5.large server on on-demand, you'd pay $840.96 over a year compared to:

If you go Reserved, the price could drop to $235.47
If Savings Plan, it could get down to $285.93

But these numbers obviously aren't fixed, they depend on when you reserve, the region, and so on.

Reserved Instances (RIs)?

Allow you to reserve EC2 capacity for 1 or 3 years in exchange for a discount of up to 72% compared to On-Demand pricing.

🔹 Types of Reserved Instances:

Standard RIs: The highest discount, but you have to be committed to a specific instance type, meaning you're confident about the load that'll be on that instance for the whole long period you're reserving it for. And if you want to get rid of them, you'll have to list them for sale on the RIs Marketplace
Convertible RIs: Lower discount than the one above, but gives you the chance to switch between instance types, on condition that the final cost ends up equal to or higher than what was originally agreed

What Are AWS Savings Plans?

More flexible alternative to Reserved Instances, offering up to 72% savings in exchange for a commitment to a minimum spend per hour for 1 or 3 years.

🔹 Types of Savings Plans:

Compute Savings Plans: Let the discount apply across more than one service — Lambda, EC2, Fargate
EC2 Instance Savings Plans Lock you into a specific family and region, but you can change the instance type within the same family freely

If we notice, we'll find that both options let you change the instance type you're using, so why do we say the savings plan is more flexible?

Reserved is basically a promise you make to AWS, so even if the plan type was Convertible RIs, even if you wanted to change the server type you'd have to send an exchange request that's manual and wait for it to get approved so the discount applies to it, otherwise you'll get charged on-demand.

The Savings Plan is more automatic because it focuses on the amount you spend more than what you're actually using, so if you change the instance or the service, e.g. from ec2 to Fargate, it'll look at your spending from, say, the last hour, and start checking what's supported, and if the discount applies to it, it'll save you more.

What do you pick?

✅ Reserved Instances if:

✔️ Your load is predictable during the plan period so you won't need to change the instance much.
✔️ You'll only use EC2 instances

✅ Savings Plans if:

✔️ You'll be using something from EC2, Fargate, and Lambda
✔️ You need the discount to focus on your spending, not what you're actually using

(1) Question: Since Compute Savings Plans has a more flexible option, does that make it better than Reserved?

No, because yes you have flexibility, but you might not need it if you know your load is constant or that you don't need anything beyond EC2 — in that case RIs would be more suitable and the discount reaches 72% instead of 66%

(2) Question: So if I don't need other services and I have two options with the same 72% discount, which are EC2 Instance Savings Plans and RIs, what do I choose based on?

The idea of the Savings Plan is that you become flexible, yes, but if there's a specific server type you know you need in a specific zone that might not be available later — say if the servers were stopped for a while and you started them again, or you're doing scaling —

Then the most suitable option is Zonal-Reserved, because it'll always keep the capacity you requested set aside for you until you need it

🤍 I would appreciate If we connect together on LinkedIn : Visit

Identity-based Policy, Service Control Policy, Resource-based Policy, Permissions Boundary 😵‍💫

Baraa Mohamed — Tue, 11 Aug 2026 15:38:53 +0000

Identity-based Policy, Service Control Policy, Resource-based Policy, Permissions Boundary 😵‍💫

All of these are terms related to permissions you deal with on AWS, but what's the difference between them?

First, they're split into two types:

Granting Permission: Identity-based Policy, Resource-based Policy
Guardrail Permissions: Service Control Policy, Permissions Boundary

💰 Think of it like an ATM machine: the Guardrail sets the overall allowed permissions for the ATM (the upper ceiling), and the Granting is what actually gives you the right to execute the action.

Identity-based Policy

Gets attached to the user or role or group itself, and defines what they're allowed to do on which service.

Real example: a user with a policy that allows them s3:GetObject and s3:PutObject on any bucket.

💰 Like when you open a bank account, the bank activates certain services on your card: (you're allowed to withdraw, transfer, and pay online).

Service Control Policy (SCP)

Works at the AWS Organizations level (Org / OU / Account) and defines the maximum possible permissions — even if the identity policy allows it, if the SCP blocks the action it won't execute.

Real example: a company has an Organization with Dev and Prod accounts, and has an SCP on the Prod OU that blocks anyone (even admins) from doing s3:DeleteBucket or leaving the Organization, to protect the data from being deleted by mistake.

💰 Like the bank preventing any branch from allowing withdrawal in any currency other than Egyptian pounds, no matter what permissions the employee doing the withdrawal has.

Resource-based Policy

Gets placed on the resource itself (not the user), and must have a "Principal" specifying who's allowed to interact with it. Supported in S3, SNS, SQS, Lambda, KMS, and others.

Real example: a bucket called global-bucket with a policy that allows a specific group of accounts to read the data

💰 Like a specific ATM machine that's only linked to VIP accounts, and anyone else with a regular card won't be able to withdraw from it even if they have withdrawal permission in general.

Permissions Boundary

Defines the maximum possible permissions for a specific IAM user or role (i.e. individually, not across multiple accounts like SCP).

Real example: a DevOps team gives every developer permission to create new IAM roles for their projects, but sets a Permissions Boundary on them that prevents them from granting themselves or any role they create admin-level permissions like iam:* or organizations:*, so no one can do privilege escalation on themselves.

💰 Like a father giving his son a card linked to his own, but setting limits on the spending that can be withdrawn from the card, and it can't be exceeded.

Note: for any action to go through, it must not be denied in any of the intersecting policies, because a Deny from any single one of them is enough to stop the action ❌.

🤍I would appreciate If we connect together on LinkedIn : Visit

RBAC & Admission Controllers

Baraa Mohamed — Tue, 11 Aug 2026 15:30:52 +0000

So now you've set up your cluster and everything's working fine — what's stopping the junior devops guy from taking down production completely innocently 😇

This is where a Kubernetes feature comes in that adds a security layer to define the types of actions that can be taken in your cluster

So basically, what's the difference between RBAC and Admission Controllers

1️⃣ RBAC:

You use it to define the types of commands each role is allowed to use, and it has two types based on scope

1️⃣ Namespace scoped "kind: Role"

For example you could block any create/delete command for the junior devops in the production namespace

2️⃣ Cluster scoped "kind: ClusterRole"

For example you can define permissions at the whole Cluster level, not a specific Namespace — block the junior from deleting any Node at the cluster level.

How do you confirm this?

kubectl auth can-i <command> <resource>

kubectl auth can-i delete namespaces

2️⃣ Admission Controller:

Adds more details that you can't express in RBAC, which is why it's a layer that comes after it

For example:

Restrict to a specific Registry: block any Pod from being created if its Image is coming from outside the company's Private Registry

Force the team to set Resource Limits: reject any Deployment that doesn't specify cpu and memory (Requests & Limits).

Prevent using the latest tag: reject any Container filled in with a Tag like image:nginx:latest.

📌 You might need to install an add-on like Kyverno or OPA Gatekeeper

Examples of my own implementations: Github

🤍** I would appreciate If we connect together on LinkedIn :** Visit

Rename Any Text Across Multiple Files with One Command! 🔍🔄

Baraa Mohamed — Tue, 10 Dec 2024 14:58:24 +0000

I’ve come into situation before while I was building Employee Management System Full-stack website, Where I needed to change name of variable and some functions but the issue was that they are used in many files.

For them being used in multiple files it wasn’t logically to manually detect them in each file and replace them.

One solution I found is using Linux commands :

find . \( -path "./node_modules"  \) -prune -o -name "*.js" -exec sed -i "s/old_text/new_text/g" {} +

find : is used to find certain files, here we use it to find all .js files
 : the backslashes are used for Linux to execute what’s inside instead of giving an error
-path : To specify certain path which we will prune
-prune : To ignore certain paths from this command’s execution
-o : Is or option so if left side is executed ( which is ignoring “node_modules” ) we skip executing rest of command after -o .
-name "*.js" : to find any file that is .js when it’s not “node_modules” folder.
-exec sed : To execute replacing command which is sed.
-i : to actually change text in file.
{} is a placeholder for the file or directory name that the find command matches.
+ : Called batch mode tells find to pass multiple matched files to the command in batches instead of running the command once per file.

Usage Example

I have 2 test.js files one of them is in “node_modules” folder, Both of them has text “baraa mohamed”.

So we execute following command.

find . \( -path "./node_modules"  \) -prune -o -name "*.js" -exec sed -i "s/baraa/XBaraaX/g" {} +

After execution result of test.js outside “node_modules” :

XBaraaX mohamed

Also after executing we find test.js inside “node_modules” :

baraa mohamed

As you can see it did not change as we pruned ( ignored ) the whole “node_modules” directory.

🤍 I'd love to connect with you on LinkedIn—let's grow our network and share ideas! here

NAT Gateway VS Internet Gateway? 🤔

Baraa Mohamed — Tue, 10 Dec 2024 08:00:38 +0000

This is usually the very first question that pops up when designing AWS networking. 🤔 Let’s break it down using this architecture:

🟣 Internet Gateway (IGW)
Think of the Internet Gateway as your VPC’s front door to the public internet. It handles both inbound and outbound traffic, acting as the target in your route tables for public subnet traffic.

Scope & Limits: You attach one IGW per VPC.

💰 Cost: The gateway itself is completely free—you only pay for standard AWS outbound data transfer.

🟣 NAT Gateway
What if you have instances in a private subnet that need internet access to pull security patches or dependencies—without exposing them to external threats? That’s where the NAT Gateway comes in. It translates private IP addresses to allow outbound-only connectivity.

💡 Key Distinction: "Outbound-only" means connections must originate from inside your private subnet. While return traffic from your requests is allowed back in, external users on the internet can never initiate a new connection directly to your private instances through a NAT Gateway. (If users need to access your app via a browser, that inbound flow is handled by an Application Load Balancer not the NAT Gateway).

Placement & Scope: A NAT Gateway must be placed inside a public subnet so it can route through the IGW. So, NAT Gateways are zonal resources—for high availability across Availability Zones, you should deploy one in a public subnet within each AZ.

💰 Cost: AWS charges for NAT Gateways per hour (for provisioning) plus a per-GB data processing fee on all data transferred through it.

Why Use It:

Enhanced Security Posture: Keeps workloads isolated while maintaining outbound access.

Allows private application servers to run apt update, fetch dependencies, or call third-party APIs safely.

🟣 How to Access Your Private Instances (Bastion Host)
Since private servers aren't directly reachable from the internet, you'll use a Bastion Host (jump box) pattern to connect:

SSH into your public instance inside the public subnet (the Bastion server).

From the Bastion, initiate a second SSH connection into your target instance inside the private subnet (Private App).

Because both subnets are inside the same VPC, AWS routes this traffic internally via the local VPC router.

The NAT Gateway is completely bypassed. The request never leaves the VPC, never touches the internet, and never hits the NAT Gateway.

To Implement that ssh access approach please check that blog: visit

Quick Summary
Internet Gateway (IGW): Inbound & Outbound | 1 per VPC | Free gateway

NAT Gateway: Outbound-only | Zonal (1 per AZ for HA) | Paid hourly + per GB

Let's connect on LinkedIn to share cloud engineering insights and grow our networks!

SSH Tunnel: Forwarding Traffic between hosts

Baraa Mohamed — Tue, 26 Nov 2024 14:25:29 +0000

In cloud environments, you might encounter scenarios where you need to forward traffic securely between hosts. SSH tunneling, also known as port forwarding, is a technique that allows you to create a secure communication tunnel between two hosts over specific ports.

What is SSH Tunneling?

SSH tunneling enables secure access to remote services that are not directly accessible. For instance, you can access a private service on a cloud server through a public host. This approach helps maintain security by keeping sensitive services private.

Example: Accessing Jenkins Dashboard on AWS

Suppose you have Jenkins running on an EC2 instance in AWS, and you want to access its dashboard on port 8080. Using SSH tunneling, you can securely forward traffic from your local machine to the Jenkins instance.

Pre-requisites:

Ensure the Jenkins EC2 instance allows TCP traffic on port 8080 and HTTP traffic in its security group.
Have the access key for the Jenkins EC2 instance.

Command to Create the Tunnel:

ssh -i <access-key> -L <your-host-port>:<Jenkins-ip>:<Jenkins-port> <public-Jenkins-instance>

Example:

ssh -i "myKey.pem" -L 4040:localhost:8080 ubuntu@ec2

Explanation of Flags:

i: Includes the access key file required for authentication.
L: Specifies the local port (4040), remote host (localhost or the private IP of Jenkins), and remote port (8080) for the tunnel.
localhost: Refers to the Jenkins instance. SSH forwards traffic to port 8080 on the Jenkins EC2 instance.

Accessing Jenkins Locally

After running the command, open your browser and navigate to http://localhost:4040. You should see the Jenkins dashboard, as traffic on port 4040 of your machine is securely forwarded to port 8080 on the EC2 instance.

Conclusion

By leveraging SSH tunneling, you can securely access remote services like Jenkins dashboards without exposing them to the public internet. This technique is versatile and applicable to many cloud-based workflows.

🤍 I'd love to connect with you on LinkedIn—let's grow our network and share ideas! here

SSH-Agent: Simplifying SSH Key Management

Baraa Mohamed — Tue, 26 Nov 2024 14:24:22 +0000

SSH-Agent is one of the tools in the SSH suite that simplifies managing access keys for secure server connections.

You can think of the SSH-Agent as a "bag" that holds your access keys, allowing you to access servers conveniently through other servers.

Starting the SSH-Agent

Begin by running the following command to start the SSH-Agent:

eval "$(ssh-agent -s)"

This initializes the agent — think of it as "opening the bag."

Adding Access Keys

Next, add your access keys to the agent. Each key represents a credential for accessing different servers:

ssh-add <file1>
ssh-add <file2>
ssh-add <file3>

This is like placing keys into your bag.

Connecting to Servers

To connect to a server using a specific access key:

ssh -v -i <access-key1> -A <server1>

v: Verbose mode — displays loading steps in the terminal (optional).
i: Specifies the access key file for authentication.
A: Forwards the SSH-Agent, allowing access to additional servers without re-entering keys.

Accessing Additional Servers

If you need to SSH from server1 to server2, simply run:

ssh -v -i <access-key2> <server2>

Add the -A flag only if you plan to SSH further from server2.

Best Practices

Use ssh-add to securely load private keys into the agent.
Forward the SSH-Agent (A) only when necessary to minimize security risks.
Regularly clean up your agent by running ssh-add -D to remove all keys after your session.

Conclusion

By using SSH-Agent, you can simplify secure server access while reducing repetitive key management tasks.

🤍 I'd love to connect with you on LinkedIn—let's grow our network and share ideas! here

Accessing EC2 In Private Subnet | Bastion | VPC | AWS

Baraa Mohamed — Tue, 26 Nov 2024 14:20:55 +0000

Accessing Private EC2 Instances in AWS: A Guide

Cloud architectures commonly use public and private subnets to balance accessibility and security. Public subnets host resources like bastion hosts or load balancers, while private subnets house sensitive workloads such as application servers. This setup ensures a secure environment, as private EC2 instances are only accessible through specific configurations.

Two Approaches to Access Private EC2 Instances

Depending on your requirements, you can access an EC2 instance in a private subnet through one of two methods: SSH access or traffic forwarding.

Method 1: SSH Access to a Private EC2

This method is ideal for performing configurations or debugging directly on the private EC2 instance.

Steps:

Start the SSH-Agent to manage your private keys:
```
eval "$(ssh-agent -s)"
```
Add the private EC2 key to the agent:
```
ssh-add <file-key-of-private-app>
```
Connect to the bastion host in the public subnet, forwarding the SSH-Agent:
```
ssh -v -i <file-key-of-bastion> -A <public-instance>
```

From the bastion host, SSH into the private EC2:

ssh -v -i <file-key-of-private-app> <private-instance>

By forwarding the agent (-A), you securely authenticate to the private instance without transferring your private keys.

Method 2: Port Forwarding

If you need to access a service (e.g., Jenkins) running on the private EC2, port forwarding allows you to securely forward traffic through the bastion host.

Example: Forwarding Jenkins Dashboard

Start the SSH-Agent and add the private key:

eval "$(ssh-agent -s)"
ssh-add <file-key-of-private-app>

Forward traffic from port 8080 on the private EC2 to port 4040 on your local machine:

ssh -v -i <file-key-of-bastion> -A -L 4040:<ip-of-private-jenkins-ec2>:8080 <public-instance>

Open http://localhost:4040 in your browser to access the Jenkins dashboard.

Note:

To retrieve the Jenkins setup password, use:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

This approach avoids exposing Jenkins to the internet, improving security.

Best Practices

Use SSH-Agent to securely store keys during your session.
Enable agent forwarding (A) only when necessary to minimize security risks.
Clean up your SSH session by removing keys after use:
```
ssh-add -D
```

Conclusion

With these methods, you can securely access private EC2 instances while maintaining a robust and secure cloud architecture.

🤍 I'd love to connect with you on LinkedIn—let's grow our network and share ideas! here