Restrict access to RShiny dashboard hosted on EC2

Question

I have built and tested a RShiny dashboard locally on my computer. I would like to host this dashboard on an AWS EC2 instance. I am comfortable spinning up the instance and getting the files transferred. My concern is how to restrict access to this dashboard to users at my organization. In addition I would like to have a more informative url (I assume this means digging into DNS, but not sure how to go about it).

Answer 1

Since your post doesn't provide much detail regarding any existing infrastructure you may (or may not have) in AWS, I'll assume none and give you the high-level approach I'd take to host your app net-new:

• Build a VPC in which to host your instance.
  • A VPC will generally have public and private subnets. I would recommend creating your EC2 instance in a private subnet proxied behind an Application Load Balancer that exists in public subnets.
• Create a Route53 public hosted zone. You can do this for a domain you already own, or you can purchase the domain directly through AWS.
• Within the Route53 hosted zone, create a record for the DNS name you'd like to use for your Shiny app that points to your load balancer.
• I would recommend adding a security group for your load balancer that restricts incoming traffic to the egress IPs of your organization (and, add a security group to the instance itself that only allows traffic from the load balancer).
• Use the AWS ACM service to create a certificate for the DNS name you assign to your app, assign the certificate to the load balancer listener that your app is listening on, and map public-facing port 443 on your load balancer to your app's port on the EC2 via target group. Disable incoming traffic on other ports.
• For the Shiny app itself, you will want to add some sort of authorization/authentication (i.e. AuthN/AuthZ). I would take a look at shinyauthr. If that doesn't work, try another (I'm not a shiny programmer, so I can't offer a lot here, but please don't skip this -- you'll need this security for your application).

This is a high-level playbook only. There are tons of details you'll need to work out as you go through the process (e.g. VPC network design [CIDRs, subnet sizes, # of availability zones used, etc.], how you manage the EC2 [create an AMI, use an empty AMI and just SSH your files up, git-clone the files onto the instance, etc.]).

Additionally, this post doesn't address more advanced techniques of resource management such as infra-as-code approaches (e.g. Cloudformation, Terraform, etc.), but this is something you should consider.

Lastly, while your question mostly focused on AWS, please do consider the deeper aspects of AuthN/AuthZ within your application itself, particularly if this dashboard is hosting sensitive data. Also, consider any administrative interfaces within your shiny application and make sure the AuthN/AuthZ solution offers adequate protection of these interfaces such that your other users won't be able to access them.

A few other closing thoughts... There are other ways to do this. For instance, you could:

• Use a site-to-site VPN from your corporate network into your AWS VPC, but I would regard this as more complicated (and likely expensive) from a networking standpoint and will require the assistance of your organization's enterprise networking team.
• Host a VPN solution within the VPC to provide private network access to the VPC, but this would require you to create VPN users and possibly manage local clients for all your users.
• Skip all the public ingress (i.e. load balancer, DNS, security groups, certificates) from the EC2 using something like ngrok, but this will depend on your appetite for using such a third-party service.
• While you specifically mentioned EC2, AWS Lightsail offers VM-based hosting also. Your certificate management becomes something you'll have to manage on-instance (but doable with something like certbot). Using Lightsail would let you bypass the VPC and load balancer setup (thought Lightsail does offer load balancers), while still giving you some decent network controls (though not as fine-grained as those in EC2/VPC). You'd still need Route53 for a DNS zone if you went this route, as well.

In my opinion, if you are just getting into networking into AWS, the VPN solutions will be messy and more complicated than the setup I detailed above, but I did want to address them for the sake of completeness. The "tried-and-true" approach of a load balancer will work for your use-case, albeit this will be a bit complicated if you don't have any familiarity with the underlying networking concepts.