August 22, 2025 marked an important milestone for Haposoft with the official opening of our new office in Hanoi. This move represents the next step in our growth, creating a modern workspace designed to meet the team’s evolving needs. Sharing this milestone together made the day truly memorable and set the stage for the stories still to come. Welcoming Partners from Near and Far Partners from Vietnam, Hong Kong, and Japan came together for Haposoft’s grand opening, each representing markets that matter most to the company. Those who couldn’t attend sent flowers and warm wishes, a quiet reminder of the support surrounding Haposoft. Their presence set the tone for the day, celebrating these connections and the shared goals that continue to guide the company forward. Throughout the day, we guided our guests through the office, explaining each area and introducing them to the teams behind their projects. These interactions offered insight into the company’s vision and reinforced the strength of each partnership. The combination of presence, dialogue, and shared focus underscored the global connections that continue to shape Haposoft’s journey. Highlights from the Celebration The celebration officially kicked off with a ceremonial wine toast. Glasses were raised high as partners, guests, and Haposoft team members joined together in marking this milestone. The moment set an uplifting tone, symbolizing new opportunities and the shared journey ahead. Our CEO then took the stage to reflect on Haposoft’s growth and aspirations: “After five years of growing in the Japanese market and expanding to Germany and Singapore, we set a vision to become a world-class IT solution company. To achieve that, we defined three pillars: expanding to new markets, becoming a strategic development partner, and delivering solutions powered by cutting-edge technology.” His speech emphasized the vision that continues to drive the team — expanding beyond borders, strengthening partnerships, and delivering solutions that matter. Adding to the excitement, a representative from the Hong Kong market shared their congratulations and heartfelt words. Their speech highlighted the strength of collaboration and the trust built over the years, reinforcing the importance of Haposoft’s global partnerships. The formal ceremony flowed into a more relaxed atmosphere with desserts, coffee, and casual conversations. Guests mingled, reconnected, and exchanged ideas, making the gathering not just a celebration but also a meaningful networking opportunity. The lively spirit carried through the rest of the day, leaving lasting memories for all who attended. Our Journey and Brand Refresh This new office is not just a change of address; it is part of a larger story. In 2022, Haposoft defined a clear vision: expand beyond Japan, become a strategic development partner worldwide, and continue to build solutions powered by new technology. By early 2025, we realized the need for a space that could match that ambition. The decision was made to move into the NHS Complex — giving our team a place to feel inspired and confident. Alongside this move, we also refreshed our brand identity to align with our vision. And as part of that refresh, our happy owl — a symbol that has been with Haposoft since the early days — officially became our company mascot.  Capturing the Spirit in Our Grand Opening TVC To bring the story to life, we premiered the Haposoft Grand Opening TVC during the event. The short film highlighted our journey, our people, and the values that continue to guide us. It was a reminder that while a new office provides walls and desks, it is people, ideas, and shared values that make it meaningful.   Gratitude and the Road Ahead The Haposoft Grand Opening was more than a celebration — it was a reflection of how far we have come and what we are building for the future. We extend our heartfelt thanks to our customers and partners for their trust, to our team for making this move possible, and to everyone who joined us for making the day unforgettable. This new space is only the beginning. With the continued support of our community, we look forward to creating more solutions, more partnerships, and more milestones in the years ahead.  

