AWS Global Accelerator provides a pair of static anycast addresses you can use to route trafic to region closest to client and while doing so get extra fault tolerance and DDoS protection for your application infrastructure. Recently it was announced you can also preserve client IP address to Application Load Balancer;

We are pleased to announce that starting today, your applications running on Application Load Balancers (ALB) fronted by AWS Global Accelerator can see the original source IP address of the client. This enables you to apply client-specific logic such as IP address or location-based filters by using AWS WAF, as well as gather connection statistics and serve personalized content for your applications. Additionally, you can front an internal ALB with Global Accelerator. This lets you use Global Accelerator as the single internet-facing access point while keeping your ALB private and protecting your applications running on AWS from distributed denial of service (DDoS) attacks.

I usually don’t read all announcements this carefully but now the part in bold started me thinking. I haven’t tested how this was working earlier, but somehow I expected it to be similar Cloudfront where you must have your origins public (as routable to internet at least). And now there was no such requirement. This is a great thing if you think of it from a security point of view. It’s always better if you can expose less of your service to internet.

To test this, I built minimal “application” using only a VPC with 2 private subnets, private ALB with static response and global accelerator using the ALB as endpoint. Note there is no internet gateway.

And it did work as promised, I could get my ALB static response from public IPs associtated with global accelerator. So far so good. Not so good part is, I just exposed services from private subnets and did that without attaching igw or peering connections!

Until now it has been “best practise” to deny any improvised internet access from account/vpc by denying igw and peering modifications with service control policy. Luckily this is easy to fix by adding 2 lines denying all Global Accelerator Create and Update actions.

 "Effect": "Deny",
 "Action": [
    "ec2:AttachInternetGateway",
    "ec2:CreateInternetGateway",
    "ec2:CreateEgressOnlyInternetGateway",
    "ec2:CreateVpcPeeringConnection",
    "ec2:AcceptVpcPeeringConnection",
    "globalaccelerator:Create*",
    "globalaccelerator:Update*"
 ],

But as new service and features keep adding, it would be really nice to have some set of managed SCPs for common tasks like blocking changes to internet access from an account.

P.S. Sep 7, 2019: Before publising this post I sent feedback to AWS asking for an update of documentation and now above sample policy has globalaccelerator actions added. Yet another example of Agility in Action.

P.P.S. Nov 27, 2020: At somepoint AWS did change the Global Accelerator deployment so that you now must have an internet gateway attached to the VPC hosting the endpoint. This feels like a security measure to prevent unauthorised internet access, as there don’t have to be a route via internet gateway, it just has to be attached.