DEV Community: Gerlie Ann Katherine Daga-as

Beyond the Default: Building a Cost-Optimized Hybrid AWS Architecture

Gerlie Ann Katherine Daga-as — Tue, 17 Mar 2026 04:51:52 +0000

In the world of AWS, "default" settings are often the fastest way to an expensive monthly bill. Recently, a Senior DevOps Engineer dropped a strategic hint on one of my posts that challenged the standard EC2-only approach:

"Lightsail is cheaper for the public-facing interface. You don't get much CPU, but enough SSD for cache. Then connect to your EC2."

I didn’t just read the comment. I built the system myself. I used AWS Lightsail for predictable costs and EC2 for extra computing power, creating a setup that greatly reduces Data Transfer Out (DTO) costs.

The "Aha!" Moment: Fighting the $0.09/GB Trap

Most developers realize too late that AWS charges roughly $0.09 per GB for outbound data from EC2 (after the first 100GB). If your site pushes 1TB of traffic, that’s roughly a $90 bill for bandwidth alone.

That’s when the "Aha!" moment hit me: AWS Lightsail isn’t just for beginners. Its $5/month plan includes 1TB of outbound data transfer. By using Lightsail as an Nginx reverse proxy, you’re essentially buying a "bandwidth insurance policy."

The strategy: route public-facing traffic through the Lightsail “front door” and keep the connection to your EC2 backend over a Lightsail VPC peering connection. This traffic stays on AWS’s private network, keeping your costs predictable while shielding your backend from the public internet.

The Build & Technical Insights

Compute Strategy: Optimized Frontend, Scalable Backend
Frontends rarely need heavy CPU. Lightsail’s burstable CPU is perfect for an Nginx reverse proxy, while EC2 handles the heavy lifting. Use Auto Scaling Groups and instance types optimized for your workload to ensure backend performance without overpaying for the frontend.
Networking: The VPC Peering Bridge

Setting up Lightsail → EC2 connectivity requires a VPC peering connection. Key detail: both route tables need manual updates:

Lightsail Side: Add a route for the EC2 VPC CIDR pointing to the peering connection.
EC2 Side: Add a route for the Lightsail VPC CIDR pointing back. This ensures traffic flows privately between Lightsail and EC2.

. Troubleshooting Masterclass: Traceroute is King

When initial curl requests timed out, I didn’t guess I traced the packets:

traceroute 172.31.x.x

Packets left the instance but died after two hops, revealing a routing table gap rather than a misconfigured Nginx. One command saved me an hour of troubleshooting.

Production Optimizations

Web Server & Static Assets

OpenLiteSpeed (OLS): For WordPress or PHP apps, OLS handles concurrent users better than Apache and is more resource-efficient.
CloudFront: Offload static assets to a CDN. Free tier: 1TB per month for the first 12 months. Reduces load on your Lightsail proxy.

Security & Traffic Management

Cloudflare: DNS, WAF, and DDoS protection hide your Lightsail public IP and add resilience.
TLS Termination: Offload HTTPS at Cloudflare or Lightsail to reduce backend CPU usage.

Email & Notifications

AWS SES: Send up to 62,000 free emails/month from EC2 instances during the free tier perfect for transactional mail and app notifications.

Hardware Efficiency

ARM (t4g / Graviton2): ~20% better price-to-performance than x86 Intel for many workloads.
AMD (t3a): ~10% cheaper than Intel for x86 workloads sensitive to micro-latency.

With this setup (Cloudflare + CloudFront + Lightsail + EC2 + SES), you can run a robust, scalable stack for ~$15/month, assuming moderate traffic and efficient use of free tiers.

Production Readiness Notes

Monitoring & Logging: Use CloudWatch for EC2 metrics and Lightsail logs. Monitor Nginx access/error logs.
High Availability: Lightsail is single-AZ. For mission-critical apps, consider multi-region failover.
Auto Scaling: Keep EC2 backends in Auto Scaling Groups to handle traffic spikes.
Backup Strategy: Snapshot EC2 and Lightsail instances regularly.

Conclusion

This project proved that in DevOps, curiosity pays off. A single comment led me to a hybrid architecture that optimizes costs, improves scalability, and demonstrates professional-grade cloud engineering. Thank you sir Harith!

