I am currently creating a service like Mercari, and I have some questions about the infrastructure configuration in the environment construction section.
The server will use AWS.
The infrastructure configuration that we are considering in the future will be as follows.

The location of the "management screen" is missing now.
With the assumption that the service built with Laravel can be put on the place where it is made public on the "Web page", I was thinking easily to install the management screen on another EC2 instance.

The reason is that it was not recommended in terms of security when receiving a free consultation from AWS to place a management screen in the Web service, and it is visually recognized that the public side and the management side are separated after hearing the story Because I thought it was high. .
However, in this case, even if the same DB is viewed when creating the management screen with Laravel, I feel that it will not be possible to maintain consistency unless it matches the Laravel on the public side, such as the model, and it will be double management and operation I feel serious.
Is it better to create a management screen in one application?
Can you give us some opinions on whether there is a good way to maintain consistency by putting the management screen on another server?

I have been doing programming for a long time, but it would be helpful if I could give advice at the level where I started studying around the infrastructure.
By the way, the development environment is also used for studying, and we are building a separate EC2 instance and building it without using ELB.
Thanks for your cooperation.

  • Answer # 1

    What are you trying to manage on the management screen?
    If you look at the same DB, I don't think so much, but what does the integrity you care about specifically mean?
    If it is consistent in DB migration, I think that there is no problem if the source that moves when accessed by the user is placed on the WEB server and the method for DB migration can be managed properly.

    I agree and should separate the management screen from the web server.

  • Answer # 2

    >Even if you look at the DB, I feel that it is not possible to maintain consistency unless it matches the Laravel on the public side such as the model, and I feel that the operation becomes difficult because it becomes double management Doing.

    For this, you should use the deployment tool and take measures such as enabling or disabling management functions in the environment.


    Can you give us your opinion on whether there is a good way to maintain consistency by putting the management screen on another server?

    I think you should use a deployment tool. (It would be eb for AWS, but if you don't use EB, I don't feel the benefits of AWS.)

  • Answer # 3

    It feels more like app design than infrastructure.

    Several application-like solutions have already come out.

    Turn all EC2 to the private subnet, and if EC2 Internet connection is required, set NAT gateway, NAT instance, or Proxy that also serves as Bastion to the public subnet.
    With ALB as the front, access to the front web and management screen is separated by L7 by routing the target group.

    For example, if you want to route all/admin access to the management instance, route to the management instance with the/admin condition and use the same routing condition to the sorry page of the S3 static page for when the management instance is down. But with Redirect, all the remaining accesses are routed to the Web side.

    Turn EC2 to the private subnet to prevent access from being written directly to hosts.

    I think that it can be separated into an instance for the management screen and an instance for the front web with a single application. Even if there is a management screen function on the Web instance side, access does not occur.
    Depending on the conditions set for the target group, it will work even if they are mixed, but in terms of security, it will decrease somewhat.
    Since it can be shared with EFS, it will be easy to prepare AutoScaling.

    For ssh, if you have a Bastion or NAT instance, go there, and if you have a NAT gateway, do it per Client VPN.