DEV Community: Ashwarya

My First Time Putting an App on AWS (A Beginner's Story)

Ashwarya — Sun, 16 Aug 2026 12:29:39 +0000

Today I did something I've wanted to do for a while — I took an app running on my own laptop and put it "live" on the internet using AWS. It sounds scary when you read about it online, but once I actually did it, it was just a bunch of small, simple steps, one after another.

This post is me writing down everything I did, in plain, easy words, so that if you're a beginner like me, you can follow along without getting confused by fancy tech terms.

What is AWS, in simple words?
AWS (Amazon Web Services) is basically Amazon renting out computers over the internet. Instead of buying your own physical server and keeping it running 24/7 at home, you "rent" a computer from Amazon. That computer runs your app, and anyone with the internet can visit it.
The specific service I used is called EC2. Think of EC2 as one virtual computer that lives in Amazon's data center, and you get to control it like it's your own.

Step 1: Set up IAM first

Before touching any servers, I went to IAM (Identity and Access Management). This is AWS's way of managing "who is allowed to do what" in your account.

In simple words: instead of using your main AWS login for everything (which is risky), IAM lets you create a separate user with its own permissions. It's like giving someone a spare key instead of your master key. I set this up first so my account stays safer.

Step 2: Launch an EC2 instance

Next, I went to the EC2 section and launched a new instance (a fancy word for "a virtual computer"). During this step, AWS also lets you create a .pem file — this is basically a secret key file. It's like a digital key to a lock. Only someone with this file can get into the server. I downloaded it and kept it safe, because if you lose it, you can't easily get back in.

Step 3: Login to the server using SSH

Once the server (EC2 instance) was ready, I needed a way to "log in" to it from my own laptop. For that, I used something called SSH, along with the .pem key file I downloaded earlier.

In simple words: SSH is like a secure phone call between your laptop and the AWS server, and the .pem file is the password that proves it's really you calling.

Once connected, my laptop's terminal was now basically "inside" the AWS computer. Anything I typed from here on ran on the AWS server, not my own laptop.

Step 4: Update the server

The very first thing to do on a fresh server is:

sudo apt update

In simple words: this just checks for the latest versions of software so everything installed after this is up to date. Think of it like checking for updates before installing new apps on your phone.

Step 5: Install the dependencies

Next, I installed the "dependencies" — these are just the extra tools and programs my app needs to actually run (things like Node.js, npm, git, etc., depending on the app). Without these, the app's code would have nowhere to run, kind of like trying to play a video game without installing the game console first.

Step 6: Bring the code onto the server

To get my actual project code onto this AWS server, I used:

git clone

This downloads a copy of my project (that was sitting on GitHub) directly onto the AWS server. Now the server has all my app's files.

Step 7: Set up the .env file (the secret settings file)

Most apps need some private settings — like passwords, API keys, or database links — that should never be shared publicly on GitHub. These usually go in a file called .env.

Here's exactly what I did:

touch .env

This creates a new, empty file named .env.

ls -a

This lists all files, including hidden ones (files starting with a dot are hidden by default), just to confirm .env was really created.

vim .env

This opens the file in a text editor called Vim, right inside the terminal.

Inside Vim, I pressed i to switch into "insert mode" (this lets you actually type text — Vim doesn't let you type by default, which confused me at first). Then I typed in my credentials (my secret settings, like API keys).

After typing everything, I pressed Esc to leave insert mode, then typed :x and hit Enter. This saves the file and closes Vim.

In simple words: Vim feels strange the first time because you can't just start typing like Notepad — you have to "unlock" typing mode with i, and then "save and exit" with a special command. It trips up almost every beginner once.

Step 8: Open the door — editing the Security Group

Even after all this, my app still wasn't visible on the internet. That's because AWS blocks all traffic by default, for safety. You have to manually tell AWS which "doors" (ports) are allowed to be opened.

Here's what I did:

Went to my EC2 instance page.
Clicked on the Security tab.
Clicked Edit inbound rules.
Added a new rule and set the port to 3000 (since that's the port my app runs on).
Saved the rule.

In simple words: a "port" is like a specific door number on the server. My app was listening on door number 3000, but AWS had that door locked. This step unlocked it so people from outside could knock and get in.

Step 9: The moment it goes live

After all that, I just opened a browser and typed:

:3000

And there it was — my app, running live on the internet, for anyone in the world to open.

What I learned

Honestly, none of these steps were individually hard. What made it feel scary before doing it was not knowing the order things happen in, and not knowing what each command actually does. Once I understood that:

IAM is about who can access what
EC2 is just a rented computer
SSH + .pem is how you securely log into that computer
The .env file holds your app's secrets
The Security Group is basically a locked door that you have to manually open

...it all made a lot more sense. If you're trying this for the first time, don't worry about memorizing every command. Just understand what each step is trying to do, and the commands will make sense on their own.

Security Principles:

Ashwarya — Thu, 17 Oct 2024 07:27:27 +0000

When evaluating the security of a system, we use the CIA triad: confidentiality, integrity, and availability.

Confidentiality: Only authorized people can access the data.
Integrity: Data cannot be changed without detection.
Availability: The system is accessible when needed.

Examples:

Online Shopping:

Confidentiality: Credit card info is kept secret.
Integrity: Shipping address cannot be altered.
Availability: The website/app is up and running.

Patient Records:

Confidentiality: Medical records are kept private by law.
Integrity: Records are accurate to ensure correct treatment.
Availability: Records are accessible during medical visits.

Sometimes, one aspect is more important than the others, like the integrity of a university announcement being critical.
Beyond CIA, two additional aspects are:

Authenticity: Data is genuine and from the claimed source.
Non repudiation: The source cannot deny their actions.

Examples:

Online Shopping: Confirm the order is real and the customer cannot deny placing it.
Large Orders: Ensure the order is authentic and the sender cannot deny it.

Parkerian Hexad adds two more elements to CIA:

Utility: Data must be useful (e.g., encrypted data is useless without the key).
Possession: Prevent unauthorized control of data (e.g., backups or ransomware).

In simple terms, security is about keeping data private, accurate, accessible, genuine, and ensuring it cannot be denied or taken without permission.
System security can be attacked by revealing, changing, or destroying data. These are the opposites of the CIA triad: confidentiality, integrity, and availability.

Disclosure (opposite of confidentiality): Revealing secret data.
Alteration (opposite of integrity): Changing data.
Destruction/Denial (opposite of availability): Making data or systems unavailable.

Examples with patient records:

Disclosure: If medical records are stolen and made public, it’s a confidentiality attack.
Alteration: If medical records are changed, wrong treatments might be given.
Destruction/Denial: If systems are made unavailable, a medical facility can’t access patient records, stalling operations.

Balancing protection against disclosure, alteration, and destruction is crucial. Focusing too much on one can harm the others. Good security practices require a balance between confidentiality, integrity, and availability. To ensure the security of a system, we can use different security models that focus on confidentiality, integrity, or both.

Bell-LaPadula Model (Confidentiality):

Simple Security Property: "No read up" – can't read data at a higher security level.
Star Security Property: "No write down" – can't write data to a lower security level.
Discretionary-Security Property: Uses an access matrix to control read/write operations.

Biba Model (Integrity):

Simple Integrity Property: "No read down" – can't read data from a lower integrity level.
Star Integrity Property: "No write up" – can't write data to a higher integrity level.

Clark-Wilson Model (Integrity):

Constrained Data Item (CDI): Important data whose integrity must be protected.
Unconstrained Data Item (UDI): All other data.
Transformation Procedures (TPs): Operations to maintain CDI integrity.
Integrity Verification Procedures (IVPs): Checks to ensure CDI integrity. These models help protect data through rules about reading and writing based on security and integrity levels

Extras

The ISO/IEC 19249:2017 standard by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) outlines architectural and design principles for secure products, systems, and applications. The five architectural principles are:

Domain Separation: Grouping related components as single entities with common security attributes.
Layering: Structuring systems into layers to impose and validate security policies at different levels.
Encapsulation: Hiding low-level implementations and preventing direct data manipulation, using methods or APIs.
Redundancy: Ensuring availability and integrity through backup systems, like dual power supplies or RAID configurations.
Virtualization: Sharing hardware among multiple OSes, providing sandboxing for security.

The five design principles are:

Least Privilege: Granting the minimal necessary permissions for tasks.
Attack Surface Minimization: Reducing vulnerabilities by disabling unnecessary services.
Centralized Parameter Validation: Ensuring input validation is centralized to prevent exploitation.
Centralized General Security Services: Centralizing security services, like authentication, to enhance security.
Error and Exception Handling: Designing systems to handle errors safely, preventing information leakage and ensuring secure failure states.

These principles guide the development of secure systems by emphasizing structured, validated, and minimalistic approaches to security.

To avoid confusion, note these three terms:

Vulnerability: A weakness susceptible to attack or damage.
Threat: A potential danger associated with a vulnerability.
Risk: The likelihood of a threat exploiting a vulnerability and the resulting impact on the business.