I’ve documented the full lab guide, including the Nginx configs and peering steps, in my GitHub repository here: aws-lightsail-nginx-lab

Breaking Free from "Click-Ops" with Terraform

Gerlie Ann Katherine Daga-as — Mon, 22 Dec 2025 10:10:41 +0000

Today marks the beginning of my #30daysofawsterraform challenge! I spent Day 01 diving into the fundamentals of Infrastructure as Code (IaC) with Piyush Sachdeva.

If you've ever spent hours clicking through the AWS Console only to realize you made a typo in a security group, this journey is for you.

📺 Reference Video

🏗️ What is Infrastructure as Code (IaC)?

In simple terms, IaC is the process of managing and provisioning your technology stack through software (code) rather than manual hardware configuration or interactive configuration tools.

Why do we need it?

Piyush explained a scenario that really hit home: The Scalability Trap.
Manual Setup: Provisioning a 3-tier app (Web, App, DB) takes ~2 hours.
The Problem: In an enterprise, you need multiple environments (Dev, SIT, QA, Prod).
The Math: 2 hours x 6 environments = 12 hours of manual clicking!

🔑 Key Takeaways from Day 01

Eliminating Configuration Drift: Manual setups lead to "it works in Dev but not in Prod." Terraform ensures every environment is an exact replica of the code.

The Power of Git: Because infrastructure is code, we can store it in GitHub. This gives us a history of every change made to our cloud.

Speed: With one command, we can spin up or destroy entire environments. This is a lifesaver for saving costs on non-prod environments.

🐧 My Linux Setup

Since I am using a Linux machine for this challenge, I spent today getting my environment ready. Here is how I set up Terraform:

Installation (Ubuntu/Debian) I followed the official HashiCorp steps to add the repository and install the CLI:

# Install dependencies
sudo apt-get update && sudo apt-get install -y gnupg software-properties-common

# Add HashiCorp GPG key
wget -O- https://apt.releases.hashicorp.com/gpg | \
gpg --dearmor | \
sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg

# Add the repository
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list

# Install Terraform
sudo apt-get update && sudo apt-get install terraform

Verification To make sure everything was correct, I ran:

terraform -version

Productivity Hack: Alias A great tip for Linux users—adding an alias to save time:

alias tf='terraform'
# Now I can just type 'tf init' instead of the full word!

⚙️ The Terraform Workflow

I learned that Terraform doesn't just "do it." It follows a logical path:

tf init: Initializes the working directory and downloads providers.
tf plan: The "Preview" mode. It shows you what will happen before you commit.
tf apply: Executes the code and creates the resources in AWS.
tf destroy: Cleans up everything to avoid unnecessary AWS bills.

Final Thoughts

Day 01 was all about the "Why." Understanding that Terraform is a tool for reliability and consistency is the foundation for everything else we will learn. I'm ready for Day 02!

Let's Connect!

If you're also taking the #30daysofawsterraform challenge, let's connect!
LinkedIn: Profile link

Mastering Cloud Security: A Strategic Guide to Securing Your AWS Environment

Gerlie Ann Katherine Daga-as — Wed, 17 Dec 2025 02:53:06 +0000

In today’s digital landscape, a single security breach can be catastrophic leading to data loss, financial impact, and reputational damage. For developers and cloud engineers, security cannot be an afterthought; it must be the foundation upon which we build.

As I deepen my focus on cloud security, I’ve synthesized the core pillars of a secure AWS environment. Whether you are launching your first EC2 instance or architecting a complex microservices application, these are the actionable steps effectively used to secure the cloud.

1. The Foundation: Understanding the Shared Responsibility Model

The most common misconception in cloud computing is assuming that "being on the cloud" means you are automatically secure. It is crucial to understand the Shared Responsibility Model.

Think of your cloud environment like a boat.

AWS (The Provider) is the Captain. They ensure the boat is seaworthy, the engines run, and the hull is intact. They are responsible for the security of the cloud (physical data centers, cabling, and virtualization hardware).
You (The Customer) are the Passenger. Once you are on the boat, your safety is your responsibility. You must wear a life jacket and follow the rules. You are responsible for security in the cloud (your customer data, identity management, operating systems, and firewall configurations).

If the boat sinks, that’s on AWS. If you trip and fall because you weren't careful, that is on you. Understanding where the line is drawn whether you are using IaaS, PaaS, or SaaS is the first step to a secure architecture.

