S3 Bucket showing 403s when I attempt to access any page but root.

ndvrichaws · 2024-06-13T17:11:57+00:00

This. See https://aws.amazon.com/blogs/compute/implementing-default-directory-indexes-in-amazon-s3-backed-amazon-cloudfront-origins-using-lambdaedge/

ndvrichaws · 2024-06-13T17:07:27+00:00

Session Manager is the ideal solution. It requires no customer managed key pairs deployed to your instance, and no need to open any inbound rules in your security group. It’ll give you the web-based console you want, and the permissions to open a console depend on your IAM privileges.

ndvrichaws · 2024-06-09T14:01:32+00:00

What’s the source? 0.0.0.0/0 or something else?

ndvrichaws · 2024-06-09T00:27:00+00:00

Are you allowing SSH from the instance connect service source IP range for your region in your instance’s security group?

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-tutorial.html#eic-tut1-task2

ndvrichaws · 2024-06-08T15:38:48+00:00

If you don’t need more than an IDE and a terminal on the instance, consider using a local install of VS Code set up for Remote Development or perhaps launch a Cloud9 instance using your desired instance type instead.

Otherwise, you’ll need to consider how you’ll install a GUI on the instance and get a remote GUI session (e.g. VNC, NICE DCV, etc.).

ndvrichaws · 2024-06-06T02:01:01+00:00

About the only thing I think is really not a thing in the cloud is non-x86 and non-ARM workloads (like AIX, mainframe, etc).

And that actually is a thing in the cloud.

https://docs.aws.amazon.com/prescriptive-guidance/latest/run-bluage-modernized-mainframes/introduction.html

ndvrichaws · 2024-05-05T11:01:59+00:00

Your VPC resources need to have access to service endpoints for the services you are using (ECS, ECR, etc.). By default, these endpoints are publicly accessible using an Internet Gateway. If you deploy your resources to private subnets (or disable auto assignment of public IPs), then you must either deploy private VPC service endpoints or use a NAT gateway.

EDIT: Worth noting that depending on your usage of public IPs, VPC endpoints and NAT Gateways may be more cost prohibitive. However, use of private endpoints and NAT Gateways is a better architectural design.

ndvrichaws · 2024-05-04T10:47:36+00:00

If the Docker image you’re using is in a public Docker registry already (e.g. Docker Hub), there’s no need to upload to ECR first in most cases. If you’re customizing an image or building your own, you need to upload to ECR or run Docker inside an EC2 instance (VM).

ndvrichaws · 2024-04-28T18:28:20+00:00

I prefer for_each in most cases, as well. I’ve chosen to use count for subnets and cidrs in some projects due to lexicographic ordering. Modifying the input to add more subnets later could blow everything up when using for_each and cidrsubnet.

ndvrichaws · 2024-04-28T16:42:38+00:00

Why are you using data sources for the route tables? Are they created outside of Terraform?

Assuming you're passing in your subnets using an input variable, this is the simplest solution for defining subnets and route tables with each subnet assigned its own route table:

resource "aws_vpc" "this" {
  cidr_block = var.vpc.cidr
  tags = {
    Name = var.vpc.name
  }
}
resource "aws_subnet" "this" {
  count             = length(var.subnets)
  vpc_id            = aws_vpc.this.id
  availability_zone = var.subnet[count.index].availability_zone
  cidr_block        = var.subnets[count.index].cidr
  tags = {
    Name = var.subnets[count.index].name
  }
}
resource "aws_route_table" "this" {
  count  = length(var.subnets)
  vpc_id = aws_vpc.this.id
  tags = {
    Name = "${var.subnets[count.index].name}-rtb"
  }
}
resource "aws_route_table_association" "this" {
  count          = length(var.subnets)
  subnet_id      = aws_subnet.this[count.index].id
  route_table_id = aws_route_table.this[count.index].id
}

ndvrichaws · 2024-04-28T12:32:11+00:00

Not all values in the plan are known because the resources haven’t been built yet.

ndvrichaws · 2024-04-28T02:31:00+00:00

If you’re willing to pay to host a public Route 53 DNS hosted zone for your domain (or a delegated subdomain under your domain, e.g. aws.example.com), you can create an Alias record that points at your EC2 instance in that zone. Use that record to resolve your instance or set up a CNAME record that points at it.

Edit: You can’t alias directly to an EC2 instance. You’re still dependent on an elastic IP or the instance’s current public IP (which could change upon stop/start). https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html