A well-built AWS VPC creates clear network boundaries for security and scaling. When the core layers are structured correctly from the start, systems stay predictable, compliant, and easier to operate as traffic and data grow. What Is a VPC in AWS? A Virtual Private Cloud (VPC) is an isolated virtual network that AWS provisions exclusively for each account—essentially your own private territory inside the AWS ecosystem. Within this environment, you control every part of the network design: choosing IP ranges, creating subnets, defining routing rules, and attaching gateways. Unlike traditional on-premise networking, where infrastructure must be built and maintained manually, an AWS VPC lets you establish enterprise-grade network boundaries with far less operational overhead. A well-designed VPC is the foundation of any workload deployed on AWS. It determines how traffic flows, which components can reach the internet, and which must remain fully isolated. Thinking of a VPC as a planned digital neighborhood makes the concept easier to grasp—each subnet acts like a distinct zone with its own purpose, access rules, and connectivity model. This structured layout is what enables secure, scalable, and resilient cloud architectures. Standard Architecture Used in Real Systems When designing a VPC, the first step is understanding the core networking components that every production architecture is built on. These components define how traffic moves, which resources can reach the Internet, and how isolation is enforced across your workloads. Once these fundamentals are clear, the three subnet layers—Public, Private, and Database—become straightforward to structure. Core VPC Components Subnets The VPC is divided into logical zones: Public: Can reach the Internet through an Internet Gateway Private: No direct Internet access; outbound traffic goes through a NAT Gateway Isolated: No Internet route at all (ideal for databases) Route Tables: Control how each subnet sends traffic: Public → Internet Gateway Private → NAT Gateway Database → local VPC routes only Internet Gateway (IGW): Allows inbound/outbound Internet connectivity for public subnets NAT Gateway: Enables outbound-only Internet access for private subnets Security Groups: Stateful, resource-level firewalls controlling application-to-application access. Network ACLs (NACLs): Stateless rules at the subnet boundary, used for hardening VPC Endpoints: Enable private access to AWS services (S3, DynamoDB) without traversing the public Internet. Each component above plays a specific role, but they only become meaningful when arranged into subnet layers. IGW only makes sense when attached to public subnets. NAT Gateway is only useful when private subnets need outbound access. Route tables shape the connectivity of each layer. Security Groups control access between tier to tier. This is why production VPCs are structured into three tiers: Public, Private, and Database. Now we can dive into each tier. Public Subnet (Internet-Facing Layer) Public subnets contain the components that must receive traffic from the Internet, such as: Application Load Balancer (ALB) AWS WAF for Layer-7 protection CloudFront for global edge delivery Route 53 for DNS routing This ensures inbound client traffic always enters through tightly controlled entry points—never directly into the application or database layers. Private Subnet (Application Layer) Private subnets host the application services that should not have public IPs. These typically include: ECS Fargate or EC2 instances for backend workloads Auto Scaling groups Internal services communicating with databases Outbound access (for package updates, calling third-party APIs, etc.) is routed through a NAT Gateway placed in a public subnet.  Because traffic can only initiate outbound, this layer protects your application from unsolicited Internet access while allowing it to function normally.  Database Subnet (Isolated Layer) The isolated subnet contains data stores such as: Amazon RDS (Multi-AZ) Other managed database services This layer has no direct Internet route and is reachable only from the application tier via Security Group rules: This strict isolation prevents any external traffic from reaching the database, greatly reducing risk and helping organizations meet compliance standards like PCI DSS and GDPR. AWS VPC Best Practices You Should Apply in 2025 Before applying any best practices, it’s worth checking whether your current VPC is already showing signs of architectural stress. Common indicators include running out of CIDR space, applications failing to scale properly or difficulty integrating hybrid connectivity such as VPN or Direct Connect. When these symptoms appear, it’s usually a signal that your VPC needs a structural redesign rather than incremental fixes. To address these issues consistently, modern production environments follow a standardized network layout: Public, Private Application, and Database subnets, combined with a controlled, one-directional traffic flow between tiers. This structure is widely adopted because it improves security boundaries, simplifies scaling, and ensures compliance across sensitive workloads. #1 — Public Subnet (Internet-Facing Layer) Location: Two subnets distributed across two Availability Zones (10.0.1.0/24, 10.0.2.0/24) Key Components: Application Load Balancer (ALB) with ACM SSL certificates AWS WAF for Layer-7 protection CloudFront as the edge CDN Route 53 for DNS resolution Route Table: 0.0.0.0/0 → Internet Gateway Purpose: This layer receives external traffic from web or mobile clients, handles TLS termination, filters malicious requests, serves cached static content, and forwards validated requests into the private application layer. #2 — Private Subnet (Application Tier) Location: Two subnets across two AZs (10.0.3.0/24, 10.0.4.0/24) Key Components: ECS Fargate services: Backend APIs (Golang) Frontend build pipelines (React) Auto Scaling Groups adapting to CPU/Memory load Route Table: 0.0.0.0/0 → NAT Gateway Purpose: This tier runs all business logic without exposing any public IPs. Workloads can make outbound calls through the NAT Gateway, but inbound access is restricted to the ALB. This setup ensures security, scalability, and predictable traffic control. #3 — Database Subnet (Isolated Layer) Location: Two dedicated subnets (10.0.5.0/24, 10.0.6.0/24) Key Components: RDS PostgreSQL with Primary + Read Replica Multi-AZ deployment for high availability Route Table: 10.0.0.0/16 → Local   (No Internet route) Security: Security Group: Allow only connections from the Application Tier SG on port 5432 NACL rules: Allow inbound 5432 from 10.0.3.0/24 and 10.0.4.0/24 Deny all access from public subnets Deny all other inbound traffic Encryption at rest (KMS) and TLS in-transit enabled Purpose: Ensures the database remains fully isolated, protected from the Internet, and reachable only through controlled, auditable application-layer traffic. #4 — Enforcing a Secure, One-Way Data Flow No packet from the Internet ever reaches RDS directly. No application container has a public IP. Every hop is enforced by Security Groups, NACL rules, and IAM policies. Purpose: This structured, predictable flow minimizes the blast radius, improves auditability, and ensures compliance with security frameworks such as PCI DSS, GDPR, and ISO 27001. Deploying This Architecture With Terraform (Code Example) Using Terraform to manage your VPC (the classic aws vpc terraform setup) turns your network design into version-controlled, reviewable infrastructure. It keeps dev/stage/prod environments consistent, makes changes auditable, and prevents configuration drift caused by manual edits in the AWS console. Below is a full Terraform example that builds the VPC and all three subnet tiers according to the architecture above. 1. Create the VPC Defines the network boundary for all workloads. 2. Public Subnet + Internet Gateway + Route Table Public subnets require an Internet Gateway and a route table allowing outbound traffic. 3. Private Application Subnet + NAT Gateway Allows outbound Internet access without exposing application workloads. 4. Database Subnet — No Internet Path Database subnets must remain fully isolated with local-only routing. 5. Security Group for ECS Backend Restricts inbound access to only trusted ALB traffic. 6. Security Group for RDS — Only ECS Allowed Ensures the database tier is reachable only from the application layer. 7. Attach to ECS Fargate Service Runs the application inside private subnets with the correct security boundaries. Common VPC Mistakes Make (And How to Avoid Them) Many VPC issues come from a few fundamental misconfigurations that repeatedly appear in real deployments. 1. Putting Databases in Public Subnets A surprising number of VPCs place RDS instances in public subnets simply because initial connectivity feels easier. The problem is that this exposes the database to unnecessary risk and breaks most security and compliance requirements. Databases should always live in isolated subnets with no path to the Internet, and access must be restricted to application-tier Security Groups. 2. Assigning Public IPs to Application Instances Giving EC2 or ECS tasks public IPs might feel convenient for quick access or troubleshooting, but it creates an unpredictable security boundary and drastically widens the attack surface. Application workloads belong in private subnets, with outbound traffic routed through a NAT Gateway and operational access handled via SSM or private bastion hosts. 3. Using a Single Route Table for Every Subnet One of the easiest ways to break VPC isolation is attaching the same route table to public, private, and database subnets. Traffic intended for the Internet can unintentionally propagate inward, creating routing loops or leaking connectivity between tiers. A proper design separates route tables: public subnets route to IGW, private subnets to NAT Gateways, and database subnets stay local-only. 4. Choosing a CIDR Block That’s Too Small Teams often underestimate growth and allocate a VPC CIDR so narrow that IP capacity runs out once more services or subnets are added. Expanding a VPC later is painful and usually requires migrations or complex peering setups. Starting with a larger CIDR range gives your architecture room to scale without infrastructure disruptions. Conclusion A clean, well-structured VPC provides the security, scalability, and operational clarity needed for any serious AWS workload. Following the 3-tier subnet model and enforcing predictable data flows keeps your environment compliant and easier to manage as the system grows. If you’re exploring how to apply these principles to your own infrastructure, Haposoft’s AWS team can help review your architecture and recommend the right improvements. Feel free to get in touch if you’d like expert guidance.