2. The Gatekeeper: Strong Identity and Access Management (IAM)

If your AWS account is a building, IAM is the security system at the front door. It controls who enters, which elevators they can use, and which rooms they can unlock.

To effectively manage identity, follow these three rules:

Enforce MFA (Multi-Factor Authentication): A password is a key that can be stolen. MFA is biometrics or a code that proves you are who you say you are. Enable this immediately for the root user and all IAM users.
Principle of Least Privilege: Do not give everyone the "Master Key." Give users the absolute minimum permissions required to do their job. If an account is compromised, this limits the blast radius.
Role-Based Access Control (RBAC):Assign permissions to roles (e.g., "Developer," "Admin," "Auditor") rather than individual users. This keeps your permissions clean and manageable as your team scales.

3. Fortifying the Architecture: Network Security

Imagine your AWS network as a bustling city. You don't want unauthorized traffic wandering into residential neighborhoods.

Virtual Private Cloud (VPC): This is your gated community. It isolates your resources from other tenants.
Segmentation:Divide your "city" into districts using Subnets. Keep public-facing web servers in a Public Subnet (Downtown) and sensitive databases in a Private Subnet (Residential).
Security Groups & NACLs:
- Security Groups act as the doorman for specific buildings (instances), controlling traffic at the resource level.
- **Network Access Control Lists (NACLs) **act as checkpoints between districts, controlling traffic at the subnet level.
WAF (Web Application Firewall): For public-facing resources, a WAF acts as border control, inspecting incoming traffic to block SQL injection, cross-site scripting, and other common web exploits.

4. Locking the Safe: Data Encryption

Data is the gold inside your city. You must protect it whether it is sitting in a vault or being transported in an armored truck.

Encryption in Transit: Use HTTPS/TLS for all data moving across networks. This prevents interception.

Encryption at Rest: Encrypt your data where it is stored (S3 buckets, EBS volumes, RDS databases).
Key Management: utilize AWS KMS (Key Management Service). Ideally, use Customer Managed Keysrather than AWS-managed keys. This ensures you retain control over the keys to your data, allowing you to rotate them regularly for enhanced security.

5. The Watchtower: Monitoring and Logging

You cannot protect what you cannot see. A secure environment requires constant vigilance.

Enable Logging: Turn on logging for all critical resources (CloudTrail for API calls, VPC Flow Logs for network traffic).
Centralize and Analyze: Don't let logs sit in silos. Aggregate them in a central location.
Automate Alerts:Use tools (like AWS CloudWatch or SIEM solutions) to detect anomalies. If a root user logs in from an unknown IP at 3 AM, you should receive an alert immediately not find out about it two weeks later during an audit.

Securing the cloud is not a "one-and-done" task; it is a continuous cycle of assessment, monitoring, and improvement. By implementing a strong foundation based on the Shared Responsibility Model and rigorously applying best practices in IAM, Network, Encryption, and Monitoring, you can build with confidence.

As I continue my journey in the AWS ecosystem, these principles remain my North Star. Security isn't just about preventing hacks; it's about enabling innovation safely.

Want to Go Deeper? Check These Out 👇

AWS Shared Responsibility Model https://aws.amazon.com/compliance/shared-responsibility-model/
AWS Well-Architected Framework (Security Pillar) https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html
IAM Best Practices https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
VPC Security Best Practices https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html
AWS KMS Best Practices https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html
Logging & Monitoring on AWS https://docs.aws.amazon.com/whitepapers/latest/logging-monitoring-aws/welcome.html

Practical Cloud Security Wins for New AWS Teams (Even If You’re Just Getting Started)

Gerlie Ann Katherine Daga-as — Mon, 01 Dec 2025 09:35:57 +0000

What if cloud security didn’t have to feel overwhelming? You don’t need a huge budget, a full security team, or a complicated architecture to feel confident about your AWS setup. These small, highly-impactful wins work extremely well for early-stage teams just starting their cloud security journey

AWS provides built-in, cost-efficient services for early visibility into potential issues. Enable these at minimum:

Turn On the Security Tools AWS Already Gives You

CloudTrail: Records every API change across your account. Huge value
GuardDuty: Continuously monitors your environment and excels at identifying suspicious or malicious events.
IAM Access Analyzer: Helps you spot unintended public access, cross-account sharing, or overly open policies

