Why You Should Delete the Default AWS VPC
The default AWS VPC is fine for kicking the tires. For a real company environment, it is too open, too generic, and too easy to misuse.
The default AWS VPC is good for quick testing, but it is not a good foundation for a company environment.
By default, AWS creates a VPC with 172.31.0.0/16, public subnets in each Availability Zone, an Internet Gateway, and a route to the internet. The default subnets are usually /20, which means thousands of IP addresses per subnet.
This is too open and too generic for production.
A company should build its own VPC with a clear network design. Public subnets should be used only for resources that really need public access, such as load balancers. Application servers should be placed in private subnets, and databases should be placed in isolated subnets.
Subnets should also be sized correctly. Creating very large subnets creates unnecessary noise, wastes IP space, and makes the environment harder to manage.
Deleting the default VPC helps reduce mistakes, prevents accidental public exposure, and forces a cleaner cloud network design that matches the company’s real security and operational needs.
Docker Compose Does Not Automatically Use the GPU
On Linux GPU servers, Docker Compose does not use the NVIDIA GPU automatically. The service starts, nothing obviously fails, and the workload quietly falls back to CPU. The fix is a few lines in the compose file, but only if you know to look for them.
Read article
Docker Default Runtime: Keep GPU Containers on NVIDIA
On Linux GPU servers, Docker can know about the NVIDIA runtime and still not use it. If default-runtime is missing from daemon.json, every container falls back to runc, nvidia-smi fails inside the container, AI workloads drop to CPU, and the problem looks like an application issue when it is really a one-line configuration gap.
Read article