- Newest
- Most votes
- Most comments
Hello.
How about using CloudFront's VPC origin?
Using this function, you can set an EC2 instance placed in a private subnet as the origin.
You can place EC2 in a private subnet to prevent direct access from outside.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html
https://aws.amazon.com/jp/blogs/aws/introducing-amazon-cloudfront-vpc-origins-enhanced-security-and-streamlined-operations-for-your-applications/
You can also use SSH to connect to an OS in an EC2 instance placed in a private subnet by using Systems Manager Session Manager or EC2 Instance Connect Endpoint.
https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/connect-to-an-amazon-ec2-instance-by-using-session-manager.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-with-ec2-instance-connect-endpoint.html
To improve the security of your setup while maintaining simplicity, consider the following best practices:
1. Move EC2 to a Private Subnet:
- Place your EC2 instance in a private subnet within your VPC.
- This prevents direct public access to your instance.
- Use CloudFront's VPC Origin:
2. Configure CloudFront to use your EC2 instance in the private subnet as the origin.
- This allows CloudFront to securely communicate with your application without exposing it publicly.
- Restrict Access to EC2:
3. Configure the EC2 security group to allow inbound traffic only from CloudFront.
- Use AWS-managed prefix lists for CloudFront to easily set up this restriction.
- Secure SSH Access:
4. Instead of opening port 22 to the internet, use AWS Systems Manager Session Manager for SSH access.
- This allows secure access without exposing SSH ports publicly.
- HTTPS Communication:
5. Configure CloudFront to use HTTPS for both viewer and origin connections.
- This ensures end-to-end encryption of your traffic.
6. Custom Origin Port:
- Configure CloudFront to communicate with your origin on port 8000 where your application is running.
These changes will significantly improve your security posture while maintaining the simplicity of your setup.
Hello! Your current architecture might work for testing or low-traffic environments, but aws recommends some best practices to make it more secure and production-ready.
1. Private subnet for EC2: If your ec2 doesn't need to be publicy exposed, the best practice is to move it to a private subnet. External access should go through CloudFront (optionally via a Load Balancer), and the instance can access the internet via a Nat Gateway for updates or downloads.
2. Restrict access to ec2: To ensure that only cloudfront can access your application, you can configure the Ec2 security group to allow inbound traffic only from the ip or security group of the Load Balancer or CloudFront.
3. Secure SSH access:: Avoid exposing port 22 to the internet. Use AWS System Manager Session Manager to access the instance via the console, without needing a public ip or ssh access.
4. High availability and scalability (optional): If your application requires high availability, consider using an Auto Sacling Group (ASG) across at leat two AZ's, adding an Application Load Balancer (ALB) and running multiple Ec2 instances for automatic failover.
So, you need to carefully consider all these points and evaluate whether your application requires auto-scaling, redundancy, or if CloudFront's latency is acceptable. Depending on your answers, these features can introduce additional costs. That’s why it’s crucial to ask yourself these questions when designing your architecture.
Relevant content
asked 2 years ago
asked 5 years ago
- AWS OFFICIALUpdated 4 months ago

This is the great solution (VPC origin), good documents. Thank you!