These detect unusual login attempts, risky IAM permissions, public resources, and strange network behavior problems many teams skip until too late

Stop Leaving Resources Public by Accident

Accidental exposure like public buckets or open ports causes most beginner breaches. Prevent them with these fixes:

Turn on S3 Block Public Access (this alone prevents SO many issues)
Add a deny rule for 0.0.0.0/0 on sensitive ports
Tighten your default VPC Security Group instead of leaving it open
These guardrails catch "oops" moments before they become incidents.

Audit Your IAM Access

IAM feels intimidating, but start with visibility via IAM Access Advisor. Check for:
Roles unused for 90+ days
Roles with wildcard admin (:) permissions.
Service accounts that don’t need programmatic access anymore.
Removing old roles and rotating access keys reduces massive risk with small effort

Secure Your Developer Workstations

Cloud breaches often start on developer laptops deploying to AWS. Set this minimum baseline:
Enable MFA for AWS logins
Use password managers.
Require disk encryption (BitLocker, FileVault).
Use a hardware key or authenticator app.
Attackers steal credentials from endpoints more than breaking into AWS directly.

Encrypt Everything

Enable encryption at rest on EBS, RDS, S3, EKS volumes.
Require TLS 1.2+ on ALBs.
Use customer-managed KMS keys for sensitive workloads. It provides an essential safety net if compromise occurs. ###Clean Up Unused Resources (A Security + Cost Win) Unused resources remain unpatched, forgotten, and exposed. Add monthly housekeeping:
Delete unused IAM roles
Remove abandoned EC2 instances.
Clean up old S3 buckets.
Purge leftover AMIs and snapshots. This dual win improves security and cuts costs.

Document Your Cloud and Decisions (The Habit That Prevents Future Mistakes)

Security isn’t just tools and configs it’s knowing why things exist and how they’re meant to behave. Keep lightweight documentation for:

Which IAM roles exist and their intended purpose
What each S3 bucket is used for
Networking decisions (e.g., why a port was opened)
Diagrams of environments and cross-account access
Runbooks for onboarding/offboarding developers

Have Something to Add?

Cloud security is huge and these are just the lightweight, high-impact wins that early-stage teams can adopt quickly.

If you use other simple practices that have helped your AWS security posture, drop them in the comments!
I’d love to hear what tools, guardrails, or habits you found effective.

References & Further Reading

"Building a Serverless Image Processing Pipeline with AWS Lambda, S3, and API Gateway"

Gerlie Ann Katherine Daga-as — Thu, 19 Dec 2024 13:16:23 +0000

In this blog, we’ll explore how to build a serverless image processing pipeline using AWS Lambda, Amazon S3, and API Gateway. We will walk you through the technical details, provide relevant code snippets, and include architectural diagrams to make the explanation clear and easy to follow.

By the end of this blog, you'll understand how these AWS services work together to process images uploaded to an S3 bucket, resize the images, and make them available via a RESTful API powered by API Gateway.

Prerequisites
Before diving into the setup, make sure you have:

An AWS account (if you don’t, you can sign up for the free tier)
Basic understanding of AWS Lambda, API Gateway, and Amazon S3
Familiarity with AWS IAM (Identity and Access Management) roles and policies
An editor for writing Python or Node.js code (we’ll use Python in this example)

1._ Frontend (Client):_ A client (such as a web app or mobile app) sends an HTTP request to the API Gateway endpoint, which will trigger an AWS Lambda function.

API Gateway: API Gateway serves as a frontend interface to handle the HTTP requests from the client and forwards them to the Lambda function.
AWS Lambda: The Lambda function receives the image from the client, processes it (resizing, compressing), and stores it back to an S3 bucket.
Amazon S3: The resized image is stored in an S3 bucket.
CloudWatch Logs: CloudWatch is used to log events, such as successful image processing or errors.

Step-by-Step Implementation

Setting Up an S3 Bucket for Image Uploads
First, we need to create an S3 bucket where images will be uploaded.
1. Log into the AWS Management Console and go to the S3 service.

2.Click Create Bucket, and give it a name like serverless-bucket-uploaded-images