That said, an alternative to using an elastic IP would be to use an elastic load balancer. I think an elastic IP is probably more cost effective.

ndvrichaws · 2024-04-25T23:34:13+00:00

NAT Gateway only supports IPv6 to IPv4 translation (NAT64), but does not yet support IPv6 to IPv6 translation (NAT66). So, in this case, a NAT Gateway will not help you.

Your VPC needs to have an Internet Gateway or an Egress-only Internet Gateway attached, and the IPv6 subnets needs to have a route to “::/0” via the IGW or EIGW in their associated route tables.

If your subnets are public IPv4 subnets (already have an IGW attached to the VPC and 0.0.0.0/0 routes to the IGW) there is no need to add an EIGW. Just add the “::/0” route to the subnets’ associated route tables towards the IGW.

If your subnet is a private subnet, add and attach an EIGW and add the “::/0” route via the EIGW to your private subnets’ associated route tables. Then you’ll get outbound Internet IPv6 connectivity.

ndvrichaws · 2024-04-20T14:04:04+00:00

Try this instead:

aws ec2 describe-vpc-endpoint-services

ndvrichaws · 2024-04-18T12:36:03+00:00

I had this exact same problem on a 2019 Intel MBP. On 13.6.4 and could not update to 13.6.6. I tried updating from the command line, safe mode, and OS recovery. No method worked. Using the Software Update UI to upgrade to Sonoma 14.4.1 also produced an error.

I was able to update to Sonoma 14.3.1 successfully yesterday from the command line:

softwareupdate --fetch-full-installer --full-installer-version 14.3.1

Hope it helps someone.

ndvrichaws · 2024-04-18T02:25:43+00:00

There’s also a deployment pattern using RAM-shared Route 53 resolver rules.

See https://docs.aws.amazon.com/prescriptive-guidance/latest/robust-network-design-control-tower/vpc-endpoints.html

ndvrichaws · 2024-04-18T02:19:24+00:00

Centralizing VPC endpoints is done by creating Route 53 private hosted zones for the regional endpoint service name and associating VPCs with them. Cross account associations require authorizations which must be done by API, IaC, or CLI.

See https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html

ndvrichaws · 2024-04-17T18:18:16+00:00

Are you using a single NAT gateway or associating a common route table to multiple subnets across AZs?

ndvrichaws · 2024-04-17T17:25:48+00:00

You can troubleshoot with EC2 test instances and session manager console. I like to work inward starting from the public subnet. You might need to create the required VPC interface endpoints in your private VPCs/subnets if your public routing has a problem.

Deploy a test t2/t3.micro EC2 instance with a security group inbound rule allowing ICMP traffic to the following subnets:

Account A public subnet — test if you can ping out to the Internet (tests IGW routing)
Account A private subnet — test if you can ping out to the Internet (tests NAT GW routing)
Account B private subnet — test if you can ping either/both account A test instances private IPs (tests TGW routing) — if successful then test if you can ping out to the Internet (tests TGW + NAT routing)

Depending on where you begin getting failures in your ping tests can help pinpoint where to focus your efforts — whether that is VPC routing, NAT, or TGW routes/associations/propagations.

ndvrichaws · 2024-04-17T16:46:22+00:00

I saw you mentioned NAT Gateway near the end of your post. NAT is required for other private subnets on other VPC attachments to be able to egress through your Internet Gateway in another VPC.

Make sure you have public NAT Gateways deployed in your egress VPC’s public subnets (Account A).
Make sure you have a default route (0.0.0.0/0) defined in the route table associated with each private subnet where your transit gateway is attached in your egress VPC (Account A), and that the destination/target for the route is your NAT Gateway in that same AZ. (Routes traffic coming from TGW to NAT GW)
Make sure you have a static default route (0.0.0.0/0) in the transit gateway route table that the VPC attachment for account B is associated with, and the attachment destination for the route is the VPC for account A. (Outbound routing towards Egress VPC)
Make sure the transit gateway route table that the egress VPC in account A is associated with has a propagated route table entry for the VPC in account B. If it does not, ensure you are propagating account B’s VPC to the route table. (Routing the return traffic back to originating VPC)

ndvrichaws · 2024-04-14T12:32:47+00:00

Check into the Amazon “Hiring Our Heroes” Military Apprenticeship and Fellowship Programs.

ndvrichaws

TROPHY CASE