3.In the Bucket Settings, ensure versioning is enabled (this helps with version control of uploaded images).
4.Set permissions for the bucket (for security, it’s recommended to restrict public access unless necessary).

Once the bucket is created, it will be used to store the original images and the resized ones.

Creating an AWS Lambda Function to Process Images
Next, let’s create the Lambda function that will process the images uploaded to the S3 bucket.
1. Go to AWS Lambda and click Create Function.
2. Select Author from Scratch, name your function (e.g., ImageResizeFunction), and choose Python latest version as the runtime. 3.For the execution role, select an existing role or create a new one with the following policies:
  - AmazonS3FullAccess (to access S3 objects)
  - AWSLambdaBasicExecutionRole (to enable CloudWatch logging) Now, let's write the code to resize the uploaded image using Python. We'll use the Pillow library for image processing, so the first step is to add the library to the Lambda deployment package.

pip install pillow -t ./lambda-package

import boto3
from PIL import Image
from io import BytesIO

def lambda_handler(event, context):
    # Extract bucket and object key from the event
    bucket_name = event['Records'][0]['s3']['bucket']['name']
    object_key = event['Records'][0]['s3']['object']['key']

    s3 = boto3.client('s3')

    # Get the original image from S3
    original_image = s3.get_object(Bucket=bucket_name, Key=object_key)
    image_data = original_image['Body'].read()

    # Process the image (resize)
    image = Image.open(BytesIO(image_data))
    image = image.resize((200, 200))  # Resize to 200x200 pixels

    # Save the resized image to a new S3 object
    output_key = f"resized/{object_key}"
    buffer = BytesIO()
    image.save(buffer, 'PNG')
    buffer.seek(0)

    s3.put_object(Bucket=bucket_name, Key=output_key, Body=buffer)

    return {
        'statusCode': 200,
        'body': f"Image {object_key} resized and saved as {output_key}"
    }

Explanation of the Lambda function:

The function triggers whenever an image is uploaded to the S3 bucket (as part of an event notification).
It fetches the image from S3, resizes it using the Pillow library, and then stores the resized image back into a separate resized/ folder in the S3 bucket.

3. Setting Up API Gateway to Trigger Lambda
Now, let's set up an API Gateway to receive HTTP requests from the frontend (e.g., a web or mobile app) to trigger the image upload.

Go to API Gateway in the AWS Console and create a new REST API.
Create a new resource (e.g., /upload-image) under the API.
Under this resource, create a POST method
In the Integration type, select Lambda Function and choose the ImageResizeFunction Lambda function you just created.
_Enable CORS _if you want to allow requests from web browsers.
Deploy the API to a new or existing stage. Once the API is deployed, you’ll receive an API endpoint URL that the frontend can use to trigger image uploads.

4. Testing the Entire Flow

1.Upload an image to the S3 bucket through your frontend, which sends a POST request to the API Gateway endpoint.
2. The API Gateway triggers the Lambda function.
3. Lambda resizes the image and saves it back to S3 under the resized/ folder.
4. You can check the resized image in the S3 bucket and monitor the Lambda function’s logs in CloudWatch.

Best Practices and Considerations

Error Handling: Implement proper error handling in the Lambda function (e.g., try/except blocks) to log and handle potential failures.
Lambda Timeout: Set an appropriate timeout for your Lambda function (e.g., 3–5 seconds for resizing).
Security: Use fine-grained IAM roles for Lambda functions and S3 buckets to limit access only to necessary resources.
Scalability: Lambda automatically scales to handle multiple requests, but ensure the S3 bucket is correctly configured to handle large traffic loads.

AWS Lambda offers a powerful and efficient way to run code in response to events without the need to manage servers. By combining Lambda with other AWS services like S3 and API Gateway, you can build scalable, event-driven applications with minimal overhead. Whether you’re processing images, handling webhooks, or automating tasks, Lambda simplifies infrastructure management and reduces operational complexity.

As serverless technologies continue to evolve, AWS Lambda remains a key tool for modern cloud applications. Start small with a simple use case, and explore how you can scale and optimize your serverless architecture as your needs grow.

Additional Resources

AWS Lambda Documentation Lambda Documentation
Amazon S3 Documentation: S3 Documentation
API Gateway Documentation:API Gateway Documentation

If something is missing or you have any suggestions, feel free to let me know in the comments section below!